Add --dns-hosts command-line option. #22
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I guess we were causing the kernel to syslog on every single packet on MacOS. Oops.
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.
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.
(apenwarr: also updates to the matching, latest minimal/do)
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.
Now that we imported the feature from redo, might as well use it.
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.
And make sshuttle exit with a well-defined exit code (111) if it needs to reboot.
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]
Add some documentation about the int() vs long() and the reason behind _shl(). Instead of "from __future__ import generators", just don't use generators.
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.)
(Slightly modified by apenwarr)
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.
(slightly modified by apenwarr)
* fqdn: hostwatch: handle fully qualified domain names auto-hosts: don't add hosts that aren't being routed by sshuttle.
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.
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.
Hasimir
added a commit
to Hasimir/sshuttle
that referenced
this pull request
Jun 24, 2015
* Merging pull request apenwarr#22.
noglitchyo
approved these changes
Oct 2, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 :
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 :
--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 ?
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.