Miért kerüli mégis egy alhálózat a VPN alapértelmezett útvonalát

Átváltja a VPN-t teljes alagútra, a forgalom nagy része engedelmeskedik, majd egy cím közvetlenül válaszol — egy nyomtató, egy NAS, egy ugrógép a 10.x-en. A kézenfekvő olvasat az, hogy az alagút szivárog, ezért csökkenti az alapértelmezett útvonal metrikáját, és semmi sem változik. Ez a sikertelen kísérlet a nyom: az alapértelmezett útvonal tartalék, nem ítélet. Az útvonalkeresés a leghosszabb egyező előtagot veszi, mielőtt egyáltalán összehasonlítaná a metrikákat, így a /24 továbbra is legyőzi a /0-t, bármilyen számot is csatol bármelyikhez. Ha ez a sorrend világos, a szivárgás általában egy szándékosan telepített útvonal, vagy egy előtag, amelyet a kliens soha nem akart lefedni.

Mit ígér valójában az alapértelmezett útvonal

A 0.0.0.0/0 minden IPv4-célhoz illeszkedik nulla bit specificitással. Azért létezik, hogy a gazdagép elérjen mindent, amit a táblája nem ír le jobban. A 192.168.1.0/24-re mutató útvonal 24 egyező bitet hordoz, így a 192.168.1.40 esetében nyer, mielőtt bárki összehasonlítaná a metrikákat, az adminisztratív távolságot vagy amit a kliens prioritásmezőnek nevez. Ugyanez a szabály érvényes a Linux FIB-ben, a Windows útvonaltáblájában és a macOS mögötti BSD stackben.

Egy normál LAN-on ez a viselkedés előny. A helyi alhálózat közvetlenül kapcsolódik, a nyomtató tovább működik, miközben az alagút a böngészését szállítja, és semmi sincs rosszul konfigurálva. A kérdés, amit érdemes feltenni, nem az, hogy miért megy az az egy cím közvetlenül, hanem hogy melyik előtag melyik táblában illeszkedik hozzá, és ki tette oda.

Fél-alapértelmezett útvonalak, avagy miért tűnhet érintetlennek az alapértelmezett bejegyzés

A legtisztább példa redirect-gateway def1 az OpenVPN-ben. Ahelyett hogy törölné és lecserélné az alapértelmezett útvonalat, hozzáadja a 0.0.0.0/1 és 128.0.0.0/1 címeket. Együtt a pár lefedi az egész IPv4-et, minden előtag hosszabb a /0-nál, és mindkettő legyőzi az útválasztó alapértelmezett útvonalát, miközben a helyén hagyja. Futtasson utána útvonallistázást, és az eredeti alapértelmezett útvonal még mindig ott van, még mindig az átjárójára mutat; egyszerűen soha nem választják internetes célokra.

A WireGuard wg-quick eszköze szabályzat-alapú útválasztással éri el ugyanezt. Ha az AllowedIPs lefedi a 0.0.0.0/0-t, saját táblát hoz létre, oda küldi a megjelölt csomagokat, és hozzáad egy szabályt, amely figyelmen kívül hagyja a fő tábla nulla hosszúságú előtagját. A fő tábla megtartja alapértelmezett bejegyzését, a szabályok pedig eldöntik, hogy az interfész tulajdonában lévő forgalom esetén először az alagút tábláját kérdezik meg.

Mindkét tervnek pontosan egy útvonalra van szüksége az alagúton kívül: egy gazdagép-útvonalra a VPN-kiszolgáló saját címére az eredeti átjárón keresztül. Enélkül a kliens megpróbálná az alagutat építő csomagokat az alagúton belül szállítani, és a kapcsolat soha nem jönne létre. Ezért a táblájában egy nem alagút-útvonal normális még egy szigorú teljes alagút profil esetén is. Azok az útvonalak, amelyeket érdemes megkérdőjelezni, azok, amelyek az Ön számára igazán fontos célokat fedik le.

A metrikák a döntetlent, az előtagok a győztest döntik el

A metrikákat csak azok között a jelöltek között hasonlítják össze, amelyek egyformán jól illeszkednek a célhoz. Linuxon ip route get 10.20.5.9 kiírja a győztest a táblájával együtt, és ip route show table all felsorolja a jelölteket, beleértve az esetleges fél-alapértelmezett útvonalakat és minden táblát, amelyre egy szabály mutat. Windowson Find-NetRoute -RemoteIPAddress 10.20.5.9 visszaadja a kiválasztott útvonalat és a forrás címet, míg Get-NetRoute a nyers táblát mutatja — de a tényleges költség az útvonal metrikája plusz az interfész metrikája, így egy lassú adapter elveszíthet egy döntetlent, amelyet látszólag megnyer.

Három eset lefedi a legtöbbet abból, amit látni fog:

• Ugyanaz a cél, /24 a /0 ellen: a /24 nyer az előtag hosszán, bármit is mondanak a metrikák.
• Ugyanaz a cél, két /24 különböző metrikákkal: az alacsonyabb tényleges metrika nyer.
• Ugyanaz a cél, két tábla, az egyiket házirend-szabály választja: a szabály először a táblát választja, és az előtag-összehasonlítás azon belül történik.

A harmadik eset az, ahol e jelentések többsége végződik. Egy Linux ip rule vagy egy Windows VPN-forgalomszűrő olyan táblába küldhet forgalmat, amely soha nem tartalmazta az alagút alapértelmezett útvonalát, és a fő tábla közben végig tökéletesnek látszik.

Ki birtokolja általában a megkerülést

Kezdje a profillal, ne a táblával. A split-tunnel konfigurációk és az alkalmazásonkénti VPN-beállítások szándékosan hagyják az elnevezett előtagokat az alagúton kívül; egy munkaprofil, amely egy privát alhálózatot véd, és az általános böngészést közvetlenül hagyja menni, úgy viselkedik, ahogy tervezték, és felülírása megszegi a szabályzatot, amelynek érvényesítésére készült. A Microsoft VPN-útválasztási útmutatója ugyanazt a határvonalat húzza meg a kényszerítetten alagutazott forgalom és a kifejezett kivételek között, ami hasznos kereszttesztté teszi, mielőtt bármit szerkesztene.

Ezután keressen maradékokat. Egy olyan interfészre mutató útvonal, amely már nem létezik, vagy egy korábbi hálózat címére mutató útvonal a dokkolóállomások, USB-adapterek és konténerhidak jövetele-menetele után jelenik meg. Egyszer törölni nem a vége: a NetworkManager kapcsolatprofiljai, a netplan fájlok és a Windows állandó útvonalai a következő csatlakozáskor vagy indításkor újratelepítik, ezért keresse meg a fájlt vagy profilt, amely birtokolja, mielőtt bármit szerkeszt.

Ezután ellenőrizze az IPv6-ot külön. ip -6 route és Get-NetRoute -AddressFamily IPv6 külön állapotot, külön alapértelmezett útvonalakat és külön kliensviselkedést tartanak. A csak IPv4-re kiterjedő audit semmit sem mond egy kettős veremű gazdagépről, amely csendben a natív IPv6-útvonalat részesíti előnyben, és ez önmagában is split-tunnelnek láttathat egy klienst.

Erősítse meg az alkalmazás saját folyamatával

Jegyezze fel a célt, amelyet az alkalmazás valóban használ, majd kérdezze meg a rendszertől az útvonalat, amelyet a forrás címről venne, amelyhez az alkalmazás kötődik. ip route get 10.20.5.9 from 192.168.1.40 erre válaszol Linuxon; Find-NetRoute -RemoteIPAddress 10.20.5.9 plusz a helyi cím teszi ezt Windowson. Hasonlítsa össze az eredményt azzal, amit a profil állít. A böngésző nyilvános IP-oldala egy célt tesztel egy protokollon, és semmit sem mond a panaszt indító privát címről.

Javítsa a legszűkebb objektumot, amely megmagyarázza a különbséget. Ha a kivétel jóváhagyott, írja fel az előtagot, és hagyja békén; ha nem, távolítsa el az útvonalat, vagy adjon hozzá egy kifejezett szűkebb útvonalat az alagúton keresztül, ahelyett hogy csökkentené az alapértelmezett metrikáját. Egy metrika csökkentése nem tud felülmúlni egy hosszabb előtagot, és az alapértelmezett szerkesztése sem változtat semmit, miközben két /1 útvonal birtokolja az internetes útvonalat.

Ezután csatlakoztassa újra az alagutat, és ismételje meg ugyanazt a lekérdezést. A kliensek minden csatlakozáskor újratelepítik az útvonalakat, így egy változás, amely csak a következő kézfogásig tart, nincs tesztelve. Ha az útvonal még mindig eltér, a fennmaradó gyanúsítottak egy házirend-szabály, egy második tábla vagy egy kliensoldali szűrő — nem az alapértelmezett útvonal.

• Nevezze meg a célt és a forrás címet, amelyet az alkalmazás valóban használ.
• Írja ki a nyertes útvonalat a ip route get vagy Find-NetRoute segítségével.
• Ellenőrizze, hogy egy /1 pár vagy egy házirendtábla birtokolja-e az internetes útvonalat.
• Sorolja fel az összes /0-nál hosszabb előtagot, amely illeszkedik a célhoz.
• Ismételje meg az IPv6-ellenőrzést külön.
• Kövesse vissza a túlélő útvonalat ahhoz a fájlhoz, profilhoz vagy szűrőhöz, amely telepíti.
• Csatlakozzon újra, és futtassa újra a lekérdezést, mielőtt javítottnak nevezné.

Ha mind a hét egyetért a profillal, az alagút pontosan azt teszi, amire konfigurálták, és a javítás a profilba tartozik, nem egy metrikába.