Slik skiller du VPN-skubbede ruter fra statiske på Linux

Et prefiks dukker opp på laptopen når tunnelen kommer opp, så det føles som om VPN-en installerte det. Det kan den ha gjort, men samme resultat kan komme fra et klientskript som kjører ved tilkobling, en tilkoblingsprofil som lister opp subnettet, eller en statisk rute som var der hele tiden og først begynte å virke da grensesnittet fantes. Velger du feil eier, kommer ruten tilbake etter hver opprydding, og neste person gjentar samme rettelse. Sekvensen nedenfor skiller de tre før noe endres.

Trinn 1: navngi mekanismen som installerer prefikser

Ulike protokoller gir tilgjengelighet på ulike måter, og å kalle alt dette en annonsering skjuler forskjellen. En OpenVPN-server skyver et rutedirektiv over kontrollkanalen, og klienten installerer det med mindre et pull-filter blokkerer det. En WireGuard-konfigurasjon lister opp tillatte prefikser lokalt, som klienten bruker både til kryptonøkkelrutting og til rutene den legger til. En IPsec-tunnel avtaler trafikkvelgere med motparten, og kjernen installerer ruter fra disse velgerne.

Finn ut hvilken av disse tunnelen din bruker før du leser noen tabell. En rute som skyves ved tilkobling, er ikke en annonsering fra en rutingsprotokoll og lover ikke at prefikset er nåbart bak den fjerne enden. Noter mekanismen ved siden av prefikset, for den avgjør hvor rettelsen hører hjemme.

Trinn 2: sammenlign tabellen gjennom en tilkobling

Lagre hovedtabellen med tunnelen nede, ta den opp, lagre igjen og sammenlign de to opptakene. Alt som dukket opp, hører til tilkoblingens livssyklus, og alt som ble igjen, hører til den lokale konfigurasjonen.

Ta opp med ip route show table main > /tmp/route-down.txt, koble til og ta opp igjen. Gjør det samme for ip -6 route hvis nettstedet bruker IPv6, fordi et manglende prefiks der gir feil som ser ut til å ikke ha med rutting å gjøre.

Trinn 3: les metrikken, ikke bare tilstedeværelsen

To oppføringer for samme prefiks kan eksistere samtidig, og kjernen velger den laveste metrikken. En statisk rute med metrikk 50 vil fortsette å slå en skubbet rute på 100 selv om begge er synlige, og derfor er «ruten er der» og «trafikken bruker den» forskjellige påstander.

Spør kjernen direkte med ip route get 10.20.5.7 og les grensesnittet den rapporterer. Hvis trafikken går ut gjennom den fysiske adapteren mens en tunnelrute sitter i tabellen, forklarer metrikken eller prefikslengden det, ikke VPN-klienten. Gjenta oppslaget for en vert du vet ligger bak tunnelen, og en du vet ikke gjør det, og forskjellen viser om delingen oppfører seg som tenkt.

Trinn 4: finn oppføringene som overlever tunnelen

Statiske ruter overlever en frakobling ved design, og det er der foreldede oppføringer kommer fra. En permanent rute mot et grensesnitt som ikke finnes lenger, kan svelge et subnett i stillhet, og en mot et gjenbrukt grensesnittnavn kan etter en omstart sende privat trafikk ut gjennom feil dør.

Sjekk den permanente siden på stedet distribusjonen din bruker, enten det er en systemd-networkd-enhet, en NetworkManager-profil eller et skript i klientens up-katalog. Å rette den levende tabellen med ip route del holder bare til neste tilkobling. Behandle den slettingen som en test av hypotesen og ikke som reparasjonen.

Der den fjerne enden gir feil dekning, ta det opp med operatøren i stedet for å filtrere alt. Å droppe alle skubbede innstillinger kaster også DNS og split-tunnel-policy som profilen er avhengig av.

Trinn 5: bekreft returveien før du klandrer klienten

For nettsted-til-nettsted eller et subnett bak tunnelen trenger den fjerne siden en rute tilbake til klientadressen din og videresending aktivert på gatewayen. En enveisvei ser nøyaktig ut som en klientrutingsfeil, bortsett fra at håndtrykket og den utgående pakken begge lykkes.

Filtrering av returveien legger en ny felle på Linux-gatewayer. Et svar som ankommer på et annet grensesnitt enn ruten forutsier, blir droppet i streng modus, og asymmetriske veier gjennom to leverandører utløser det pålitelig. Drop-tellerne på gatewayen, ikke på klienten, forteller deg om filtreringen er årsaken.

Trinn 6: test ressursen, ikke pinget

Når den valgte ruten er riktig, åpne den faktiske ressursen og bekreft returtrafikken. Et ping-svar beviser veien i én retning og ingenting om tjenesten, og en tjeneste som svarer på en bufret tilkobling beviser enda mindre.

Gjenta så hele kontrollen etter en ny tilkobling. Verdien av sekvensen er at den forutsier hva neste tilkobling vil gjøre, og derfor hører både sammenligningen og metrikken hjemme i billetten.