Hello
On 2023-02-22 22:08, David Wright wrote:
On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:
What I want is: setting up /etc/resolv.conf ONLY
- at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN
(cleaning it's mess in the routing table, interfaces, /etc/resolv's
and other netwwork stuff it might have modified, makes sense)
What's the output from ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf
With the ctime changing more or less often, since it is
deleted/recreated by what I suspect to do DHCP requests (see audit.log)
What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.
openconnect does. When it's CTRL-C-ed to disconnect from the workplace
VPN, resolv.conf is reverted back to my home network resolver
Not sure whether vpnc_script just calls the DHCP client (probably
dhclient since it's the only dhcp client preinstalled, at least I'm
aware of)
- I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
connmann as the default network manager) ships with systemd-resolvd
disabled and I'm totally OK with it
- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as
root. I used auditd to detect when changes that file… but I can't a
get any process name. I can just see it's root
One way of finding the process is to # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)
Thank you. I'll give it a try, But I won't be on remote work before next
week
Which log file is used for that?
So instead of grepping /var/log/ recursively when the problem occurs.
I'd tail -f the right file to find the "rogue" process right away
But how do you manage /etc/resolv.conf with connman. I don't use it,
openconnect uses something called vpnc_script.
When openconnects is exc, resolv.conf contains the appropriate info as
well a comment including "VPNC_GENERATED"
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.
Whether it informs connmann or cleans after itself without involving
connmann, I don't know and I'm not sure how to check that out.
I'm not familiar with how vpnc_script works and what it does _exactly_
But it does clean up the config and network config is left in working
state when openconnect disconnects
I was expecting to see a process name it the audit.log file BUT it
didn't happened so I'm still stuck. so my question is: How to debug
that further, and identify the exact process that screw up with
/etc/resolv.conf file… So from there I could search for a way to
prevent that by modifying the rights config file or whatever…
Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)
Yes, I certainly don't want to block the process entirely, I just want
to find some mechanism that works in the following way
"Leave /etc/resolv.conf alone, ONLY IF you're not openconnect/a
vpnc_script AND WHEN openconnect is running"
Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
generated according to my home router's DHCP tells the computer
Thank you for your help either way. It gives me some interesting
pointers :)
Cheers,
David.
