Varför en borttagen VPN-väg kommer tillbaka efter återanslutning

Att ta bort en aktiv väg ändrar ingenting när en profil, en push eller en uppstartsenhet skapar den igen. Hitta ägaren, ändra det där och verifiera vid en återanslutning.

En väg som du tog bort manuellt är tillbaka efter nästa återanslutning, och tabellen ser exakt ut som tidigare. Det här är inte en routingbugg: något återskapar posten från konfigurationen eller från en åtgärd i anslutningens livscykel. De flesta runbooks stannar vid den aktiva tabellen, och därför verkar borttagningen fungera i en minut och misslyckas sedan. Identifiera ägaren, ändra den och bevisa det vid en återanslutning.

Vem installerade vägen

Börja med en lista över kandidater i stället för med en rättelse. En VPN-profil kan bära sina egna vägar, en server kan pusha dem vid anslutning, en nätverkshanterarprofil kan deklarera dem, en uppstartsenhet eller ett skript kan lägga till dem, och IPsec-implementeringar installerar vägar för de trafikväljare de förhandlar om. Policy-routingregler kan också omdirigera trafik helt till en annan tabell.

Tidpunkten skiljer dem snabbare än konfigurationsarkeologi. En post som dyker upp i samma stund som gränssnittet kommer upp tillhör klienten; en som anländer en sekund senare kom oftast från en server-push; en som finns vid uppstart tillhör den sparade konfigurationen. Registrera tabellen före och efter en anslutning, en frånkoppling och en omstart, och mönstret namnger ägaren. En väg som bara kommer tillbaka när tjänsten startar om pekar på en enhet och inte på VPN:en.

Läs tabellen innan du redigerar den

Titta på kärnans egen vy i stället för en sparad fil. Protokollkolumnen visar vad som installerade varje post:

ip route show
ip route show table all
ip rule show

Protokollfältet, metriken och tabellnumret berättar om du tittar på en statisk post, en kärnskapad post eller något som en daemon har lagt till. Regellistan spelar roll eftersom en sökning helt kan lämna huvudtabellen, vilket gör en ändring där osynlig för programmet du felsöker. Läs raden från vänster till höger: destination, gateway, enhet, protokoll och metrik.

Fråga sedan kärnan vilken väg den faktiskt skulle använda. En skyddad adress är en bättre sond än en offentlig:

ip route get 10.20.5.7

Ändra ägaren, inte symptomet

När ägaren är känd hör ändringen till den ägaren. Ta bort vägen från klientprofilen, rätta den pushade vägen på servern eller redigera nätverkshanterarens anslutning i stället för att lägga till en konkurrerande permanent väg som vinner på metrik. Två regler som slåss mot varandra ger en tabell som ingen senare kan förklara.

Behåll undantaget för slutpunkten. En värdväg som skickar VPN-serverns egen offentliga adress genom den fysiska gatewayen är det som håller de yttre tunnelpaketen i flöde; tar du bort den försöker tunneln bära sig själv. På en split-tunnel-profil gäller samma omsorg för de lokala subnäten som ska gå förbi tunneln.

Anslut igen och verifiera båda vägarna

Anslut igen och kontrollera sedan båda destinationerna i en enda genomgång. Den skyddade adressen och den undantagna slutpunkten svarar på olika frågor:

ip route get 10.20.5.7
ip route get 198.51.100.20

Den första bör lösas via tunnelgränssnittet och den andra via den fysiska gatewayen. Om båda löses via tunneln saknas undantaget; om ingen gör det har profiländringen inte trätt i kraft och du tittar på en annan ägare än du trodde.

Skriv ner vägens syfte, dess ägare och hur länge den bör leva. Den anteckningen är det som hindrar nästa person från att upprepa samma borttagnings- och återanslutningscykel.

Relaterade artiklar