Megölt openconnect: az útvonalak és a DNS még mindig az alagútra mutatnak

Az alagút le van állva, de a gép még mindig úgy viselkedik, mintha fel lenne: egy lekérdezés addig lóg, míg le nem jár az idő, és egy útvonal olyan interfészre mutat, amely már nem létezik. Ez annak az openconnect-folyamatnak a jele, amely úgy halt meg, hogy nem futtatta le a bontó segédprogramját. A hálózati állapot, amelyet létrehozott, még mindig telepítve van, és semmi más a rendszerben nem tudja, hogyan kell eltávolítani.

Járja végig a gépet abban a sorrendben, ahogy az állapot létrejött: folyamat, kapcsolat, útvonal, resolver. Minden lépés megmondja, hogy az ügyfél valóban eltűnt-e, vagy csak a termináljáról vált le, és ez a különbség dönti el, hogy egyáltalán javítson-e valamit.

A folyamattal kezdje, ne a konfigurációval

Nyisson egy terminált, és kérdezze meg, mi fut még, mielőtt hozzányúlna egy útvonalhoz. pgrep -a openconnect minden példányt felsorol az argumentumaival, ami megmutatja a pid-fájlt és a neki adott szkriptet. Egy váratlan folyamat gyorsabban megmagyarázza a fantomalagutat, mint bármelyik napló.

Ha semmi sem fut, nézze meg a kapcsolatot. ip link show tun0 megmondja, hogy túlélte-e az interfész, és ip route show dev tun0 felsorolja az útvonalakat, amelyek még hozzá vannak kötve. Ezután ellenőrizze a resolvert ezzel resolvectl status. Jegyezze fel mindhárom kimenetet, mielőtt módosítja őket, mert ez a feljegyzés az, amivel később megkülönbözteti az elavult bejegyzést az újtól.

Egy eltűnt interfész általában magával viszi az útvonalait. A kapcsolatot túlélő útvonalak általában azt jelentik, hogy a folyamat még él, vagy hogy egy második ügyfél birtokolja az eszközt.

A segédszkript az, ami visszafordítja a változtatásokat

Az openconnect nem maga távolítja el az interfészt, az útvonalakat vagy a resolver-bejegyzéseket. Külső segédprogramot hív, /etc/vpnc/vpnc-script egy upstream buildben és /usr/share/vpnc-scripts/vpnc-script a Debian és Ubuntu csomagokban, ezzel kiválasztva: -s. Ugyanaz a szkript építi fel az alagutat, amelyik le is bontja.

Ha a folyamat anélkül lép ki, hogy meghívná ezt a segédprogramot, az állapot megmarad. Az OpenConnect kézikönyv egyértelműen kimondja, hogy az útválasztás és a névszolgáltatás a szkript nélkül nem fog megfelelően működni, és a segédprogramot úgy írja le, mint a kilépéskor az interfész állapotát bontó komponenst. Ezért számít az útvonal, amikor ezzel indítja az ügyfelet: -s.

Hogy melyik jel ér el ehhez az útvonalhoz, verziók között változott. A 7.06 kézikönyve a SIGTERM-et azonnali kilépésnek tekinti, amely kihagyja a szkriptet. A jelenlegi buildek az INT-et és a TERM-et tiszta leállításként dokumentálják, ahol a munkamenet kijelentkezik, és a segédprogram lefut. Olvassa el annak a binárisnak a SIGNALS szakaszát, amely valóban megvan, ahelyett hogy bármelyik viselkedést feltételezné.

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

Küldje el a jelet, amelyet a buildje dokumentál

Ha ismeri a jelet, állítsa le a folyamatot pid alapján, ne minta alapján.

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

Ezután ismételje meg az első szakasz három ellenőrzését, ahelyett hogy a kilépési állapotban bízna. ip link show tun0 sikertelennek kell lennie, ip route show dev tun0 nem szabad semmit kiírnia, és resolvectl status már nem szabad listáznia a VPN-kapcsolatot.

A SIGHUP nem stopgomb: bontja a kapcsolatot, lefuttatja a szkriptet, és a munkamenetet ezzel folytathatóan hagyja: --cookie. A SIGUSR2 azonnali újracsatlakozást kényszerít. A SIGKILL teljesen kihagyja a tisztítást, és pontosan ez az az állapot, amelyről ez a cikk szól.

Javítsa meg a resolvert a resolv.conf lecserélése nélkül

A legtöbb Ubuntu rendszeren /etc/resolv.conf a systemd-resolved felé mutató szimbolikus hivatkozás, nem olyan fájl, amelyet szerkesztenie kellene. Lecserélése minden hálózat névfeloldását elrontja, nem csak a VPN-ét. Ehelyett távolítsa el az alagút regisztrációját:

resolvectl revert tun0
resolvectl query example.com

Ha a rendszer a systemd-resolved helyett resolvconfot használ, az interfészenkénti bejegyzés mindaddig megmarad, amíg nem szólítják fel a kapcsolat elengedésére, és resolvconf -d tun0 az egyenértékű művelet. Ellenőrizze, melyik resolvert használja, mielőtt kiválasztja a parancsot.

Egy lekérdezés, amely még mindig a halott kapcsolat mögötti kiszolgálóra irányul, addig lóg, míg le nem jár az idő, és ez a késleltetés inkább törött DNS-kiszolgálónak tűnik, mint egy maradék útvonalnak.

Tegye unalmassá a következő lecsatlakozást

Tartsa azonosnak a pid-fájl útvonalát indításkor és leállításkor azzal, hogy --pid-file minden alkalommal átadja, vagy futtassa az openconnectet egy unit alatt amelynek KillSignal egyezik a verziója által dokumentált jellel. Az előtérben való tesztelés megmutatja a leállítási üzeneteket, amelyeket a segédprogram kiír.

Csatlakozzon, csatlakozzon le, és futtassa egyszer a három ellenőrzést. Egy tiszta kilépés nem hagy VPN-kapcsolatot, VPN-útvonalat vagy VPN-resolver-bejegyzést. Ha a három közül egy túléli, most már tudja, melyik komponens nem takarított. A következő vizsgálat akkor abból a válaszból indul, nem egy lógó lekérdezésből.