Miért öli meg a Windows VPN a helyi nyomtatót, és hogyan állítsd meg

Csatlakoztasd a VPN-t, és a nyomtató eltűnik, a NAS-megosztás nem nyílik meg, és a melletted lévő gép felé induló Távoli asztal munkamenet lejár. Semmi nem tört el. A kliens hozzáadott egy alapértelmezett útvonalat, és most minden célállomás az övé, amelyet a laptop meg tud nevezni, beleértve a három méterre lévőket is. Ez az egész mechanizmus, és VPN-hibának nevezni az, ami egy egysoros javítást támogatási esetté változtat.

Először olvasd ki az útvonaltáblát

Mielőtt bármit módosítanál, rögzítsd az IPv4-táblát ezzel: route print -4 és őrizd meg a kimenetet. Csatlakozz, rögzítsd újra, és hasonlítsd össze a következő sorokat: 0.0.0.0 az aktív alapértelmezett útvonal egy interfészt nevez meg, és ha ez az interfész az alagút, a helyi nyomtatás és böngészés először az irodába megy.

A második oszlop interfészszáma az, amire egy állandó útvonalnak később hivatkoznia kell, ezért jegyezd fel, amíg az alagút fel van. Ez az az érték is, amely az adapter újralétrehozásakor változik, ezért a hozzá rögzített útvonalak csendben túlélhetik hasznosságukat.

Távolítsd el az alapértelmezett útvonalat, három módon

Beépített Windows-profilnál a vezérlő egy jelölőnégyzet. Nyisd meg a kapcsolat tulajdonságait, IPv4, majd Speciális, és töröld a következőt: Use default gateway on remote network; az újabb Beállítások alkalmazás ugyanezt a párbeszédablakot egy réteggel mélyebben rejti el. Emelt parancssorból ugyanez a változtatás egyetlen cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Egy OpenVPN profil másként működik, ezért viselkedése összezavarja azokat, akik jelölőnégyzetet várnak. A redirect-gateway def1 direktívája egyáltalán nem cseréli le az alapértelmezett útvonalat; két fél tartományú útvonalat telepít, 0.0.0.0/1 és 128.0.0.0/1, amelyek együtt legyőzik az alapértelmezettet anélkül, hogy törölnék. Mivel az eredeti alapértelmezett túlél, egy net_gateway-re mutató előtag hozzáadása csak ezt az előtagot küldi vissza a helyi routernek. Ez a részlet magyarázza, miért előtag-útvonal a def1 profil javítása, és nem egy jelölőnégyzet, amelyet senki nem talál.

Csak azt tedd vissza, ami a munkához tartozik

Az alapértelmezett útvonal nélkül az alagút semmit nem szállít, ezért a munkaelőtagokat kifejezetten meg kell nevezni. Az a cmdlet, amely előtagot köt a kapcsolathoz, biztonságosabb az állandó útvonalnál, mert csak addig települ, amíg ez a kapcsolat fennáll, és nem függ interfészszámtól:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

A régebbi megközelítés még mindig működik, és még mindig minden ellenőrzőlistán szerepel: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, az alagút saját interfészindexével és átjárócímével. Túléli az újraindításokat, ami a lényeg és egyben a veszély, mert az index a következő indításkor valami máshoz tartozhat.

A többit a metrikák döntik el. Ha a fizikai és az alagút-adapter is igényt tart ugyanarra az előtagra, az alacsonyabb metrika nyer, és az alagút metrikájának emelése legitim kliensoldali vezérlés, nem hack.

Amikor a kiszolgáló dönt helyetted

Az a kliens, amely figyelmen kívül hagyja a jelölőnégyzetedet, általában egy házirendet követ. A Cisco-profilok hordanak egy beállítást: Allow Local LAN Access, és egy headend push-olhat tunnel-all házirendet, amely felülírja, amit a kliens előnyben részesítene; kötelező alagút telepítésénél nincs helyi kapcsoló, amelyet át lehetne billenteni. Olvasd a kliens naplóját a push-olt útvonalakért és házirendsorokért, ahelyett hogy újra ellenőriznéd ugyanazt a párbeszédablakot.

Utána nézd meg a névfeloldást, amely külön kapcsoló a forgalomirányítástól. Egy osztott alagút továbbra is kaphat belső feloldót és keresési utótagot, ezért egy helyi eszköz elérhető cím alapján, és nem található meg név alapján, amíg a DNS-oldal is rendbe nem jön.

Az átfedések más probléma

Ha az otthoni LAN és az irodai LAN ugyanazt az előtagot használja, például 192.168.0.0/24, egyetlen útvonal sem tudja megkülönböztetni őket. Minden csomagnak abban a tartományban egyetlen keresési eredménye van, és a megoldás az, hogy újraszámozzák az egyik oldalt, vagy egy lefordított címen keresztül érjék el az irodát a poolból. Több konkrét útvonal hozzáadása csak eltolja, hogy a hálózat melyik fele törik el.

Egy ellenőrzéssel fejezd be öt helyett: csatlakozz, majd futtasd a következőt tracert egy belső és egy nyilvános hoszt ellen. Az első ugrásnak el kell térnie, és ha nem tér el, az osztás nincs érvényben, bármit is jelent a kliens. Utána egyszer csatlakozz újra, és ismételd meg, mert a push-olt útvonalak minden munkamenettel visszatérnek.