VPN säger ansluten, men standardvägen är död

Klienten rapporterar ansluten, ikonen i aktivitetsfältet ser normal ut och ingenting laddas. Det började direkt efter att du gick från Wi-Fi till kabel, eller direkt efter att en distributionsuppgradering blev klar. Det som gick sönder är inte profilen utan tillståndet som byggdes för den förra basanslutningen. Kärnan har fortfarande en standardväg som pekar på en tunnelenhet som ingen äger, eller resolvern listar fortfarande servrar på en länk som är borta. Båda felen ser ut som ett dött nätverk och båda kan repareras på plats.

De föråldrade delarna var redan fel innan du märkte dem. Att dra ur en kabel gjorde dem bara synliga.

Fråga kärnan vart ett paket skulle ta vägen

Rutlistor är svåra att läsa eftersom de räknar upp allt systemet känner till, inklusive poster som inte längre gäller. En rutsökning svarar på den enda fråga som är värd att ställa: vilken enhet bär just detta paket just nu. Om svaret nämner en tunnelenhet kommer kärnan att använda den även om det inte finns någon levande klientprocess bakom, och paketet faller ned i ett gränssnitt som ingen underhåller. Om svaret nämner Ethernet-adaptern medan klienten insisterar på att anslutningen är uppe, finns tunneln men har förlorat urvalet, vilket är det vanliga resultatet av att byta från trådlöst till kabel.

Kör sökningen två gånger, en gång för en offentlig adress och en gång för en intern, eftersom en princip för delad tunnel kan routa den ena ärligt och tappa den andra.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Resolvern behåller också den döda länken

På en värd med systemd-resolved hör DNS-servrar till länkar i stället för till en global lista. En VPN-länk som har fallit kan stanna kvar registrerad med sina servrar ett tag, och då väntar varje sökning på en adress som aldrig kommer att svara. Den fördröjningen känns som ett dött nätverk och skickar folk att titta på rutter när rutten är i ordning.

resolvectl status
resolvectl query intranet.example.com

Läs blocken per länk och avgör vilken länk som äger den aktuella domänen. En tunnel som är uppe men inte äger den interna domänen vidarebefordrar interna namn till den offentliga resolvern, och symtomet går inte att skilja från ett routingfel.

Reparera registreringen i stället för /etc/resolv.conf. På nuvarande Ubuntu- och Fedora-installationer är den sökvägen en symbolisk länk till resolverns körtidstillstånd, så en ändring ignoreras eller skrivs över vid nästa nätverkshändelse.

En VPN startar aldrig av sig själv

NetworkManager lyfter en VPN ovanpå en basanslutning, och den lär sig vilken den ska följa från connection.secondaries på den basen. Referensen för anslutningsinställningar säger uttryckligen att autoconnect inte är implementerat för VPN-profiler. Det är hela mekanismen bakom den här klassen av fel: ändra basen, och VPN:en måste paras ihop igen eller aktiveras manuellt.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

När den aktiva listan visar basen utan VPN:en är tunneln inte aktiv alls och rutten installerades aldrig i stället för att ha lämnats föråldrad. När aktiveringen klagar över att det inte finns någon källanslutning har basen den var ihopaprad med försvunnit, så reparera basen eller ihopaparningen först och sluta försöka med VPN:en igen.

En uppgradering kan tappa inställningar utan ett meddelande

Att uppgradera en distribution ersätter klienten och ofta dess NetworkManager-plugin, medan den sparade profilen behåller de egenskapsnamn den skrevs med. Allt det nya pluginet inte längre känner igen hoppas över i tysthet. Profilen aktiveras fortfarande och enheten syns fortfarande, men rutten som förut kom med den kommer aldrig.

Handskrivna krokar flyttar sig också. Ett skript som installerade en rutt vid en förutsägbar tidpunkt i den gamla sekvensen kan nu köra innan gränssnittet finns, eller efter att klienten redan har tajmat ut.

Jämför den levande profilen med det plugin du faktiskt har, i stället för med beteendet du minns. Om en nyckel är borta från dokumentationen, flytta arbetet till ett dispatcher-skript eller en stödd ersättning i stället för att återställa den gamla egenskapen.

Tre tillstånd, tre olika reparationer

Bestäm vilket tillstånd du är i innan du rör något, eftersom en omstart förstör bevisen och felet kommer tillbaka vid nästa nätverksändring.

Avsluta med en sökning för en offentlig adress, en för en intern adress och en namnfråga. Om adresserna fungerar och namnet inte, är det återstående felet domänomfång i resolvern, och routingtabellen var aldrig problemet.