Skip to content

pmos-base-ui-networkmanager: set up dnsmasq for filtering lookup

clayton craft requested to merge nm-dnsmasq-filter into master

Testing

Please help test! This patch adds a Network Manager dispatcher script that toggles options in dnsmasq, which control filtering for IPv4 and IPv6 DNS answers. The reason for this madness is to (almost completely) solve the problem where outgoing connections on a device might be routed out of the "wrong" interface. The case I hit all the time before this patch was: I'm connected to wifi and mobile data at the same time, but I was rapidly using up my mobile data cap because a lot of traffic was being routed over it. This is despite being connected to a perfectly fine, unmetered wifi network.

It can be installed using mrtest add 3823. After installing, the easiest way to load up things is to just reboot. No other configuration is necessary.

What to test

1) USB tethering

  • !3819 (merged), cc @dylanvanassche (in case you have time, but anyone else welcome to try it too)
  • Does DNS function properly for both the phone and the target?
  • Does having dnsmasq running already via NM cause problems with configuring things for usb tethering?

2) Does MMS work for different carriers?

  • It requires a very peculiar DNS setup to work.

3) Does IPv6 work as you'd expect when it is only routable over a non-primary connection?

  • IPv6 only on mobile data, while connected also to wifi that is IPv4 only? FWIW, wifi is already prioritized over mobile data in all other network manager config.
  • With the current patch, you shouldn't get any IPv6 responses via DNS (unless you bypass the default nameserver, e.g. dig @X.X.X.X). Which means basically no traffic should go over mobile data / IPv6. Is that reasonable?

4) Do VPNs work as expected?

  • I've lightly tested wireguard and it seemed fine, but definitely interested if there are setups that don't work!

5) What else?

  • I'm sure I'm forgetting something... so try to think of any situations where this could blow up 😅

Additional info

When a connection changes state, the dispatcher script should run and configure dnsmasq to filter A or AAAA answers depending on which gateways are available on the current primary connection. Network Manager has preferences for which connection to "use" based on which other connections are active, it prefers wifi over mobile data, for example. Anyways, the output in syslog should look something like this:

Mar 13 00:08:24 foo user.notice nm-dns-filter[2262]: iface: eth0, action: up ...
Mar 13 00:08:24 foo user.notice nm-dns-filter[2285]: ip4 gateway: 10.0.2.2
Mar 13 00:08:24 foo user.notice nm-dns-filter[2301]: ip6 gateway:
Mar 13 00:08:24 foo user.notice nm-dns-filter[2302]: disabling IPv4 filter
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: Disabling --filter-a option from D-Bus
Mar 13 00:08:24 foo user.notice nm-dns-filter[2304]: enabling IPv6 filter
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: Enabling --filter-aaaa option from D-Bus
Mar 13 00:08:24 foo daemon.info dnsmasq[1887]: cleared cache

Despite the efforts of this patch, there are still opportunities for traffic to go over the wrong interface... This trick only works for apps that use the libc resolver, or are already reading /etc/resolv.conf. Apps that have external DNS servers configured could still receive DNS answers that might steer their traffic away from the primary connection. In practice, I really haven't seen any unexplainable mobile data usage when connected to wifi, but maybe I'm just lucky so far 😄

Please report any new problems in a new comment thread in this MR, and I'll try to get to it ASAP.

See #1430 for more details.

Background

This uses a dispatcher script to configure filtering A and AAAA records based on which IP versions are routable on the NM primary connection.

See #1430 for more details. fixes #1430

TODO:

  • repackage busctl so that elogind isn't "required"

    • I hit a problem with this, help appreciated! /usr/libexec/libelogind-shared-*.so is installed by elogind package but busctl links against it, and there doesn't appear to be a straight forward way to break that .so off into libelogind...
    • submitted patch to aports: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/43543
    • UPDATE merged in aports, and patch updated to depend on busctl

  • add dnsmasq patch to aports, then drop patch from this series

  • [ ] wait for !3819 (merged), test

    • this triggers on the "reapply" event, which is added in a NM upstream patch and supported in !3819 (merged). @dylanvanassche says it works, but let's just make sure after the final versions of those are merged...
    • UPDATE: discussed and decided that this shouldn't be blocked on that
Edited by clayton craft

Merge request reports