Re: Forcing dhclient to not ignore tun0 interface when it's available

[davenull@tuxfamily.org]

On 2023-03-07 05:01, David Wright wrote:
> On Mon 06 Mar 2023 at 13:34:52 (+0100), davenull@tuxfamily.org wrote:
> > On 2023-03-03 16:00, Max Nikulin wrote:
> > > On 03/03/2023 13:29, Tim Woodall wrote:
> > > > On Fri, 3 Mar 2023, Max Nikulin wrote:
> > > > >
> > > > > dhclient running for enp2s0f0 should detect that VPN is
> > > > > active and to avoid overwriting DNS settings that direct
> > > > > requests to tun0.
> > > > >
> > > > The hook can create and delete a file like rhis:
> > > > tim@dirac:/etc/dhcp (none)$ cat dhclient-enter-hooks.d/nodnsupdate
> > > > make_resolv_conf() {
> > > >          :
> > > > }
> > >
> > > I agree that VPN script may add and remove dhclient hook or may write
> > > some file in /run that is read by dhclient hook. They should cooperate
> > > in some way. In more versatile configuration domain resolution may be
> > > per-interface. E.g. hosts from the corporate domain are resolved
> > > through tun0, other sites through enp2s0f0.
> >
> > I agree about cooperation. BUT  It would be much easier if everything
> > is resolved through workplace's resolver whenever openconnect is
> > active.
>
> I don't see how your workplace's resolver can resolve addresses on
> your own LAN.

Well, I meant resolving anything on the Internet + work's private 
network. Not on my LAN

It obviously can't resolve hostnames on my LAN, but for the time being, 
there's actually nothing on LAN I'd want to resolve.

I have a network printer which I use once in a while, but it configured 
in CUPS by IP, not by (its 3 km long, weird,) hostname.
And I don't use it often enough (so it's mostly off to save electricity) 
to spend time
to create/test (then script) a route specifically for anything 
192.168.1.0/192.0168.0.0 while the VPN is on.
So for the printer is inaccessible either way when the VPN is on

The printer being only thing on my which I might need to resolve… maybe 
one day.
But it has a weird hostname harder to remember than it's IP (not sure if 
I can change the hostname for something human-readable…,
still learning about its capabilities and menus),
And I don't use it daily. So I'm OK with not being able to print with 
VPN connected

Granted, I might want to exclude 192.168.0|1.0 from requests sert to 
workplace resolver. But I certainly
don't to think about each (sub)domain and whether it's should/can be 
resolved by worksplace or
not

> > If I have to specify all the domains I want to be resolved using tun0
> > interface,
> > It would be annoying to configure and error-prone. Because there
> > multiple "private"
> > different domains, in additions to private subdomains, of
> > publicly-accessible "parent" domains.
>
> I was under the impression that the fifty-odd functions in the
> vpnc-script we discussed earlier had a role in setting your
> resolvers and routing for the tunnel with the environment parameters.
>
> > Not to mention redirections for SSO/authentication (depending on the
> > tool/server/where's it hosted, it not the same LDAP server),
> > or tools which multiple servers but without load-balancer/unique URL
> > for access. You just arrive on one of the servers.
> > Some kind of load balancing but different FQDN for each server of the
> > pool.
> >
> > And some tools have literally multiples redirections before the home
> > page, across different domains and subdomains
>
> I'm guessing that you're talking here about stuff at the other
> end of the tunnel? Presumably they have sysadmins setting that up.
>
> Cheers,
> David.