Kiel distingi VPN-puŝitajn vojojn de statikaj sur Linux

Prefikso aperas sur la tekkomputilo kiam la tunelo ekfunkcias, do ŝajnas, ke la VPN instalis ĝin. Eble jes, sed la sama rezulto povas veni de klienta skripto, kiu ruliĝas ĉe konekto, de konekta profilo, kiu listigas la subreton, aŭ de statika vojo, kiu estis tie la tutan tempon kaj ekfunkciis nur kiam la interfaco ekzistis. Elekti la malĝustan posedanton signifas, ke la vojo revenas post ĉiu purigado, kaj la sekva persono ripetas la saman riparon. La jena sinsekvo apartigas la tri antaŭ ol ŝanĝi ion ajn.

Paŝo 1: nomu la mekanismon, kiu instalas prefiksojn

Diversaj protokoloj provizas atingeblon diversmaniere, kaj nomi ĉion ĉi anonco kaŝas la distingon. OpenVPN-servilo puŝas voj-direktivon tra la regkanalo kaj la kliento instalas ĝin, se pull-filtrilo ne blokas ĝin. WireGuard-agordo listigas permesitajn prefiksojn loke, kiujn la kliento uzas kaj por kriptoŝlosila enkursigo kaj por la vojoj, kiujn ĝi aldonas. IPsec-tunelo interkonsentas trafikselektilojn kun la samtavolano, kaj la kerno instalas vojojn el tiuj selektiloj.

Identigu, kiun el tiuj uzas via tunelo, antaŭ ol legi ajnan tabelon. Vojo puŝita ĉe konekto ne estas anonco de enkursiga protokolo, kaj ĝi promesas nenion, ke la prefikso estas atingebla malantaŭ la malproksima fino. Notu la mekanismon apud la prefikso, ĉar ĝi decidas, kie apartenas la riparo.

Paŝo 2: komparu la tabelon tra unu konekto

Konservu la ĉefan tabelon kun la tunelo mallevita, levu ĝin, konservu denove kaj komparu la du registraĵojn. Ĉio, kio aperis, apartenas al la vivociklo de la konekto, kaj ĉio, kio restis, apartenas al loka agordo.

Registru ĝin per ip route show table main > /tmp/route-down.txt, konektiĝu kaj registru denove. Faru la samon por ip -6 route se la ejo uzas IPv6, ĉar mankanta prefikso tie produktas paneojn, kiuj aspektas neligitaj al enkursigo.

Paŝo 3: legu la metrikon, ne nur la ĉeeston

Du enskriboj por la sama prefikso povas kunekzisti, kaj la kerno elektas la pli malaltan metrikon. Statika vojo kun metriko 50 daŭre venkos puŝitan vojon je 100, kvankam ambaŭ videblas, kaj tial «la vojo estas tie» kaj «la trafiko uzas ĝin» estas malsamaj asertoj.

Demandu la kernon rekte per ip route get 10.20.5.7 kaj legu la interfacon, kiun ĝi raportas. Se trafiko eliras tra la fizika adaptilo dum tunela vojo sidas en la tabelo, la metriko aŭ la prefiksa longo klarigas tion, ne la VPN-kliento. Ripetu la serĉon por gastiganto, pri kiu vi scias, ke ĝi vivas malantaŭ la tunelo, kaj por unu, pri kiu vi scias, ke ne, kaj la diferenco montras, ĉu la divido kondutas kiel celite.

Paŝo 4: trovu la enskribojn, kiuj postvivas la tunelon

Statikaj vojoj postvivas malkonekton laŭdizajne, kaj de tie venas kadukaj enskriboj. Daŭra vojo montranta al interfaco, kiu ne plu ekzistas, povas silente engluti subreton, kaj unu montranta al reuzita interfaca nomo povas post rekomenco sendi privatan trafikon tra la malĝusta pordo.

Kontrolu la daŭran flankon en la loko, kiun via distribuo uzas, ĉu temas pri systemd-networkd-unuo, NetworkManager-profilo aŭ skripto en la up-dosierujo de la kliento. Ripari la vivan tabelon per ip route del teniĝas nur ĝis la sekva konekto. Traktu tiun forigon kiel teston de la hipotezo, ne kiel la riparon.

Kie la malproksima fino provizas la malĝustan kovradon, levu tion ĉe la operatoro anstataŭ filtri ĉion. Forĵeti ĉiujn puŝitajn agordojn ankaŭ forĵetas DNS kaj dividitan tunelpolitikon, de kiuj la profilo dependas.

Paŝo 5: konfirmu la revenan vojon antaŭ ol kulpigi la klienton

Por ejo-al-ejo aŭ subreto malantaŭ la tunelo, la malproksima flanko bezonas vojon reen al via klienta adreso kaj ebligitan plusendadon sur la pordego. Unudirekta vojo aspektas ĝuste kiel klienta enkursiga cimo, krom ke la manpremo kaj la elira pako ambaŭ sukcesas.

Inversvoja filtrado aldonas duan kaptilon sur Linux-pordegoj. Respondo alvenanta sur alia interfaco ol la vojo antaŭvidas estas forĵetata de strikta reĝimo, kaj nesimetriaj vojoj tra du provizantoj fidinde ekigas ĝin. La forĵetnombriloj sur la pordego, ne sur la kliento, diras al vi, ĉu filtrado estas la kaŭzo.

Paŝo 6: testu la rimedon, ne la ping

Post kiam la elektita vojo ĝustas, malfermu la realan rimedon kaj konfirmu la revenan trafikon. Ping-respondo pruvas la vojon en unu direkto kaj nenion pri la servo, kaj servo respondanta sur kaŝmemorigita konekto pruvas eĉ malpli.

Poste ripetu la tutan kontrolon post rekonekto. La valoro de la sinsekvo estas, ke ĝi antaŭdiras, kion faros la sekva konekto, kaj tial kaj la komparo kaj la metriko apartenas al la bileto.