Add --dns-hosts command-line option. #22

Open
wants to merge 23 commits into
from

Conversation

Projects
None yet
9 participants

The --dns switch adds firewall rules to intercept queries only for
nameservers found in resolv.conf ; This command-line option allows
the user to explicitly specify the nameservers to create firewall
redirection rules for.

This is useful when using a local DNS forwarder to redirect DNS queries
to different nameservers.

Example:

We can use sshuttle to access a private subnet 172.30.0.0/16, which hosts
a local DNS server resolving private domain names in that subnet.

Currently, the only way to be able to resolve those domain names is to use
the --dns switch. However, all DNS queries will then go through the remote
nameserver, which might not be desirable especially if said nameserver
does not know how to resolve every query.

One solution is to run a local DNS forwarder, which knows that the private
domain names can be resolved through a private IP, say 172.30.128.40.

Now, we can run :

sshuttle -r ssh.remoteserver.com -i 172.30.0.0/16 --dns-hosts 172.30.128.40

DNS queries for private domain names will get forwarded to 172.30.128.40,
intercepted by the firewall rule and sent through the tunnel to the nameserver
used by the remote endpoint (which might or might not be 172.30.128.40 !).

Notes :

  • There is nothing preventing --dns-hosts from being used together with
    --dns, in which case the nameservers found in resolv.conf will also be
    added to the firewall rules as usual. This defeats the purpose of the
    example, however.
    There might be some weird use-case where this is useful ?
  • Since there is no control over which nameserver the query gets sent to
    after it has crossed the tunnel, the IPs specified in --dns-hosts are
    irrelevant (as long as they are the same as found in the DNS forwarder
    configuration). This might be a little counter-intuitive.

apenwarr and others added some commits Jan 2, 2012

ipfw: don't use 'log' parameter.
I guess we were causing the kernel to syslog on every single packet on
MacOS.  Oops.
ui-macos/main.py: fix wait() to avoid deadlock.
If the subprocess was trying to write to its stdout/stderr, its process
would never actually finish because it was blocked waiting for us to read
it, but we were blocked on waitpid().  Instead, use waitpid(WNOHANG) and
continually read from the subprocess (which should be a blocking operation)
until it exits.
firewall: catch SIGHUP and SIGPIPE.
Not sure if this will fix anything, but it might stop the problem reported
on some MacOS versions where the firewall doesn't get cleaned up correctly.
Use the new arguments from redo v0.10.
(apenwarr: also updates to the matching, latest minimal/do)
Import the non-pandoc manpage generator from redo.
This makes it easier (possible?) to generate sshuttle.8 from sshuttle.md on
MacOS.  We also import the git-enhanced version numbering magic so the
generated manpage can have a real version number.
Add a --version (-V) option.
Now that we imported the feature from redo, might as well use it.
firewall.py: workaround MacOS 10.7 Lion bug.
On top of the bug that already existed in 10.6, Lion also makes the sysctl
needed to fix the problem into a read-only variable, so we have to actually
change it at kernel boot time and force people to reboot.  Nice job, Apple.
firewall.py: clean up repeated calls to ssubprocess.call().
And make sshuttle exit with a well-defined exit code (111) if it needs to
reboot.
Fix runpython.do for systems with unxpected configurations.
If the expected arch directory doesn't exist, give up and don't specify arch at
all. Currently it expands to '*' which fails.

[slightly modified by apenwarr]
server.py: slightly rearrange previous commit.
Add some documentation about the int() vs long() and the reason behind
_shl().  Instead of "from __future__ import generators", just don't use
generators.
firewall.py: catch SIGINT and SIGTERM too.
There were still a few conditions under some OSes that would cause
firewall.py to terminate without cleaning up the firewall settings.  'pkill
sshuttle' was one of them.  Ignore a couple more signals to further ensure a
correct cleanup.

(This only affects sshuttle --firewall, which is a subprocess of the main
sshuttle process.  The firewall is supposed to exit automatically whenever
the client exits, and so far that part seems to work reliably.)
Added --exclude-from feature.
(Slightly modified by apenwarr)
auto-hosts: don't add hosts that aren't being routed by sshuttle.
I've been meaning to add this patch for a long time, but it's especially
important once we add FQDN support to --auto-hosts.  Basically, auto-hosts
will still discover all the hostnames it can, but we'll only add them to
/etc/hosts if their IP address is in one of the routed subnet ranges.  That
prevents polluting the /etc/hosts file with cruft.
hostwatch: handle fully qualified domain names
(slightly modified by apenwarr)
Merge branch 'fqdn'
* fqdn:
  hostwatch: handle fully qualified domain names
  auto-hosts: don't add hosts that aren't being routed by sshuttle.
dns: Move resolvconf_nameservers() call from firewall.py to client.py
This adds a dns_hosts command-line option, which is passed internally to
the firewall, containing a comma-separated list of nameservers to target
when creating firewall rules.
dns: Add --dns-hosts command-line option.
The --dns switch adds firewall rules to intercept queries only for
nameservers found in resolv.conf ; This command-line option allows
the user to explicitly specify the nameservers to create firewall
redirection rules for.

This is useful when using a local DNS forwarder to redirect DNS queries
to different nameservers.

Example:

  We can use sshuttle to access a private subnet 172.30.0.0/16, which hosts
  a local DNS server resolving private domain names in that subnet.

  Currently, the only way to be able to resolve those domain names is to use
  the --dns switch. However, all DNS queries will then go through the remote
  nameserver, which might not be desirable especially if said nameserver
  does not know how to resolve every query.

  One solution is to run a local DNS forwarder, which knows that the private
  domain names can be resolved through a private IP, say 172.30.128.40.

  Now, we can run :

    sshuttle -r ssh.remoteserver.com -i 172.30.0.0/16 --dns-hosts 172.30.128.40

  DNS queries for private domain names will get forwarded to 172.30.128.40,
  intercepted by the firewall rule and sent through the tunnel to the nameserver
  used by the remote endpoint (which might or might not be 172.30.128.40 !).

Notes :

    * There is nothing preventing --dns-hosts from being used together with
	  --dns, in which case the nameservers found in resolv.conf will also be
	  added to the firewall rules as usual. This defeats the purpose of the
	  example, however.
	  There might be some weird use-case where this is useful ?

    * Since there is no control over which nameserver the query gets sent to
	  after it has crossed the tunnel, the IPs specified in --dns-hosts are
	  irrelevant (as long as they are the same as found in the DNS forwarder
	  configuration). This might be a little counter-intuitive.

peyoot commented on 9ce2fa0 Feb 11, 2015

I use this command: sshuttle -D --dns -vvr user@ip:port 0/0 ,to make it run as daemon. But how can I disconnect it? does sshuttle provide any shortcut key to stop or kill the corresponding threads?
I try to use byobu to run it in one terminal, but it turns out that my ssh session to the host that runs sshuttle won't close if I remain sshuttle in background connected to remote server. any solution?

Hasimir added a commit to Hasimir/sshuttle that referenced this pull request Jun 24, 2015

Merge branch 'pull/22'
* Merging pull request #22.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment