Add support for systemd-resolved

[da-x]

These two commits make it possible to update systemd-resolved with the DNS server configuration upon a successful connect. First commit adds a generic script invocation, and the second adds an example script for updated systemd-resolved.

[DimitriPapadopoulos]

Perhaps it would be worth discussing this pull request in #600.

[Tatsh]

Version of this patch for version 1.17.1 (works on Gentoo with its user patches system): https://gist.github.com/Tatsh/8ad5aa75721d6ba018a20906a04a6fa3

[DimitriPapadopoulos]

I think it would be best to strandardize on vpnc-script, like OpenConnect.

[Tatsh]

In terms of systemd stuff, it should be detected if the user is actually using it. It's not required by systemd to be working. If that check fails for some reason (false positive), a new setting like systemd-dns should be added so it can be set to 0.

Lastly, rather than introducing a generic scripting thing here, the code could directly call the D-Bus API.

Main thing for me is to have the D-Bus calls do the DNS changing, and not touch /etc/resolv.conf.

[Tatsh]

This does fix my issue where Chrome (and not any others) could not resolve based on changes made to /etc/resolv.conf. Many things read it and take the first nameservers, but not Chrome as of recently.

Now that those changes are made to the PPP link with systemd, Chrome can correctly resolve certain VPN-specific domains.

This is a much appreciated patch.

[DimitriPapadopoulos]

I believe vpnc-script does the right thing. It would be great to remove the routing/DNS code written in C and call vpnc-script instead. Unfortunately, I don't have the resources for that change.

[DimitriPapadopoulos]

Finally, I suppose Chrome is resolving using systemd. Other software resolve using glibc.

You can reproduce this using systemd-resolve (obviously uses systemd) and nslookup (uses glibc).

While systemd and glibc have been unified in recent Fedora distributions (https://fedoraproject.org/wiki/Changes/systemd-resolved), this might not be the case on Gentoo.

[Tatsh]

They won't be unified on Gentoo, unless Gentoo decides that systemd will be the only supported init system. This is very unlikely to happen.

[Tatsh]

macOS needs equivalent call to networksetup -setdnsservers IF ..., but I do not see vpnc-scripts supporting it at this time.

Edit: It does support it by using scutil.

[DimitriPapadopoulos]

Yes, there are open issues about that:
openconnect/vpnc-scripts#15
openconnect/vpnc-scripts#27

Yet I believe vpnc-scripts remain the best bet in the long term.

[Tatsh]

I looked at some of the logic to see if it's feasible to use as-is with the current openfortivpn code (with a change similar to this PR). Right now the main issue is the VPNGATEWAY environment variable which then calls set_vpngateway_route, where this is already taken cared of by openfortivpn. Otherwise, the INTERNAL_IP4_DNS env var with the connect reason will set the correct DNS, while the disconnect reason will undo it.

So in summary:

• openfortivpn has to pass VPNGATEWAY (and others) for routing, and INTERNAL_IP4_DNS for DNS, via environment
• Make a code path to avoid doing routing/DNS in openfortivpn and instead pass it to vpnc-script. Perhaps an option like --use-vpnc-script [PATH] (default to searching for vpnc-script in PATH)
• Call the script at the appropriate times: vpnc-script pre-init, vpnc-script connect, vpnc-script disconnect

[DimitriPapadopoulos]

Yes, most of ipv4.c would be replaced by vpnc-script, or an alternative script such as vpnc-slice. And indeed, an -s/--script option would be great to choose the script that handles routing/DNS settings.

The nice thing with that solution is that IPv6 support would (more) straightforward to add.

[Tatsh]

@DimitriPapadopoulos this change is now in master?

[DimitriPapadopoulos]

It shouldn't. Let me see. No, it's not in the master branch.

[DimitriPapadopoulos]

This pull request has been closed inadvertently by GitHub. Re-opened as #1092.