Korleis skilje VPN-skubba ruter frå statiske på Linux

Eit prefiks dukkar opp på laptoppen når tunnelen kjem opp, så det kjennest som om VPN-en installerte det. Det kan han ha gjort, men same resultat kan kome frå eit klientskript som køyrer ved tilkopling, ein tilkoplingsprofil som listar opp subnettet, eller ei statisk rute som var der heile tida og først byrja å verke då grensesnittet fanst. Vel du feil eigar, kjem ruta tilbake etter kvar opprydding, og neste person gjer same rettinga om att. Sekvensen nedanfor skil dei tre før noko vert endra.

Steg 1: nemn mekanismen som installer prefiks

Ulike protokollar gjev tilgjenge på ulike måtar, og å kalle alt dette ein annonsering gøymer skilnaden. Ein OpenVPN-tenar skuvar eit rutedirektiv over kontrollkanalen, og klienten installer det med mindre eit pull-filter blokkerer det. Ein WireGuard-konfigurasjon listar opp tillatne prefiks lokalt, som klienten nyttar både til kryptonøkkelrutting og til rutene han legg til. Ein IPsec-tunnel avtalar trafikkveljarar med motparten, og kjernen installer ruter frå desse veljarane.

Finn ut kva av desse tunnelen din nyttar før du les noka tabell. Ei rute som vert skuva ved tilkopling, er ikkje ein annonsering frå ein rutingsprotokoll og lovar ikkje at prefikset er nåbart bak den fjerne enden. Noter mekanismen ved sida av prefikset, for han avgjer kvar rettinga høyrer heime.

Steg 2: samanlikn tabellen gjennom ei tilkopling

Lagre hovudtabellen med tunnelen nede, ta han opp, lagre igjen og samanlikn dei to opptaka. Alt som dukka opp, høyrer til livssyklusen til tilkoplinga, og alt som vart att, høyrer til den lokale konfigurasjonen.

Tak opp med ip route show table main > /tmp/route-down.txt, kople til og tak opp igjen. Gjer det same for ip -6 route om nettstaden nyttar IPv6, fordi eit manglande prefiks der gjev feil som ser ut til å ikkje ha med rutting å gjere.

Steg 3: les metrikken, ikkje berre tilstadeværet

To oppføringar for same prefiks kan eksistere samstundes, og kjernen vel den lågaste metrikken. Ei statisk rute med metrikk 50 vil halde fram med å slå ei skuva rute på 100 sjølv om begge er synlege, og difor er «ruta er der» og «trafikken nyttar henne» ulike påstandar.

Spør kjernen direkte med ip route get 10.20.5.7 og les grensesnittet han rapporterer. Går trafikken ut gjennom den fysiske adapteren medan ei tunnelrute sit i tabellen, forklarer metrikken eller prefikslengda det, ikkje VPN-klienten. Gjenta oppslaget for ein vert du veit ligg bak tunnelen, og ein du veit ikkje gjer det, og skilnaden viser om delinga oppfører seg som tenkt.

Steg 4: finn oppføringane som overlever tunnelen

Statiske ruter overlever ein fråkopling ved design, og det er der forelda oppføringar kjem frå. Ei permanent rute mot eit grensesnitt som ikkje finst lenger, kan svelgje eit subnett i stillheit, og ei mot eit gjenbrukt grensesnittnamn kan etter ein omstart sende privat trafikk ut gjennom feil dør.

Sjekk den permanente sida på staden distribusjonen din nyttar, anten det er ein systemd-networkd-eining, ein NetworkManager-profil eller eit skript i up-katalogen til klienten. Å rette den levande tabellen med ip route del held berre til neste tilkopling. Handsame den slettinga som ein test av hypotesen og ikkje som reparasjonen.

Der den fjerne enden gjev feil dekning, ta det opp med operatøren i staden for å filtrere alt. Å droppe alle skuva innstillingar kastar også DNS og split-tunnel-policy som profilen er avhengig av.

Steg 5: stadfest returvegen før du klandrar klienten

For nettstad-til-nettstad eller eit subnett bak tunnelen treng den fjerne sida ei rute tilbake til klientadressa di og vidaresending slått på i gatewayen. Ein einvegveg ser nøyaktig ut som ein klientrutingsfeil, bortsett frå at handtrykket og den utgåande pakken båe lukkast.

Filtrering av returvegen legg ei ny felle på Linux-gatewayar. Eit svar som kjem inn på eit anna grensesnitt enn ruta føreseier, vert droppa i streng modus, og asymmetriske vegar gjennom to leverandørar utløyser det påliteleg. Drop-teljarane på gatewayen, ikkje på klienten, fortel deg om filtreringa er årsaka.

Steg 6: test ressursen, ikkje pinget

Når den valde ruta er rett, opne den faktiske ressursen og stadfest returtrafikken. Eit ping-svar beviser vegen i éin retning og ingenting om tenesta, og ei teneste som svarar på ei buftra tilkopling beviser endå mindre.

Gjenta så heile kontrollen etter ei ny tilkopling. Verdien av sekvensen er at han føreseier kva neste tilkopling vil gjere, og difor høyrer både samanlikninga og metrikken heime i billetten.