Manglende VPN-rute i NetworkManager: profilpolicy eller et skript?

Du kobler til, tunellgrensesnittet dukker opp, og ett prefiks du trenger er rett og slett ikke i tabellen. Neste steg er vanligvis et søk etter et skript som legger det til. Det søket ender på svar som limer inn en OpenVPN-hjelper i en profil, og halvparten av disse svarene gjør situasjonen verre i stedet for bedre, fordi en manglende rute har tre mulige eiere, og bare én av dem er et manglende skript.

Avgjør hvilken eier som er ansvarlig før du skriver noe.

Tre eiere, ett manglende prefiks

Prefikset kan mangle fordi ingen leverte det, fordi profilen avviste det, eller fordi det ble installert et sted du ikke ser. Det er forskjellige feil, og de har forskjellige rettelser.

Det første er lettest å sjekke: tilbød serveren eller pluginen noen gang ruten? En backend som aldri mottok prefikset, kan ikke installere det, og et hjelpeskript kan ikke finne opp en tilgjengelighet som motparten aldri beskrev. Det andre er profilpolicy, som kan undertrykke ruter som forbindelsen ellers ville ta. Det tredje er en tabell eller regel, som kan holde ruten på et sted der standardoppslaget aldri ser.

En fjerde eier er deg, senere: et skript som legger til ruten ved tilkobling, men ikke fjerner den ved frakobling. Det gir et prefiks som overlever tunnelen, peker på et dødt grensesnitt og forvirrer den neste som feilsøker maskinen.

Les profilen før du legger til noe

Start med den lagrede forbindelsens egne egenskaper. Les dem uten å dumpe hemmeligheter, og bruk UUID-en hvis profilnavnet er tvetydig.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type forteller deg hvilken backend som eier forbindelsen, og det er viktig fordi plugin-data er backends-spesifikke. En nøkkel som én plugin godtar, er ikke en støttet instruksjon for en annen, så et utdrag kopiert fra en annen klients dokumentasjon er ikke bevis for noe.

ipv4.ignore-auto-routes og ipv4.never-default svarer på forskjellige spørsmål. Det første kan avvise ruter som forbindelsen ellers ville ta automatisk, og det andre styrer om profilen kan bli standardruten. En profil som ignorerer automatiske ruter og ikke stoler på noe annet, kobler til rent og installerer nesten ingenting.

ip -4 rule show
ip -4 route show table all

Disse to kommandoene avgjør den tredje muligheten. Se etter prefikset ditt i hver tabell, ikke bare main, og sjekk om en policyregel sender det relevante oppslaget et annet sted. Hvis prefikset finnes i en annen tabell og ingenting konsulterer det, har du ikke en manglende rute; du har et oppslag som aldri når den.

Hva et skript ikke kan rette

Å legge til et hjelpeskript gir vpn.data i NetworkManager et program å kjøre. Det er en reell mekanisme, og den er feil for de fleste av disse tilfellene, fordi skriptet får kontroll etter at profilens egen policy allerede har bestemt hva som skal godtas.

script-security i OpenVPN er den andre gjentakende forvirringen. Det er en OpenVPN-innstilling som styrer hvilke skript klienten kan kjøre og hva den kan legge i miljøet deres; nivå 3 tillater å sende legitimasjon gjennom miljøet, noe som er en beslutning om håndtering av hemmeligheter og ikke en rutingsrettelse. Å lime det inn i en profil der backend ikke er OpenVPN, eller å heve det når ingen skript trenger det, gir mer eksponering uten å gi en rute.

Så er det omstartrefleksen. Å starte NetworkManager-tjenesten på nytt river ned og bygger opp igjen hver administrert lenke, inkludert den du er koblet gjennom hvis du jobber eksternt. Det er en forstyrrende handling, ikke en uskyldig diagnose, og på en server kan det være forskjellen mellom en økt som overlever og en som ikke gjør det.

Beslutningen, i rekkefølge

Still tre spørsmål etter hverandre. Leverte motparten prefikset, noe backendens logg eller dens egen statusutskrift vil vise? Hvis ja, er profilen konfigurert til å godta og installere ruter, eller undertrykker den dem? Hvis ruten finnes et sted, er oppslagbanen riktig for trafikken du tester?

Bare når det første svaret er ja, det andre er ja og det tredje er riktig, blir et supplerende skript forsvarlig, og selv da bør du spørre om backend støtter ruten innfødt. VPN-innstillingsreferansen dokumenterer service-type og den pluginspesifikke dataordboken, og det er der man bør begynne før man antar at en nøkkel finnes.

Etter en godkjent rettelse, koble til på nytt og test målet etter adresse og deretter etter navn, og koble så fra og til igjen for å bekrefte at tilstanden er repeterbar. Én eier, én tabell og en rute som forsvinner med tunnelen er resultatet som er verdt å ha.