Sådan skelner du VPN-skubbede ruter fra statiske på Linux

Et præfiks dukker op på laptop'en, når tunnelen kommer op, så det føles, som om VPN'en installerede det. Det kan den have gjort, men det samme resultat kan komme fra et klient-script, der kører ved forbindelse, en forbindelsesprofil, der lister undernettet, eller en statisk rute, der var der hele tiden og først begyndte at virke, da interfacet fandtes. Vælger du den forkerte ejer, kommer ruten tilbage efter hver oprydning, og den næste person gentager den samme rettelse. Sekvensen nedenfor adskiller de tre, før noget ændres.

Trin 1: navngiv den mekanisme, der installerer præfikser

Forskellige protokoller leverer tilgængelighed på forskellige måder, og at kalde det hele en annoncering skjuler forskellen. En OpenVPN-server skubber et rutedirektiv gennem kontrolkanalen, og klienten installerer det, medmindre et pull-filter blokerer det. En WireGuard-konfiguration lister tilladte præfikser lokalt, som klienten bruger både til kryptonøgle-routing og til de ruter, den tilføjer. En IPsec-tunnel aftaler trafikvælgere med peer'en, og kernen installerer ruter ud fra disse vælgere.

Afgør, hvilken af dem din tunnel bruger, før du læser nogen tabel. En rute, der skubbes ved forbindelse, er ikke en annoncering fra en routingprotokol og lover ikke, at præfikset kan nås bag den fjerne ende. Notér mekanismen ved siden af præfikset, for den afgør, hvor rettelsen hører til.

Trin 2: sammenlign tabellen hen over en forbindelse

Gem hovedtabellen med tunnelen nede, bring den op, gem igen, og sammenlign de to optagelser. Alt, der dukkede op, hører til forbindelsens livscyklus, og alt, der blev, hører til den lokale konfiguration.

Optag den med ip route show table main > /tmp/route-down.txt, forbind, og optag igen. Gør det samme for ip -6 route, hvis stedet bruger IPv6, fordi et manglende præfiks der giver fejl, der ser ud til ikke at have med routing at gøre.

Trin 3: læs metrikken, ikke bare tilstedeværelsen

To poster for samme præfiks kan eksistere samtidig, og kernen vælger den lavere metrik. En statisk rute med metrik 50 vil blive ved med at vinde over en skubbet rute på 100, selv om begge er synlige, og derfor er 'ruten er der' og 'trafikken bruger den' forskellige udsagn.

Spørg kernen direkte med ip route get 10.20.5.7 og læs det interface, den rapporterer. Hvis trafikken forlader gennem den fysiske adapter, mens en tunnelrute ligger i tabellen, forklarer metrikken eller præfiksets længde det, ikke VPN-klienten. Gentag opslaget for en vært, du ved ligger bag tunnelen, og en, du ved ikke gør, og forskellen viser, om opdelingen opfører sig som tilsigtet.

Trin 4: find de poster, der overlever tunnelen

Statiske ruter overlever en afbrydelse ved design, og det er der, forældede poster kommer fra. En permanent rute, der peger på et interface, som ikke findes længere, kan lydløst sluge et undernet, og en, der peger på et genbrugt interfacenavn, kan efter en genstart sende privat trafik ud ad den forkerte dør.

Tjek den permanente side på det sted, din distribution bruger, hvad enten det er en systemd-networkd-unit, en NetworkManager-profil eller et script i klientens up-mappe. At rette den levende tabel med ip route del holder kun til næste forbindelse. Behandl den sletning som en test af hypotesen snarere end som reparationen.

Hvor den fjerne ende leverer den forkerte dækning, bring det op hos operatøren i stedet for at filtrere alt. At droppe alle skubbede indstillinger kasserer også DNS og split-tunnel-politik, som profilen afhænger af.

Trin 5: bekræft returvejen, før du bebrejder klienten

For site-til-site eller et undernet bag tunnelen skal den fjerne side have en rute tilbage til din klientadresse og videresendelse aktiveret på gatewayen. En envejsvej ser præcis ud som en klient-routingfejl, bortset fra at handshaket og den udgående pakke begge lykkes.

Filtrering af returvejen tilføjer en anden fælde på Linux-gateways. Et svar, der ankommer på et andet interface, end ruten forudsiger, bliver droppet af streng tilstand, og asymmetriske veje gennem to udbydere udløser det pålideligt. Drop-tællerne på gatewayen, ikke på klienten, fortæller, om filtrering er årsagen.

Trin 6: test ressourcen, ikke pinget

Når den valgte rute er korrekt, åbn den faktiske ressource, og bekræft returtrafikken. Et ping-svar beviser vejen i én retning og intet om tjenesten, og en tjeneste, der svarer på en cachet forbindelse, beviser endnu mindre.

Gentag derefter hele kontrollen efter en genforbindelse. Værdien af sekvensen er, at den forudsiger, hvad den næste forbindelse vil gøre, og derfor hører både sammenligningen og metrikken hjemme i billetten.