openconnect gedood: routes en DNS wijzen nog steeds naar de tunnel

De tunnel is neer, maar de machine gedraagt zich nog steeds alsof hij omhoog is: een opzoeking blijft hangen tot de time-out, en een route wijst naar een interface die niet meer bestaat. Dat is de signatuur van een openconnect-proces dat stierf zonder zijn loskoppelhulpje te draaien. De netwerkstatus die het creëerde, is nog steeds geïnstalleerd, en niets anders op het systeem weet hoe die te verwijderen.

Loop de machine door in de volgorde waarin de status is ontstaan: proces, link, route, resolver. Elke stap vertelt je of de client echt weg is of alleen van je terminal is losgekoppeld, en dat onderscheid bepaalt of je überhaupt iets moet repareren.

Begin bij het proces, niet bij de configuratie

Open een terminal en vraag wat er nog draait voordat je een route aanraakt. pgrep -a openconnect somt elke instantie met zijn argumenten op, wat het pid-bestand en het script laat zien dat hij kreeg. Een proces dat je niet verwachtte, verklaart de fantoomtunnel sneller dan welk log dan ook.

Als er niets draait, kijk dan naar de link. ip link show tun0 vertelt je of de interface heeft overleefd, en ip route show dev tun0 somt routes op die er nog aan gebonden zijn. Controleer daarna de resolver met resolvectl status. Noteer alle drie de uitvoer voordat je ze wijzigt, want die registratie is hoe je later een verouderde vermelding van een nieuwe onderscheidt.

Een interface die weg is, neemt meestal zijn routes mee. Routes die de link overleven, betekenen meestal dat het proces nog leeft of dat een tweede client het apparaat bezit.

Het hulpscript is wat de wijzigingen terugdraait

openconnect verwijdert de interface, de routes en de resolver-vermeldingen niet zelf. Het roept een externe helper aan, /etc/vpnc/vpnc-script in een upstream-build en /usr/share/vpnc-scripts/vpnc-script in de Debian- en Ubuntu-pakketten, gekozen met -s. Hetzelfde script dat de tunnel opzet, breekt hem ook af.

Als het proces eindigt zonder die helper aan te roepen, blijft de status staan. OpenConnect-handleiding zegt uitdrukkelijk dat routering en naamdienst zonder het script niet correct werken, en beschrijft de helper als de component die de interfacestatus bij het afsluiten afbreekt. Daarom is het pad belangrijk wanneer je de client start met -s.

Welk signaal dat pad bereikt, is tussen versies veranderd. De handleiding van 7.06 behandelt SIGTERM als een onmiddellijke exit die het script overslaat. Huidige builds documenteren INT en TERM als een schone stop, waarbij de sessie wordt afgemeld en de helper draait. Lees de sectie SIGNALS van het binaire bestand dat je echt hebt in plaats van een van beide gedragingen aan te nemen.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Stuur het signaal dat je build documenteert

Als je het signaal kent, stop het proces dan op pid en niet op patroon.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Herhaal daarna de drie controles uit het eerste deel in plaats van de exitstatus te vertrouwen. ip link show tun0 zou moeten mislukken, ip route show dev tun0 zou niets moeten afdrukken, en resolvectl status zou de VPN-link niet meer moeten oplijsten.

SIGHUP is geen stopknop: het verbreekt, voert het script uit en laat de sessie hervatbaar met --cookie. SIGUSR2 forceert een onmiddellijke herverbinding. SIGKILL slaat het opruimen volledig over, en dat is precies de toestand waarover dit artikel gaat.

Repareer de resolver zonder resolv.conf te vervangen

Op de meeste Ubuntu-systemen is /etc/resolv.conf een symbolische link naar systemd-resolved, geen bestand dat je zou moeten bewerken. Het vervangen breekt naamresolutie voor elk netwerk, niet alleen de VPN. Verwijder in plaats daarvan de registratie van de tunnel:

resolvectl revert tun0
resolvectl query example.com

Als het systeem resolvconf gebruikt in plaats van systemd-resolved, blijft de vermelding per interface staan totdat er wordt gezegd de link los te laten, en resolvconf -d tun0 is de equivalente actie. Controleer welke resolver wordt gebruikt voordat je het commando kiest.

Een opzoeking die nog op een server achter de dode link is gericht, blijft hangen tot de time-out, en die vertraging lijkt op een kapotte DNS-server in plaats van een overgebleven route.

Maak de volgende ontkoppeling saai

Houd het pad van het pid-bestand gelijk bij het starten en afsluiten door --pid-file elke keer mee te geven, of draai openconnect onder een unit waarvan de KillSignal overeenkomt met het signaal dat je versie documenteert. Eerst op de voorgrond testen laat je de afsluitberichten zien die de helper afdrukt.

Verbind, verbreek en voer de drie controles één keer uit. Een schone exit laat geen VPN-link, geen VPN-route en geen VPN-resolver-vermelding achter. Als een van de drie overleeft, weet je nu welke component niet heeft opgeruimd. Het volgende onderzoek begint dan bij dat antwoord in plaats van bij een hangende opzoeking.