Miks üks alamvõrk möödub endiselt VPN-i vaikimisi marsruudist

Lülitate VPN-i täistunnelile, suurem osa liiklusest kuuletub, ja siis vastab üks aadress otse — printer, NAS, hüppemasin aadressil 10.x. Ilmselge tõlgendus on, et tunnel lekib, seega langetate vaikimisi marsruudi mõõdikut ja miski ei muutu. See ebaõnnestunud katse on vihje: vaikimisi marsruut on varuvariant, mitte otsus. Marsruudiotsing võtab pikima sobiva prefiksi, enne kui üldse mõõdikuid võrdleb, seega /24 võidab /0 vastu ikka, ükskõik millise numbri te neist kummagi külge kinnitate. Kui see järjekord on selge, on leke tavaliselt marsruut, mille keegi sihilikult paigaldas, või prefiks, mida klient ei kavatsenudki katta.

Mida vaikimisi marsruut tegelikult lubab

0.0.0.0/0 sobib iga IPv4-sihtkohaga null bitti spetsiifilisust. See on olemas selleks, et host pääseks kõigele, mida tema tabel paremini ei kirjelda. Marsruut 192.168.1.0/24-ni kannab 24 sobivat bitti, seega 192.168.1.40 puhul võidab see enne, kui keegi võrdleb mõõdikuid, administratiivset kaugust või kuidas klient oma prioriteedivälja ka ei nimetaks. Sama reegel kehtib Linuxi FIB-is, Windowsi marsruutimistabelis ja macOS-i taga olevas BSD-pinus.

Tavalises LAN-is on see käitumine omadus. Kohalik alamvõrk on otse ühendatud, printer töötab edasi, samal ajal kui tunnel kannab teie veebilehitsemist, ja miski pole valesti seadistatud. Küsimus, mida tasub küsida, pole see, miks too üks aadress otse läheb, vaid milline prefiks millises tabelis sellega sobib ja kes selle sinna pani.

Pool-vaikimisi marsruudid ehk miks vaikimisi kirje võib tunduda puutumata

Puhtaim näide on redirect-gateway def1 OpenVPN-is. Selle asemel et teie vaikimisi marsruut kustutada ja asendada, lisab see 0.0.0.0/1 ja 128.0.0.0/1. Koos katab paar kogu IPv4, iga prefiks on pikem kui /0, ja mõlemad löövad ruuteri vaikimisi marsruudi, jättes selle paigale. Käivitage seejärel marsruutide loend ja algne vaikimisi marsruut on endiselt seal, osutab endiselt teie lüüsile; seda lihtsalt ei valita kunagi interneti sihtkohtade jaoks.

WireGuardi wg-quick jõuab sama tulemuseni poliitikapõhise marsruutimisega. Kui AllowedIPs katab 0.0.0.0/0, loob see oma tabeli, saadab märgitud paketid sinna ja lisab reegli, mis eirab põhitabeli nullpikkusega prefiksit. Põhitabel hoiab oma vaikimisi kirjet ja reeglid otsustavad, et liidesele kuuluva liikluse jaoks konsulteeritakse kõigepealt tunnelitabeliga.

Mõlemad lahendused vajavad täpselt ühte marsruuti väljaspool tunnelit: hostimarsruuti VPN-serveri enda aadressile algse lüüsi kaudu. Ilma selleta üritaks klient tunnelit ehitavaid pakette tunnelis sees kanda ja ühendus ei saaks kunagi valmis. Seega on mittetunneliline marsruut teie tabelis normaalne ka range täistunneliprofiili puhul. Marsruudid, mida tasub kahtluse alla seada, on need, mis katavad sihtkohti, millest teile tõesti hoolite.

Mõõdikud otsustavad viigid, prefiksid otsustavad võitjad

Mõõdikuid võrreldakse ainult kandidaatide vahel, mis sobivad sihtkohaga võrdselt hästi. Linuxis ip route get 10.20.5.9 trükib võitja koos oma tabeliga ja ip route show table all loetleb kandidaadid, sealhulgas kõik pool-vaikimisi marsruudid ja iga tabeli, millele reegel osutab. Windowsis Find-NetRoute -RemoteIPAddress 10.20.5.9 tagastab valitud marsruudi ja lähteaadressi, samas kui Get-NetRoute näitab töötlemata tabelit — kuid tegelik kulu on marsruudi mõõdik pluss liidese mõõdik, seega aeglane adapter võib kaotada viigi, mille ta näib võitvat.

Kolm juhtumit katavad suurema osa sellest, mida näete:

• Sama sihtkoht, /24 versus /0: /24 võidab prefiksi pikkuse järgi, mida iganes mõõdikud ütlevad.
• Sama sihtkoht, kaks /24 erinevate mõõdikutega: võidab madalam tegelik mõõdik.
• Sama sihtkoht, kaks tabelit, üks valitud poliitikareegliga: reegel valib kõigepealt tabeli ja prefiksite võrdlus toimub selle sees.

Kolmas juhtum on koht, kuhu enamik neist aruannetest jõuab. Linuxi ip rule või Windowsi VPN-liiklusfilter võib saata liikluse tabelisse, milles pole kunagi olnud tunneli vaikimisi marsruuti, ja põhitabel näeb kogu aeg täiuslik välja.

Kellele see möödaminek tavaliselt kuulub

Alustage profiilist, mitte tabelist. Split-tunneli konfiguratsioonid ja rakendusepõhised VPN-seaded jätavad nimetatud prefiksid sihilikult tunnelist välja; tööprofiil, mis kaitseb üht privaatset alamvõrku ja laseb üldisel veebilehitsemisel otse minna, käitub nii, nagu ette nähtud, ja selle ülekirjutamine rikub poliitikat, mida see pidi rakendama. Microsofti VPN-i marsruutimise juhend tõmbab sama piiri sunniviisiliselt tunnelisse suunatud liikluse ja selgesõnaliste erandite vahele, mis teeb sellest kasuliku ristkontrolli enne millegi muutmist.

Seejärel otsige jäänuseid. Marsruut, mis osutab liidesele, mida enam ei ole, või eelmise võrgu aadressile, ilmub pärast seda, kui dokkimisjaamad, USB-adapterid ja konteinerisillad tulevad ja lähevad. Selle üks kord kustutamine pole lõpp: NetworkManageri ühendusprofiilid, netplani failid ja Windowsi püsivad marsruudid paigaldavad selle uuesti järgmisel ühendamisel või alglaadimisel, seega leidke fail või profiil, millele see kuulub, enne kui midagi muudate.

Seejärel kontrollige IPv6-t eraldi. ip -6 route ja Get-NetRoute -AddressFamily IPv6 hoiavad eraldi olekut, eraldi vaikimisi marsruute ja eraldi kliendi käitumist. Ainult IPv4 audit ei ütle midagi kahekordse virnaga hosti kohta, mis eelistab vaikselt natiivset IPv6-teed, ja ainuüksi see võib panna kliendi split-tunnelina näima.

Kinnitage rakenduse enda voo abil

Kirjutage üles sihtkoht, mida rakendus tegelikult kasutab, seejärel küsige süsteemilt teed, mille see läbiks lähteaadressist, millega see rakendus ennast seob. ip route get 10.20.5.9 from 192.168.1.40 vastab sellele Linuxis; Find-NetRoute -RemoteIPAddress 10.20.5.9 pluss kohalik aadress teeb seda Windowsis. Võrrelge tulemust sellega, mida profiil väidab. Brauseri avaliku IP leht testib üht sihtkohta ühel protokollil ega ütle midagi privaatse aadressi kohta, mis kaebuse algatas.

Parandage kitsaim objekt, mis erinevust selgitab. Kui erand on kinnitatud, kirjutage prefiks üles ja jätke see rahule; kui ei ole, eemaldage marsruut või lisage tunnelist läbi selgesõnaline kitsam marsruut, selle asemel et vaikimisi marsruudi mõõdikut langetada. Mõõdiku langetamine ei saa pikemat prefiksit ületada, ja vaikimisi marsruudi muutmine, kui kaks /1 marsruuti internetiteed valdavad, ei muuda samuti midagi.

Seejärel ühendage tunnel uuesti ja korrake sama päringut. Kliendid paigaldavad marsruudid igal ühendamisel uuesti, seega muudatus, mis püsib ainult järgmise kätluseni, pole testitud. Kui tee lahkneb endiselt, on ülejäänud kahtlusalused poliitikareegel, teine tabel või kliendipoolne filter — mitte vaikimisi marsruut.

• Nimetage sihtkoht ja lähteaadress, mida rakendus tõesti kasutab.
• Näidake võidumat marsruuti käsuga ip route get või Find-NetRoute.
• Kontrollige, kas internetiteed valdab /1 paar või poliitikatabel.
• Loetlege iga prefiks, mis on pikem kui /0 ja sobib sihtkohaga.
• Korrake IPv6 kontrolli eraldi.
• Jälgige alles jäänud marsruut tagasi faili, profiili või filtrini, mis selle paigaldab.
• Ühendage uuesti ja käivitage päring veel kord, enne kui nimetate selle parandatuks.

Kui kõik seitse nõustuvad profiiliga, teeb tunnel täpselt seda, milleks see seadistati, ja parandus kuulub profiili, mitte mõõdikusse.