Miért mutatja a Windows VPN útválasztási táblázata a 0.0.0.0/1 és 128.0.0.0/1 címeket

Csatlakozzon egy Windows VPN-hez, és nyissa meg az útválasztási táblázatot: két bejegyzés tűnik fel, a 0.0.0.0/1 és a 128.0.0.0/1. Ezek nem elgépelések, és nem helyettesítik az alapértelmezett útvonalat. Megjelenésük egyetlen profilbeállítástól függ, és a pár így épít fel egy teljes alagutat, nem split-tunnel funkció. Olvassa össze a beállítást, az előtagot és az interfészt, mielőtt egyetlen sort módosítana.

Mit telepít az alapértelmezett átjáró beállítása

A profilbeállítás, amely mindent az alagúton keresztül küld, e két előtag hozzáadásával működik. Törölje a beállítást, és eltűnnek, csak egy olyan útvonal marad, amely csak az alagút-adapternek adott alhálózatot fedi le. A jelölőnégyzet a párt vezérli; nem írja át az egyetlen alapértelmezett útvonalat. Ezért néz ki a táblázat a jelölés törlése után részleges átírásnak, nem törlésnek.

A 0.0.0.0/1 az IPv4-tér alsó felét, a 128.0.0.0/1 a felső felét fedi le, így együtt minden unicast címet lefednek. Mindegyik konkrétabb a 0.0.0.0/0 alapértelmezett útvonalnál, azaz a leghosszabb előtag egyezése a szokásos forgalmat az alagútba küldi, miközben a fizikai alapértelmezett útvonal a helyén marad. Ennek az alapértelmezettnek a megtartása nem kozmetika: a titkosított terhelést beburkoló csomagok a kiszolgáló nyilvános címére vannak címezve, és a fizikai adapteren kell kilépniük. Ha az alapértelmezettet felosztás helyett lecseréli, az alagút saját szállítása próbál belépni az alagútba, ami hurok, nem kapcsolat.

Ezért érdemes megállni egy szó szerinti 0.0.0.0/0 előtt, amely a VPN-adapterre mutat. A natív kliens általában nem ír ilyet, tehát egy kézi útvonal vagy egy másik kliens konfigurációja megváltoztatta a táblázatot a háta mögött. Találja meg, mielőtt bármit is hibakeresne lejjebb.

A bontás olcsóbb, mint egy átjáró megtartása

A bontás a gyakorlati érv két bejegyzés mellett eggyel szemben. A kliens csatlakozva pontosan két útvonalat birtokol, és kapcsolódáskor törli őket, meghagyva azt, amit a fizikai adapter abban a pillanatban tart. Egy kliensnek, amely lecserélte volna az egyetlen alapértelmezettet, emlékeznie kellene az előző átjáróra, és egy DHCP-bérlet változása után olyat állíthatna vissza, amely már nem létezik. Két saját bejegyzés nem hordoz ilyen állapotot.

Más kliensek ugyanerre a kialakításra jutnak. A redirect-gateway def1 beállítású OpenVPN-profil ezt a két előtagot telepíti az alapértelmezett törlése helyett, és a Windows kliens ugyanezt a mintát követi ugyanabból az útválasztási okból.

Ezért is nézhet ki egy táblázat teljes alagútnak, amikor felosztást várt. A pár így építi fel a teljes alagutat, nem pedig egy split-tunnel hiba bizonyítéka. Ha a profil a távoli átjáró használatára van beállítva, minden útvonalon megy, bármit is ér el egy helyi alkalmazás.

A leghosszabb előtag minden metrikánál előbb győz

Az előtag hossza dönti el a keresést minden más mező előtt. A metrika csak az azonos előtagú útvonalak közötti holtversenyt dönti el, ezért a /1 bejegyzés legyőzi a /0 alapértelmezettet akkor is, ha a metrikája rosszabb. Az interfész-kötés dönti el, mi marad, amikor két útvonal osztozik egy előtagon, és a Windowsnak el kell döntenie, melyik adapter küldi a csomagot.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Egy split-tunnel táblázat tartalmazza a fizikai alapértelmezettet, a két fél-alapértelmezettet, az alagút alhálózatának útvonalát és minden hozzáadott irodai előtagot. A fizikai alapértelmezett alacsonyabb vagy magasabb metrikán lehet a klienstől és a profiltól függően, és amíg a /1 pár létezik, ez a különbség nem változtat semmit. Mindent megváltoztat abban a pillanatban, amikor a párt eltávolítják, és akkor bukkan fel egy elavult átjáró vagy egy rossz interfész. Az egész táblázatot olvassa, ne azt az egy sort, amelyet módosítani készült.

Válasszon egy tulajdonost az irodai előtaghoz

Split-tunnel esetén csak azt az előtagot nevezze meg, amelynek a VPN-t kell használnia, és válasszon egy módot a birtoklására. Az útvonalat a hozzárendelt alagútcímre irányítani addig működik, amíg a cím meg nem változik, míg az interfészhez kötés túléli a címváltozást, de eltörik, amikor az indexet a profil újraépítése után újra hozzárendelik. A profilhoz kötött cmdlet mindkét problémát elkerüli, cserébe a profilra van szükség.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

A cmdlet az előtagot a megnevezett profilhoz köti, így az útvonal a kapcsolattal együtt jelenik meg és vele együtt tűnik el, amit egy felügyelt laptop szeretne. Egy állandó útvonal túléli az újraindításokat és túléli az őt kiváltó profilt, így egy kivont VPN évekre ott hagyja a bejegyzéseket. Előtagotként egy módszert válasszon, és jegyezze fel a döntést, mert egy állandó útvonal plusz egy profil-útvonal ugyanahhoz az előtaghoz olyan duplikátumokat hoz létre, amelyeket bontáskor fájdalmas kibogozni. Bármit is választ, a tulajdonjognak látszania kell a jegyben, nem csak a gépen.

A tulajdonjog az a kérdés, amelyre ez a szakasz válaszol, nem a szintaxis. Két tulajdonos egy előtaghoz az a hibamód, amelyet érdemes elkerülni.

Céllal ellenőrizzen, ne webhellyel

Azt a célt tesztelje, amelynek át kell haladnia az alagúton, ne egy webhelyet, amely kilépési címet jelent. Find-NetRoute visszaadja a kiválasztott útvonalat és a forráscímet, így láthatja, hogy az irodai előtag vagy a fizikai alapértelmezett győzött-e, majd megnyitja magát a megosztást.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

A kilépési címet mutató webhely gyenge ellenőrzés, mert a DNS, az IPv6 és egy böngésző-proxy egyaránt más útvonalon küldheti azt a kérést. Az IPv4-nek és az IPv6-nak ugyanabban a párbeszédablakban külön beállításai is vannak, és egy mező törlése a másik családot érintetlenül hagyja, így egy kettős vermű gép IPv6-ot vihet az alagúton, miközben az IPv4 a split útvonalat követi. Mindkét családot ellenőrizze, mielőtt splitnek nevezné a profilt. Ha az útvonal helyes, és a szolgáltatás mégis meghibásodik, a fennmaradó réteg a szűrés, nem az útválasztás.

Egy kliens által felügyelt tűzfal blokkolhatja az irodai alhálózatot tökéletes útválasztási táblázat mellett is. Ez a szabályzat azt illeti, aki a profilt kiosztotta, nem azt, aki az útvonalakat szerkeszti.