Manglende VPN-rute i NetworkManager: profilpolitik eller et script?

Du opretter forbindelse, tunnelgrænsefladen dukker op, og et præfiks, du har brug for, er ganske enkelt ikke i tabellen. Næste skridt er normalt en søgning efter et script, der tilføjer det. Den søgning ender på svar, der klistrer en OpenVPN-hjælper ind i en profil, og halvdelen af de svar gør situationen værre i stedet for bedre, fordi en manglende rute har tre mulige ejere, og kun én af dem er et manglende script.

Afgør, hvilken ejer der er ansvarlig, før du skriver noget.

Tre ejere, ét manglende præfiks

Præfikset kan mangle, fordi ingen leverede det, fordi profilen afviste det, eller fordi det blev installeret et sted, du ikke kigger. Det er forskellige fejl, og de har forskellige rettelser.

Det første er lettest at kontrollere: tilbød serveren eller pluginnet nogensinde ruten? En backend, der aldrig modtog præfikset, kan ikke installere det, og et hjælpescript kan ikke opfinde en tilgængelighed, som modparten aldrig beskrev. Det andet er profilpolitik, som kan undertrykke ruter, som forbindelsen ellers ville tage. Det tredje er en tabel eller regel, som kan holde ruten et sted, hvor standardopslaget aldrig kigger.

En fjerde ejer er dig, senere: et script, der tilføjer ruten ved forbindelse, men ikke fjerner den ved afbrydelse. Det giver et præfiks, der overlever tunnelen, peger på en død grænseflade og forvirrer den næste, der fejlretter maskinen.

Læs profilen, før du tilføjer noget

Start med den gemte forbindelses egne egenskaber. Læs dem uden at dumpe hemmeligheder, og brug UUID'en, hvis profilnavnet er tvetydigt.

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

vpn.service-type fortæller dig hvilken backend der ejer forbindelsen, og det er vigtigt, fordi plugin-data er specifikke for backenden. En nøgle, som ét plugin accepterer, er ikke en understøttet instruktion for et andet, så et uddrag kopieret fra en anden klients dokumentation er ikke bevis for noget.

ipv4.ignore-auto-routes og ipv4.never-default besvarer forskellige spørgsmål. Det første kan afvise ruter, som forbindelsen ellers ville tage automatisk, og det andet styrer, om profilen må blive standardruten. En profil, der ignorerer automatiske ruter og ikke stoler på noget andet, opretter forbindelse rent og installerer næsten intet.

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

De to kommandoer afgør den tredje mulighed. Led efter dit præfiks i hver tabel, ikke kun main, og kontroller, om en politikregel sender det relevante opslag et andet sted hen. Hvis præfikset findes i en anden tabel, og intet konsulterer det, har du ikke en manglende rute; du har et opslag, der aldrig når den.

Hvad et script ikke kan rette

At tilføje et hjælpescript giver NetworkManagers vpn.data et program at køre. Det er en reel mekanisme, og det er den forkerte til de fleste af disse tilfælde, fordi scriptet får kontrol, efter at profilens egen politik allerede har afgjort, hvad der skal accepteres.

OpenVPNs script-security er den anden tilbagevendende forvirring. Det er en OpenVPN-indstilling, der styrer, hvilke scripts klienten må køre, og hvad den må lægge i deres miljø; niveau 3 tillader at sende legitimationsoplysninger gennem miljøet, hvilket er en beslutning om håndtering af hemmeligheder snarere end en rutningsrettelse. At klistre det ind i en profil, hvis backend ikke er OpenVPN, eller hæve det, når intet script har brug for det, tilføjer eksponering uden at tilføje en rute.

Så er der genstartsrefleksen. Genstart af NetworkManager-tjenesten river hver administreret forbindelse ned og genopbygger den, inklusive den, du er forbundet gennem, hvis du arbejder eksternt. Det er en forstyrrende handling, ikke en uskyldig diagnostik, og på en server kan det være forskellen mellem en session, der overlever, og en, der ikke gør.

Beslutningen, i rækkefølge

Stil tre spørgsmål i rækkefølge. Leverede modparten præfikset, hvilket backendens log eller dens egen statusudskrift vil vise? Hvis ja, er profilen konfigureret til at acceptere og installere ruter, eller undertrykker den dem? Hvis ruten findes et sted, er opslagsvejen korrekt for den trafik, du tester?

Kun når det første svar er ja, det andet er ja, og det tredje er korrekt, bliver et supplerende script forsvarligt, og selv da bør du spørge, om backenden understøtter ruten oprindeligt. VPN-indstillingsreference dokumenterer service-type og den pluginspecifikke dataordbog, og det er der, man skal starte, før man antager, at en nøgle findes.

Efter en godkendt rettelse skal du oprette forbindelse igen og teste destinationen efter adresse og derefter efter navn, og derefter afbryde og tilslutte igen for at bekræfte, at tilstanden kan gentages. Én ejer, én tabel og en rute, der forsvinder med tunnelen, er det resultat, der er værd at have.