Saknad VPN-rutt i NetworkManager: profilpolicy eller ett skript?

Du ansluter, tunnelgränssnittet dyker upp, och ett prefix du behöver finns helt enkelt inte i tabellen. Nästa steg är vanligtvis en sökning efter ett skript som lägger till det. Den sökningen landar i svar som klistrar in en OpenVPN-hjälpare i en profil, och hälften av dessa svar gör situationen värre i stället för bättre, eftersom en saknad rutt har tre möjliga ägare och bara en av dem är ett saknat skript.

Avgör vilken ägare som är ansvarig innan du skriver något.

Tre ägare, ett saknat prefix

Prefixet kan saknas för att ingen levererade det, för att profilen avvisade det, eller för att det installerades någonstans där du inte tittar. Det är olika fel och de har olika åtgärder.

Det första är lättast att kontrollera: erbjöd servern eller pluginen någonsin rutten? En backend som aldrig fick prefixet kan inte installera det, och ett hjälpskript kan inte hitta på en nåbarhet som motparten aldrig beskrev. Det andra är profilpolicy, som kan undertrycka rutter som anslutningen annars skulle ta. Det tredje är en tabell eller regel, som kan hålla rutten på en plats där standarduppslaget aldrig tittar.

En fjärde ägare är du, senare: ett skript som lägger till rutten vid anslutning men inte tar bort den vid frånkoppling. Det ger ett prefix som överlever tunneln, pekar på ett dött gränssnitt och förvirrar nästa person som felsöker maskinen.

Läs profilen innan du lägger till något

Börja med den sparade anslutningens egna egenskaper. Läs dem utan att dumpa hemligheter, och använd UUID:n om profilnamnet är tvetydigt.

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

vpn.service-type berättar vilken backend som äger anslutningen, och det spelar roll eftersom plugin-data är backendspecifika. En nyckel som en plugin accepterar är inte en instruktion som stöds av en annan, så ett utdrag kopierat från en annan klients dokumentation bevisar ingenting.

ipv4.ignore-auto-routes och ipv4.never-default svarar på olika frågor. Den första kan avvisa rutter som anslutningen annars skulle ta automatiskt, och den andra styr om profilen får bli standardrutten. En profil som ignorerar automatiska rutter och inte förlitar sig på något annat ansluter rent och installerar nästan ingenting.

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

De två kommandona avgör den tredje möjligheten. Sök efter ditt prefix i varje tabell, inte bara i main, och kontrollera om en policyregel skickar det relevanta uppslaget någon annanstans. Om prefixet finns i en annan tabell och ingenting konsulterar det, har du inte en saknad rutt; du har ett uppslag som aldrig når den.

Vad ett skript inte kan åtgärda

Att lägga till ett hjälpskript ger vpn.data i NetworkManager ett program att köra. Det är en verklig mekanism, och den är fel för de flesta av dessa fall, eftersom skriptet får kontroll efter att profilens egen policy redan har bestämt vad som ska accepteras.

script-security i OpenVPN är den andra återkommande förvirringen. Det är en OpenVPN-inställning som styr vilka skript klienten får köra och vad den får lägga i deras miljö; nivå 3 tillåter att skicka inloggningsuppgifter genom miljön, vilket är ett beslut om hantering av hemligheter och inte en routingrättelse. Att klistra in det i en profil vars backend inte är OpenVPN, eller höja det när inget skript behöver det, ökar exponeringen utan att lägga till en rutt.

Sedan är det omstartsreflexen. En omstart av NetworkManager-tjänsten river ner och bygger upp varje hanterad länk igen, inklusive den du är ansluten genom om du arbetar på distans. Det är en störande åtgärd, inte en ofarlig diagnos, och på en server kan det vara skillnaden mellan en session som överlever och en som inte gör det.

Beslutet, i ordning

Ställ tre frågor i följd. Levererade motparten prefixet, vilket backendens logg eller dess egen statusutskrift visar? Om ja, är profilen konfigurerad att acceptera och installera rutter, eller undertrycker den dem? Om rutten finns någonstans, är uppslagssökvägen korrekt för den trafik du testar?

Först när det första svaret är ja, det andra är ja och det tredje är korrekt blir ett kompletterande skript försvarbart, och även då bör du fråga om backenden stöder rutten inbyggt. Referensen för VPN-inställningar dokumenterar service-type och den pluginspecifika dataordboken, och det är där man bör börja innan man antar att en nyckel finns.

Efter en godkänd rättelse, anslut igen och testa målet efter adress och sedan efter namn, koppla sedan från och anslut igen för att bekräfta att tillståndet är repeterbart. En ägare, en tabell och en rutt som försvinner med tunneln är resultatet som är värt att ha.