OpenConnect vpnc-script: hvilken fil kjøres?

OpenConnect kan fullføre tunnelhåndtrykket og likevel la deg stå uten rute til det private subnettet, fordi klienten og hjelperen som endrer den lokale nettverkstilstanden er to forskjellige programmer. Autentiseringen beviser at gatewayen godtok økten; den beviser ingenting om hvilket grensesnitt, hvilke ruter eller hvilke resolverinnstillinger som ble installert etterpå. De fleste forvirrende rapportene kommer av å erstatte hjelperen med en kopi fra et gammelt svar, noe som endrer oppførselen for hver tilkobling på maskinen. Finn hjelperen den kjørende klienten faktisk kaller, før du endrer noe i den.

To programmer, to ansvarsområder

Klienten eier transport, autentisering og tunnelenheten. En separat hjelper eier det som skjer på det lokale systemet når tunnelen finnes: adressering på grensesnittet, ruter til subnettene gatewayen annonserte, og resolverkonfigurasjon. dokumentasjonen for OpenConnect-hjelperen beskriver denne delingen og miljøet hjelperen mottar. Forskjellen betyr noe under en feil, fordi et avvist passord og en manglende rute ikke er samme hendelse, selv når skrivebordet viser én dialog for begge.

Å huske denne delingen forklarer også hvorfor en tilkobling kan rapportere suksess mens private navn fortsatt ikke lar seg slå opp. Tunnelen er oppe i begge tilfeller, og bare det lokale integreringstrinnet er forskjellig.

Finn hjelperen den kjørende klienten bruker

Stien fastsettes når pakken bygges, og kan overstyres ved hvert kall, så filen du husker fra en annen distribusjon har kanskje ingenting med denne tilkoblingen å gjøre. Spør den kjørende prosessen i stedet for dokumentasjonen du tilfeldigvis har åpen.

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

Hvis prosesslinjen bærer et --script argument, vinner den filen over den kompilerte standarden. Eldre stier som /etc/vpnc/vpnc-script kan finnes og likevel være ubrukte, og derfor endrer sletting eller redigering av dem ingenting på en nyere bygg. Sjekk også endringsdatoen, fordi en hjelper ingen har rørt på årevis er et sterkt tegn på at standardverdien fra pakken gjør jobben.

NetworkManager-integrasjonen er en tredje eier, med sin egen hjelper og egne profilinnstillinger. Å legge et ekstra rute- eller resolverskript oppå den integrasjonen dobbeltfører ruter og etterlater en resolver som to programmer begge hevder å styre. Velg én eier per tilkobling, og slå av den andre før du tester.

Les den første mislykkede operasjonen, ikke den siste advarselen

Grensesnittkonfigurasjon, ruteinstallasjon, resolvalg og opprydding av utdatert tilstand er separate trinn, og advarselen som skrives ut sist er ofte en oppryddingsklage og ikke feilen som brøt tilkoblingen. Les oppover til den første konkrete operasjonen som mislyktes. En hjelperfeil som navngir en fil eller en adresse er verdt mer enn ti linjer oppryddingsstøy.

Sammenlign det tilsiktede lokale resultatet med det observerte: tunnelenheten finnes, en rute til en kjent privat adresse går gjennom den, og resolveren svarer for et privat navn. En hjelper som lykkes med de to første og feiler på det tredje, peker på resolverpolitikk og ikke på ruting. En hjelper som ikke konfigurerer enheten i det hele tatt ble sannsynligvis aldri kjørt, og det er et spørsmål om tillatelser, ikke om nettverk. Bekreft den kjørbare biten og tjenestekontoen før du skriver om noen logikk.

Verifiser tilkobling, gjenoppkobling og frakobling

Oppsettet er bare halvparten av kontrakten, fordi den samme hjelperen må gjenopprette eller fjerne tilstanden den eier når tunnelen lukkes. En hjelper som legger til ruter og aldri fjerner dem, etterlater maskinen med en utdatert sti som overlever økten.

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'

Kjør de tre første mens du er tilkoblet, koble fra, og kjør dem så igjen og bekreft at ruten og resolveroppføringen er borte. Den fjerde linjen viser om hjelperen ble kalt i det hele tatt, og hvilken kjørbar sti tjenesten brukte. Ta vare på det paret med utdata i saken, fordi nettopp før-og-etter gjør en oppryddingsfeil tydelig.

Hold hjelperen pakket og kjørbar for tjenestekontoen, fordi et skript som kjører i skallet ditt kan fortsatt bli avvist under en begrenset tjenestepolicy. Når en tilpasning virkelig er nødvendig, dokumenter formålet og eieren, og sammenlign den med den pakkede versjonen ved hver oppgradering. En uforklart fork av en hjelper er en av de få tingene som kan få en fungerende tilkobling til å feile et år senere.