VPN säger ansluten men inget dirigeras: två ställen att titta på

En tunnel kan rapportera ansluten medan inget når den, och de två fakta bor på olika ställen. Det ena är routingtabellen, som fortfarande kan skicka paket till en enhet som ingen äger. Det andra är resolvern, som fortfarande kan lista en server på en länk som är borta. Nätverksändringen skadade inte profilen, den gjorde tillståndet som hörde till den tidigare anslutningen föräldralöst, och reparationen beror på vilket av de två du faktiskt tittar på.

Fråga först kärnan vilken enhet den skulle använda

En ruttlista visar vad som finns; en routeuppslagning visar vad som skulle ske. Fråga efter en offentlig adress och läs enhetsnamnet i svaret, för det enda fältet avgör om paketet når någonstans användbart. När svaret namnger en tunnelenhet lämnar kärnan paketen dit även om ingen klientprocess fortfarande körs bakom det gränssnittet. När svaret namnger det fysiska kortet medan klienten påstår sig vara ansluten är tunneln uppe och helt enkelt inte den valda vägen.

Det andra fallet är det vanliga efter att en kabel ersatt trådlöst, och det presenterar sig som en trasig VPN.

ip route show default
ip route get 203.0.113.9

Läs sedan standardposterna, eftersom en route som lagts till av den tidigare basanslutningen kan överleva ett länkbyte och hamna framför den nya. En standardroute via en enhet som ligger nere är värre än ingen standardroute, eftersom kärnan fortfarande föredrar den. Notera metriken bredvid varje post, för den ordningen förklarar preferensen snabbare än gränssnittsnamnen.

Läs sedan resolvern per länk, inte per fil

Namnuppslagning bär sitt eget tillstånd och sin egen inaktualitet. En resolver som listar DNS-servrar per länk behåller servrarna för en tunnellänk som ligger nere men fortfarande är registrerad, och varje uppslagning väntar då på en server som inte kommer att svara. Symtomet är ett nätverk som känns dött medan routingtabellen ser perfekt ut.

Granska tillståndet per länk i stället för filen, för på många distributioner är filen en symbolisk länk in i resolvern och att redigera den gör antingen ingenting eller skrivs snabbt över. Titta på vilken länk som äger vilka servrar och vilken sökdomän, och fråga sedan om tunnellänken alls borde vara registrerad. Om inte, inaktivera anslutningen som äger den i stället för att redigera genererat tillstånd för hand. Ett namn som löses upp medan routeuppslagningen skickar paketen någon annanstans är ett tredje och separat fel.

resolvectl status
resolvectl query app.internal.example

Om adresser löses upp och anslutningar misslyckas är resolvern okej och routen inte. Om adresser inte löses upp alls är det här rätt ställe att börja.

Hur en inaktuell route överlever ändringen

Klienten äger inte nätverket själv. På en NetworkManager-värd aktiveras en VPN-profil ovanpå en basanslutning, och anslutningsinställningarna låter den basen namnge den VPN som ska följa den. När basen byts för att en annan profil blir föredragen följer tunneln med till den nya basen eller blir stående utan någon.

En VPN-profil tar inte upp sig själv, så parkopplingen betyder mycket mer än profilens egen autoconnect-inställning.

Läs den aktiva listan och notera vilken bas som är uppe innan du rör tunneln. Om basen finns med och tunneln inte, saknas routen snarare än att vara inaktuell och åtgärden är aktivering. Om aktiveringen av tunneln klagar på att ingen källanslutning finns, är basen den parkopplades med borta, så få upp den först eller reparera parkopplingen i stället för att försöka med tunneln igen. Att försöka igen med en profil vars förälder saknas ger samma fel varje gång, vilket är en användbar signal och inte en olägenhet.

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

Skilj inaktuellt tillstånd från en saknad förälder

Tre tillstånd förklarar nästan varje rapport, och varje kräver sin egen reparation. En standardroute via en enhet som fortfarande finns men inte längre bär tunneln är inaktuellt tillstånd, rensat antingen genom att ta bort posten eller genom att starta om profilen som ansvarar för den. En tunnelenhet vars klientprocess har försvunnit är ett städningsfel, så frånkopplingsvägen förtjänar uppmärksamheten och inte routingtabellen. Ingen tunnelenhet alls betyder att föräldern eller parkopplingen saknas och att routingtabellen aldrig var inblandad.

En omstart döljer vilket av de tre du hade, och det är just därför det känns som en åtgärd.

Fråga efter reparationen kärnan om en offentlig och en intern adress, och slå sedan upp ett internt namn. När adressen fungerar och namnet inte, har du hittat ett domänomfångsproblem i resolvern och inte ett routingproblem. Skriv ned vilket tillstånd du hittade, för nästa nätverksändring kommer att återge det du lämnade ifred.