Så skiljer du VPN-skickade rutter från statiska på Linux

Ett prefix dyker upp på laptopen när tunneln kommer upp, så det känns som om VPN:en installerade det. Det kan den ha gjort, men samma resultat kan komma från ett klientskript som körs vid anslutning, en anslutningsprofil som listar subnätet, eller en statisk rutt som fanns där hela tiden och började fungera först när gränssnittet fanns. Fel ägare innebär att rutten kommer tillbaka efter varje städning, och nästa person upprepar samma åtgärd. Sekvensen nedan skiljer de tre åt innan något ändras.

Steg 1: namnge mekanismen som installerar prefix

Olika protokoll ger nåbarhet på olika sätt, och att kalla allt detta en annonsering döljer skillnaden. En OpenVPN-server skickar ett rutdirektiv över kontrollkanalen och klienten installerar det om inte ett pull-filter blockerar det. En WireGuard-konfiguration listar tillåtna prefix lokalt, som klienten använder både för kryptonyckelrouting och för de rutter den lägger till. En IPsec-tunnel förhandlar trafikväljare med motparten, och kärnan installerar rutter från dessa väljare.

Ta reda på vilken av dessa din tunnel använder innan du läser någon tabell. En rutt som skickas vid anslutning är inte en annonsering från ett routingprotokoll och lovar inte att prefixet är nåbart bakom den bortre änden. Anteckna mekanismen bredvid prefixet, för den avgör var åtgärden hör hemma.

Steg 2: jämför tabellen genom en anslutning

Spara huvudtabellen med tunneln nere, ta upp den, spara igen och jämför de två fångsterna. Allt som dök upp hör till anslutningens livscykel, och allt som blev kvar hör till den lokala konfigurationen.

Fånga den med ip route show table main > /tmp/route-down.txt, anslut och fånga igen. Gör samma sak för ip -6 route om webbplatsen använder IPv6, eftersom ett saknat prefix där ger fel som verkar orelaterade till routing.

Steg 3: läs metriken, inte bara förekomsten

Två poster för samma prefix kan finnas samtidigt, och kärnan väljer den lägre metriken. En statisk rutt med metrik 50 fortsätter att vinna över en skickad rutt på 100 även om båda syns, och därför är 'rutten finns där' och 'trafiken använder den' olika påståenden.

Fråga kärnan direkt med ip route get 10.20.5.7 och läs det gränssnitt den rapporterar. Om trafiken går ut genom det fysiska nätverkskortet medan en tunnelrutt sitter i tabellen, förklarar metriken eller prefixlängden det, inte VPN-klienten. Upprepa sökningen för en värd du vet ligger bakom tunneln och en du vet inte gör det, och skillnaden visar om delningen beter sig som avsett.

Steg 4: hitta posterna som överlever tunneln

Statiska rutter överlever en frånkoppling enligt design, och det är därifrån inaktuella poster kommer. En permanent rutt mot ett gränssnitt som inte längre finns kan svälja ett subnät i tysthet, och en mot ett återanvänt gränssnittsnamn kan efter en omstart skicka privat trafik genom fel dörr.

Kontrollera den permanenta sidan på den plats din distribution använder, vare sig det är en systemd-networkd-enhet, en NetworkManager-profil eller ett skript i klientens up-katalog. Att rätta den levande tabellen med ip route del håller bara till nästa anslutning. Behandla den borttagningen som ett test av hypotesen och inte som reparationen.

Där den bortre änden ger fel täckning, ta upp det med operatören i stället för att filtrera allt. Att släppa alla skickade inställningar kastar också bort DNS och split-tunnelpolicy som profilen är beroende av.

Steg 5: bekräfta returvägen innan du skyller på klienten

För site-till-site eller ett subnät bakom tunneln behöver den bortre sidan en rutt tillbaka till din klientadress och vidarebefordran aktiverad på gatewayen. En enkelriktad väg ser exakt ut som ett klientroutningsfel, förutom att handskakningen och det utgående paketet båda lyckas.

Filtrering av returvägen lägger en andra fälla på Linux-gatewayer. Ett svar som anländer på ett annat gränssnitt än rutten förutser släpps i strikt läge, och asymmetriska vägar genom två leverantörer utlöser det pålitligt. Droppräknarna på gatewayen, inte på klienten, berättar om filtreringen är orsaken.

Steg 6: testa resursen, inte pinget

När den valda rutten är korrekt, öppna den faktiska resursen och bekräfta returtrafiken. Ett ping-svar bevisar vägen i en riktning och ingenting om tjänsten, och en tjänst som svarar på en cachad anslutning bevisar ännu mindre.

Upprepa sedan hela kontrollen efter en återanslutning. Värdet med sekvensen är att den förutsäger vad nästa anslutning kommer att göra, och därför hör både jämförelsen och metriken hemma i ärendet.