Kial unu subreto ankoraŭ preteriras la implicitan vojon de via VPN

Vi ŝaltas la VPN al plena tunelo, la plej multo de la trafiko obeas, kaj tiam unu adreso respondas rekte — printilo, NAS, saltgastiganto ĉe 10.x. La evidenta legado estas, ke la tunelo likas, do vi malaltigas la metrikon de la implicita vojo kaj nenio ŝanĝiĝas. Tiu malsukcesa provo estas la ŝlosilo: implicita vojo estas rezervo, ne verdikto. La vojserĉo prenas la plej longan kongruan prefikson antaŭ ol ĝi iam ajn komparas metrikojn, do /24 daŭre venkas kontraŭ /0, kiun ajn numeron vi alkroĉas al iu el ili. Post kiam tiu ordo klaras, la liko kutime estas vojo, kiun iu instalis intence, aŭ prefikso, kiun la kliento neniam celis kovri.

Kion implicita vojo efektive promesas

0.0.0.0/0 kongruas kun ĉiu IPv4-celo kun nulo da bitoj de specifeco. Ĝi ekzistas por ke gastiganto povu atingi ion ajn, kion ĝia tabelo ne priskribas pli bone. Vojo al 192.168.1.0/24 portas 24 kongruajn bitojn, do por 192.168.1.40 ĝi venkas antaŭ ol iu komparas metrikojn, administran distancon aŭ kiel ajn la kliento nomas sian prioritatan kampon. La sama regulo validas en la Linux-FIB, la Windows-voja tabelo kaj la BSD-stako malantaŭ macOS.

En normala LAN tiu konduto estas trajto. La loka subreto estas rekte alligita, la printilo daŭre funkcias dum la tunelo portas vian retumadon, kaj nenio estas mise agordita. La demando inda je starigo ne estas, kial tiu unu adreso iras rekte, sed kiu prefikso en kiu tabelo kongruas kun ĝi, kaj kiu metis ĝin tie.

Duon-implicitaj vojoj, aŭ kial la implicita ero povas ŝajni netuŝita

La plej pura ekzemplo estas redirect-gateway def1 ĉe OpenVPN. Anstataŭ forigi vian implicitan vojon kaj anstataŭigi ĝin, ĝi aldonas 0.0.0.0/1 kaj 128.0.0.0/1. Kune la paro kovras la tutan IPv4, ĉiu prefikso estas pli longa ol /0, kaj ambaŭ venkas la implicitan vojon de la enkursigilo dum ili lasas ĝin surloke. Rulu vojan listigon poste kaj la originala implicita vojo ankoraŭ estas tie, ankoraŭ montras al via kluzo; ĝi simple neniam estas elektita por interretaj celoj.

wg-quick de WireGuard atingas la saman rezulton per politika enkursigado. Kiam AllowedIPs kovras 0.0.0.0/0, ĝi kreas sian propran tabelon, sendas markitajn pakaĵojn tien, kaj aldonas regulon, kiu ignoras la nul-longan prefikson de la ĉefa tabelo. La ĉefa tabelo konservas sian implicitan eron, kaj la reguloj decidas, ke la tunela tabelo estas konsultata unue por la trafiko, kiun la interfaco posedas.

Ambaŭ dezajnoj bezonas ekzakte unu vojon ekster la tunelo: gastigantan vojon al la propra adreso de la VPN-servilo tra la origina kluzo. Sen ĝi la kliento provus porti la pakaĵojn, kiuj konstruas la tunelon, ene de la tunelo, kaj la konekto neniam finiĝus. Ne-tunela vojo en via tabelo do estas normala eĉ ĉe strikta plen-tunela profilo. La vojoj indaj je pridemandado estas tiuj, kiuj kovras celojn, pri kiuj vi vere zorgas.

Metrikoj decidas egalecojn, prefiksoj decidas venkintojn

Metrikoj estas komparataj nur inter kandidatoj, kiuj egale bone kongruas kun la celo. En Linux, ip route get 10.20.5.9 presas la venkinton kune kun ĝia tabelo, kaj ip route show table all listigas la kandidatojn, inkluzive de iuj ajn duon-implicitaj vojoj kaj iu ajn tabelo, al kiu montras regulo. En Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 revenigas la elektitan vojon kaj fontan adreson, dum Get-NetRoute montras la krudan tabelon — sed la efektiva kosto estas voja metriko plus interfaca metriko, do malrapida adaptilo povas perdi egalecon, kiun ĝi ŝajne gajnas.

Tri kazoj kovras la plej multon de tio, kion vi vidos:

• Sama celo, /24 kontraŭ /0: la /24 venkas pro prefiksa longo, kion ajn diras la metrikoj.
• Sama celo, du /24-oj kun malsamaj metrikoj: la pli malalta efektiva metriko venkas.
• Sama celo, du tabeloj, unu elektita de politika regulo: la regulo unue elektas la tabelon, kaj prefiksa komparo okazas ene de ĝi.

La tria kazo estas, kie finiĝas la plej multo de ĉi tiuj raportoj. Linuxa ip rule aŭ Windows-VPN-trafika filtrilo povas sendi trafikon al tabelo, kiu neniam tenis la implicitan vojon de la tunelo, kaj la ĉefa tabelo aspektas perfekta la tutan tempon.

Kiu kutime posedas la preteriron

Komencu per la profilo, ne per la tabelo. Split-tunnel-agordoj kaj VPN-agordoj por unuopa aplikaĵo intence lasas nomitajn prefiksojn ekster la tunelo; labora profilo, kiu protektas unu privatan subreton kaj lasas ĝeneralan retumadon iri rekte, kondutas kiel dizajnite, kaj superregi ĝin rompas la politikon, kiun ĝi devis plenumi. La gvidilo pri VPN-enkursigado de Microsoft tiras la saman linion inter devige tunelita trafiko kaj eksplicitaj esceptoj, kio igas ĝin utila kruca kontrolo antaŭ ol vi redaktas ion ajn.

Poste serĉu restaĵojn. Vojo montranta al interfaco, kiu ne plu ekzistas, aŭ al adreso el la antaŭa reto, aperas post kiam dokstacioj, USB-adaptiloj kaj konteneraj pontoj venas kaj foriras. Forigi ĝin unufoje ne estas la fino: NetworkManager-konektaj profiloj, netplan-dosieroj kaj persistentaj Windows-vojoj reinstalas ĝin ĉe la sekva konekto aŭ ekfunkciigo, do trovu la dosieron aŭ profilon, kiu posedas ĝin, antaŭ ol redakti ion ajn.

Tiam kontrolu IPv6 aparte. ip -6 route kaj Get-NetRoute -AddressFamily IPv6 tenas apartan staton, apartajn implicitajn vojojn kaj apartan klientan konduton. Aŭdo nur de IPv4 diras nenion pri duobla-staka gastiganto, kiu silente preferas indiĝenan IPv6-vojon, kaj tio sola povas igi klienton aspekti split-tunnel.

Konfirmu per la propra fluo de la aplikaĵo

Notu la celon, kiun la aplikaĵo efektive uzas, poste demandu la sistemon pri la vojo, kiun ĝi prenus de la fonta adreso, al kiu tiu aplikaĵo ligiĝas. ip route get 10.20.5.9 from 192.168.1.40 respondas tion en Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus la loka adreso faras tion en Windows. Komparu la rezulton kun tio, kion asertas la profilo. La publika-IP-paĝo de retumilo testas unu celon per unu protokolo kaj diras nenion pri la privata adreso, kiu komencis la plendon.

Riparu la plej mallarĝan objekton, kiu klarigas la diferencon. Se la escepto estas aprobita, skribu la prefikson kaj lasu ĝin; se ne, forigu la vojon aŭ aldonu eksplicitan pli mallarĝan vojon tra la tunelo anstataŭ malaltigi la metrikon de la implicita vojo. Malaltigi metrikon ne povas superi pli longan prefikson, kaj redakti la implicitan vojon dum du /1-vojoj posedas la interretan vojon ankaŭ ŝanĝas nenion.

Poste rekonektu la tunelon kaj ripetu la saman demandon. Klientoj reinstalas vojojn ĉe ĉiu konekto, do ŝanĝo, kiu daŭras nur ĝis la sekva manpremo, ne estis testita. Se la vojo ankoraŭ malkongruas, la restantaj suspektatoj estas politika regulo, dua tabelo aŭ klientflanka filtrilo — ne la implicita vojo.

• Nomu la celon kaj la fontan adreson, kiujn la aplikaĵo vere uzas.
• Presu la venkan vojon per ip route get aŭ Find-NetRoute.
• Kontrolu, ĉu /1-paro aŭ politika tabelo posedas la interretan vojon.
• Listigu ĉiun prefikson pli longan ol /0, kiu kongruas kun la celo.
• Ripetu la IPv6-kontrolon aparte.
• Spuru la postvivantan vojon reen al la dosiero, profilo aŭ filtrilo, kiu instalas ĝin.
• Rekonektu kaj rerulu la demandon antaŭ ol nomi ĝin riparita.

Se ĉiuj sep kongruas kun la profilo, la tunelo faras ĝuste tion, por kio ĝi estis agordita, kaj la riparo apartenas al la profilo, ne al metriko.