Proposal: remove dhclient configuration from debops.tinc

[drybjed]

I'm redesigning the debops.tinc role to use new configuration and remove excessive variables like tinc__*_mesh0 (really, who thought that would be a good idea in the first place?). Druing this I've looked a bit closer at the dhclient configuration the role adds and what really the issue is, and I think this should be removed from the role in the current state, and replaced with more lean solution.

The issue is that when DHCP is used to configure the Tinc clients on the mesh network, the DHCP server offers certain parameters like default route, DNS nameservers and search domains and probably some other configuration. Without any additional work these parameters my disrupt host connectivity - for example the hosts picks the route through the Tinc VPN instead of the more correct route through the normal network interface.

The current solution is to install a hook script, which filters some DHCP parameters like default routers, etc. on the Tinc VPN network interfaces. The idea is good, but I feel that the debops.tinc role is a bad place to set that up. This should be moved to the (currently not existing) dhclient role. Currently in debops.tinc the method is essentially blacklisting certain network interfaces from configuring network parameters; I think that the better way would be to whitelist interfaces instead, which should be easily doable via a dedicated dhclient role.

Blacklisting default routers received from the Tinc VPN is also not that useful in the context of the debops.tinc role. What I would want to do instead, is to define a higher metric, say 100, for the Tinc network interfaces by default. This should ensure that any default route received from the DHCP server will have a higher "cost" and won't be preferred by the operating system. If you don't want to publish a default route through the VPN... fix your DHCP server to not publish such things (debops.dnsmasq allows to control that easily using dnsmasq__router variable).

The same goes for the nameservers and search domains - if your VPN DHCP server does not offer such things, disable them in your DHCP offerings. If it does but your DNS server inside the VPN is making your client network configuration wonky, I think that the issue is on the DNS server side and should be fixed there.

@ypid, since you introduced the dhclient hook script in the role, what do you think about this proposal?

[ypid]

since you introduced the dhclient hook script in the role, what do you think about this proposal?

Sounds like a plan. Sure, we already agreed that the dhclient related parts should be moved to a separate role.

(debops.dnsmasq allows to control that easily using dnsmasq__router variable).

Maybe I need to describe my use case 😉 I have one internal0 bridge on my vps for lxc containers. The lxc containers only have one interface and are not reachable from the Internet. In order for me to configure them I need to connect to the internal0 bridge with my Ansible controller. I guess I could disable the default route for the MAC address of my Ansible controller (is it static by the way?) but I did not want to do that because that VPS is hosted so I consider it semi trusted. So the settings need to be blocked on the Ansible controller.

The same goes for the nameservers and search domains

Similar as above. I use a subdomain pubsrv.ypid.de for my public servers. I have a local dnsmasq configured to forward queries to the dnsmasq on the internal0 network which has all the records via DHCP.

[drybjed]

OK then, I'm gonna drop the dhclient hook from the role as discussed.

If you haven't specified the MAC address of the Tinc interface using the hwaddr parameter, the role will generate random but known and static MAC address based on the FQDN of the host, you can check that in the tinc-up script. You can then define configuration for that host in the dnsmasq using this MAC address. After a rewrite the Tinc interface will automatically have a lower metric, so it shouldn't affect routing on the Ansible Controller.

[ypid]

Do you plan to move the dhclient features somewhere?

[drybjed]

Yes, I wanted for your dhclient role and update it a bit. I hope that you don't mind. :-)

[ypid]

I don’t mind 😄 How could I. I ensured the role is GPL-3.0 to account for that case when we last talked about it. Awesome work, as always 👍

[ypid]

@drybjed noted that this feature might take awhile before it gets added again/the new role becomes ready. I am using this workaround for now:

resources__host_files:
  - dest: '/etc/dhcp/dhclient-enter-hooks.d/00ypid-tinc'
    content: |
      # This file is managed by Ansible, all changes will be lost.
      # Hook into `dhclient-script(8)` because properly rejecting configuration
      # options in `dhclient.conf(5)` is not supported and upstream seems to be
      # unwilling to fix this.
      # Refs: (ordered after helpfulness, from helpful to unhelpful)
      # * https://singpolyma.net/2012/08/how-to-force-the-default-route-to-always-use-a-specific-interface-on-ubuntu/
      # * https://lists.debian.org/debian-user/2010/09/msg00240.html
      # * https://unix.stackexchange.com/questions/120009/strip-specific-option-from-a-response-in-dhclient
      # * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232
      #
      # The feature has been removed from the tinc role:
      # https://github.com/debops/ansible-tinc/issues/37
      #
      # Doing it manually until the feature gets reimplemented.
      case ${interface} in
          tap-mesh0) unset new_routers ;;
      esac
      case ${interface} in
          tap-mesh0) unset new_domain_name_servers new_domain_search ;;
      esac