New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd-resolved (in some configurations?) breaks telepresence #242

Closed
itamarst opened this Issue Jul 24, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@itamarst
Contributor

itamarst commented Jul 24, 2017

See #135 (comment) and following comment.

Tte way sshuttle works is to capture DNS packets going to configured nameservers and in /etc/resolv.conf and forward them to remote DNS server (in our case k8s proxy). The log attached in comment linked above shows no DNS packets being sent for hellotelepresence.

When systemd-resolved NSS plugin was removed from /etc/nsswitch.conf, however, everything worked. This suggests systemd-resolved NSS plugin is breaking resolution.

A plausible theory: caching, since this was issue on OS X as well. After first hellotelepresence the lack of domain is cached by OS X's resolver, which I solve by flushing its cache each time. systemd-resolved also does caching, so might have similar issue.

If that is the problem, we need to flush cache. Or, an even better idea: instead of always looking up some domain, look up hellotelepresence1, hellotelepresence2, hellotelepresence3, etc., so caching isn't an issue and we don't need to do custom per-platform cache clearing.

@itamarst

This comment has been minimized.

Contributor

itamarst commented Jul 24, 2017

Some testing by @farcaller suggests maybe the issue is not caching, but rather that systemd-resolved decides not to send single segment DNS records to DNS servers.

@itamarst

This comment has been minimized.

Contributor

itamarst commented Jul 24, 2017

From https://www.freedesktop.org/software/systemd/man/systemd-resolved.html:

Single-label names are routed to all local interfaces capable of IP multicasting, using the LLMNR protocol. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are only sent via LLMNR on IPv6. Lookups for the locally configured host name and the "gateway" host name are never routed to LLMNR.

Search domains are per-link, it sounds like as well, so lacking a search domain from DHCP, it seems like LLMNR is used, which means sshuttle won't capture those packets since they're not sent to DNS servers at all.

@itamarst

This comment has been minimized.

Contributor

itamarst commented Jul 24, 2017

Seems like it's possible to convince sshuttle (currently by patching its code) to capture packets sent via LLMNR - basically you have sshuttle capture packets going to 224.0.0.252:5355. This isn't quite the same as DNS, but possibly close enough that it'll just work. Otherwise we can modify Twisted's DNS parser, possibly.

So next need to test whether in telepresence case we can capture packets this way.

@itamarst

This comment has been minimized.

Contributor

itamarst commented Jul 24, 2017

The proposed fix seems to work.

Remaining:

  • Get @farcaller to test (but need to push image first.)
  • Tests pass on Travis, in particular Mac.
  • Think about how automated tests could work, given Travis doesn't have new enough thing. (Filed #249).
  • File ticket about upstreaming new llmnr sshuttle branch in our fork, update fork README.

@itamarst itamarst moved this from Next to In progress in Telepresence Jul 25, 2017

@itamarst itamarst removed this from In progress in Telepresence Jul 25, 2017

@itamarst itamarst added this to In progress in Telepresence Jul 25, 2017

itamarst added a commit that referenced this issue Jul 26, 2017

@farcaller

This comment has been minimized.

farcaller commented Jul 26, 2017

^ Tested, works for me

@itamarst

This comment has been minimized.

Contributor

itamarst commented Jul 26, 2017

0.62 should be released in next 30 minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment