OpenConnect vpnc-script: vilken fil körs?

OpenConnect kan slutföra tunnelns handskakning och ändå lämna dig utan rutt till det privata subnätet, eftersom klienten och hjälparen som ändrar det lokala nätverkets tillstånd är två olika program. Autentiseringen bevisar att gatewayen accepterade sessionen; den bevisar ingenting om vilket gränssnitt, vilka rutter eller vilka resolverinställningar som installerades efteråt. De flesta förvirrande rapporterna kommer från att hjälparen ersätts med en kopia från ett gammalt svar, vilket ändrar beteendet för varje anslutning på maskinen. Hitta hjälparen som den körande klienten faktiskt anropar innan du ändrar något i den.

Två program, två ansvarsområden

Klienten äger transport, autentisering och tunneleenheten. En separat hjälpare äger det som händer i det lokala systemet när tunneln finns: adressering på gränssnittet, rutter till subnäten som gatewayen annonserade och resolverkonfiguration. dokumentationen för OpenConnect-hjälparen beskriver den uppdelningen och den miljö som hjälparen får. Skillnaden spelar roll vid ett fel, eftersom ett avvisat lösenord och en saknad rutt inte är samma händelse även när skrivbordet visar en enda dialog för båda.

Att hålla den uppdelningen i minnet förklarar också varför en anslutning kan rapportera framgång medan privata namn fortfarande inte går att slå upp. Tunneln är uppe i båda fallen, och bara det lokala integrationssteget skiljer sig.

Hitta hjälparen som den körande klienten använder

Sökvägen fastställs när paketet byggs och kan åsidosättas vid varje anrop, så filen du minns från en annan distribution har kanske ingenting med den här anslutningen att göra. Fråga den körande processen i stället för dokumentationen du råkar ha öppen.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Om processraden bär ett --script argument vinner den filen över det kompilerade standardvärdet. Äldre sökvägar som /etc/vpnc/vpnc-script kan finnas och ändå vara oanvända, och därför ändrar radering eller redigering av dem ingenting i en nyare bygge. Kontrollera också ändringsdatumet, eftersom en hjälpare som ingen har rört på åratal är ett starkt tecken på att standardvärdet från paketet gör jobbet.

NetworkManager-integrationen är en tredje ägare, med egen hjälpare och egna profilinställningar. Att lägga ett andra rutt- eller resolverskript ovanpå den integrationen dubblerar rutter och lämnar en resolver som två program båda hävdar att de hanterar. Välj en ägare per anslutning och stäng av den andra före test.

Läs den första misslyckade åtgärden, inte den sista varningen

Gränssnittskonfiguration, ruttinstallation, resolvval och städning av föråldrat tillstånd är separata steg, och varningen som skrivs ut sist är ofta ett städklagomål och inte felet som bröt anslutningen. Läs uppåt till den första konkreta åtgärden som misslyckades. Ett hjälparfel som namnger en fil eller en adress är värt mer än tio rader städbrus.

Jämför det avsedda lokala resultatet med det observerade: tunneleenheten finns, en rutt till en känd privat adress går genom den, och resolvern svarar för ett privat namn. En hjälpare som lyckas med de två första och misslyckas med det tredje pekar på resolverpolicy och inte på routing. En hjälpare som inte konfigurerar enheten alls kördes förmodligen aldrig, och det är en fråga om behörigheter, inte om nätverk. Bekräfta den körbara biten och tjänstekontot innan du skriver om någon logik.

Verifiera anslutning, återanslutning och frånkoppling

Inställningen är bara halva kontraktet, eftersom samma hjälpare måste återställa eller ta bort det tillstånd den äger när tunneln stängs. En hjälpare som lägger till rutter och aldrig tar bort dem lämnar maskinen med en föråldrad sökväg som överlever sessionen.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Kör de tre första medan du är ansluten, koppla från och kör dem sedan igen och bekräfta att rutten och resolverposten är borta. Den fjärde raden visar om hjälparen anropades överhuvudtaget och vilken körbar sökväg tjänsten använde. Spara det paret utdata i ärendet, eftersom just före-och-efter gör ett städningsfel uppenbart.

Håll hjälparen paketerad och körbar för tjänstekontot, eftersom ett skript som körs i ditt skal kan ändå nekas under en begränsad tjänstepolicy. När en anpassning verkligen behövs, dokumentera syftet och ägaren och jämför den med den paketerade versionen vid varje uppgradering. En oförklarad fork av en hjälpare är en av de få saker som kan få en fungerande anslutning att misslyckas ett år senare.