openconnect i vrarë: rrugët dhe DNS-ja ende tregojnë tunelin

Tuneli është poshtë, por makina ende sillet sikur të ishte lart: një kërkim varet derisa skadon, dhe një rrugë tregon një ndërfaqe që nuk ekziston më. Ky është nënshkrimi i një procesi openconnect që vdiq pa ekzekutuar ndihmësin e tij të shkëputjes. Gjendja e rrjetit që krijoi është ende e instaluar, dhe asgjë tjetër në sistem nuk e di si ta heqë atë.

Përshkoni makinën sipas rendit në të cilin u krijua gjendja: proces, lidhje, rrugë, resolver. Çdo hap ju thotë nëse klienti ka ikur vërtet apo është shkëputur vetëm nga terminali juaj, dhe kjo dallim vendos nëse duhet të riparoni ndonjë gjë.

Filloni me procesin, jo me konfigurimin

Hapni një terminal dhe pyesni çfarë po funksionon ende përpara se të prekni një rrugë. pgrep -a openconnect rendit çdo shembull me argumentet e tij, gjë që tregon skedarin pid dhe skriptin që iu dha. Një proces që nuk e prisnit e shpjegon tunelin fantazmë më shpejt se çdo regjistër.

Nëse asgjë nuk funksionon, shikoni lidhjen. ip link show tun0 ju thotë nëse ndërfaqja mbijetoi, dhe ip route show dev tun0 rendit rrugët që janë ende të lidhura me të. Më pas kontrolloni resolverin me resolvectl status. Shkruani të tre daljet përpara se t'i ndryshoni, sepse pikërisht ai regjistrim është mënyra për të dalluar më vonë një zë të vjetruar nga një i ri.

Një ndërfaqe që zhduket zakonisht i merr rrugët me vete. Rrugët që i mbijetojnë lidhjes zakonisht nënkuptojnë se procesi është ende i gjallë ose se një klient i dytë zotëron pajisjen.

Është skripti ndihmës ai që i anulon ndryshimet

openconnect nuk e heq vetë ndërfaqen, rrugët ose zërat e resolverit. Ai thërret një ndihmës të jashtëm, /etc/vpnc/vpnc-script në një ndërtim upstream dhe /usr/share/vpnc-scripts/vpnc-script në paketat Debian dhe Ubuntu, i zgjedhur me -s. I njëjti skript që ngre tunelin është ai që e çmonton.

Nëse procesi del pa thirrur atë ndihmës, gjendja mbetet. manuali i OpenConnect thotë shprehimisht se rrugëtimi dhe shërbimi i emrave nuk do të funksionojnë si duhet pa skriptin, dhe e përshkruan ndihmësin si komponenti që çmonton gjendjen e ndërfaqes në dalje. Kjo është arsyeja pse rruga ka rëndësi kur e nisni klientin me -s.

Cili sinjal arrin në atë rrugë ndryshoi midis versioneve. Manuali i 7.06 e trajton SIGTERM si një dalje të menjëhershme që e kalon skriptin. Ndërtimet aktuale dokumentojnë INT dhe TERM si një ndalesë të pastër, ku sesioni shkëputet dhe ndihmësi ekzekutohet. Lexoni seksionin SIGNALS të binarit që keni vërtet, në vend që të supozoni njërin prej dy sjelljeve.

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

Dërgoni sinjalin që dokumenton ndërtimi juaj

Pasi ta dini sinjalin, ndaloni procesin sipas pid dhe jo sipas modelit.

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

Më pas përsëritni tre kontrollet e pjesës së parë në vend që t'i besoni statusit të daljes. ip link show tun0 duhet të dështojë, ip route show dev tun0 nuk duhet të shtypë asgjë, dhe resolvectl status nuk duhet të rendisë më lidhjen VPN.

SIGHUP nuk është buton ndalimi: shkëput, ekzekuton skriptin dhe e lë sesionin të rifillueshëm me --cookie. SIGUSR2 detyron një rilidhje të menjëhershme. SIGKILL e kalon plotësisht pastrimin, dhe pikërisht ky është gjendja për të cilën është ky artikull.

Riparoni resolverin pa zëvendësuar resolv.conf

Në shumicën e sistemeve Ubuntu /etc/resolv.conf është një lidhje simbolike në systemd-resolved, jo një skedar që duhet ta redaktoni. Zëvendësimi i saj prish zgjidhjen e emrave për çdo rrjet, jo vetëm për VPN. Në vend të kësaj, hiqni regjistrimin e tunelit:

resolvectl revert tun0
resolvectl query example.com

Nëse sistemi përdor resolvconf në vend të systemd-resolved, zëri për ndërfaqe vazhdon derisa t'i thuhet ta lëshojë lidhjen, dhe resolvconf -d tun0 është veprimi ekuivalent. Kontrolloni cili resolver po përdoret përpara se të zgjidhni komandën.

Një kërkim ende i drejtuar nga një server pas lidhjes së vdekur varet derisa skadon, dhe ai vonesë duket si një server DNS i prishur dhe jo si një rrugë e mbetur.

Bëjeni shkëputjen tjetër të mërzitshme

Mbani të njëjtën rrugë të skedarit pid në nisje dhe në mbyllje duke kaluar --pid-file çdo herë, ose ekzekutoni openconnect nën një njësi të cilit KillSignal i përgjigjet sinjalit që dokumenton versioni juaj. Testimi fillimisht në plan të parë ju tregon mesazhet e mbylljes që shtyp ndihmësi.

Lidhuni, shkëputuni dhe ekzekutoni tre kontrollet një herë. Një dalje e pastër nuk lë asnjë lidhje VPN, asnjë rrugë VPN dhe asnjë zë resolver VPN. Nëse njëri prej të treve mbijeton, tani e dini cili komponent nuk pastroi. Hetimi tjetër atëherë fillon nga ai përgjigje dhe jo nga një kërkim që varet.