Hello,
========= context =========
For the context, I use a Debian 11 laptop for work. When I work remotely
from home, I have to use a cisco VPN. Good thing is there is
openconnect, which does work, and in teh case of ym work's VPN, it does
wor. cisco's spyware/downloaded binry, namely using the --csd-wrapper
/usr/libexec/openconnect/"
When I start openconnect, it usses some vpnc sript to write a porper,
working, /etc/resolv.conf, with the right (work's) DNS resolver IP in
it. And it works.
That worked flawlessly for months. But some months ago, probably after
an upgrade or something (because I definitely didn't change anything),
something started to screw up with /etc/resolv.conf.
So issue is not openconnect-related, at was just for the context. And to
make it clear that totally disabling DHCP and writing the whole network
config manually is not reasonably doable in my context. Because it's a
laptop, sometime used with VPN, sometimes without it (even from home,
occasionally, like during training on which I need to access external
VMs that are not withelisted workplace's firewalls) so network context
varies sometimes.
===== end of context =====
There is an unidentified process that decides it's ok to delete and
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and
creates the file with wrong resolver's IP. The IP corresponds to my home
router IP, which does has a DNS resolver and it works as it should. BUT
my home's router DNS obviously don't know jack about work internal
servers, on which I work… and work's proxy as well, which when it cannot
be resolved… breaks everything using HTTP.
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)
Here's what I know:
- Whatever process does that seems does what I highly suspect to be DHCP
[1] requests every now and then. Home's router answers giving it's own
address as both gateway and DNS resolver. And said process thinks it's
OK to delete and recreate resolv.conf with the wrong content… breaking
everything work's related while the VPN is still active
- Such requests which varies a lot and inst consistent, can be twice or
tree time in 10 minutes or 3-5 times during one afternoon…). sometimes
it happens the minute after I restart the VPN client to recreate a
working resolv.conf file, sometimes it leaves the file alone for 15,
minutes or even 2-3 hours…
- I never configured anything that to do repetitive/time-random DHCP
requests. Except of course the initial DHCP request the system is first
started and connected in the morning when I satrt my work day, wich is
configurerd by default when you install debian for desktop/laptop/with
DEs and network managers and all the fancy stuff.
- 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
Here's what tail -f audit.log | grep --color resolv.conf shown what it
happens
------
type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf"
inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf"
inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
cap_frootid=0OUID="root" OGID="root"
------
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…
1. But didn't sniff network packets to confirma or infirm that, because
I might wait for long time for it to happen, making extremely huge pcap
files… Unless I know exactly what to filter out from input to have
compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll
end up with nothing. If I don't filter anything and it doesn't happen
before 2 or 3 hours, it will take a shitload too much space form my home
partition and would be PITA to use wireshark's search functions and
display filters, and search for specific stuff, that will probably need
several attempts with different search pattern and display filters to
MAYBE find out something. Because I wouldn't know for sure what I'm
looking for… Plus, it obviously would only confirm whether or not it's
DHCP requests without additional nfo I actually need. I prefer to put my
efforts and to time to look for the actual culprit process, not just the
protocol.
