A VPN blokkolja a helyi LAN-t Windowson: útvonal vagy kliensszabály?
A helyi LAN elérése Windowson két különböző okból szakad meg: hiányzó útvonal vagy olyan átjárószabály, amely eldobja az alhálózatot. Három ellenőrzés megmondja, melyik.
A saját asztalodon lévő nyomtató, NAS vagy fejlesztőgép abban a pillanatban abbahagyja a válaszadást, amikor a munkahelyi VPN csatlakozik. Néha egy útvonalparancs másodpercek alatt rendbe teszi; néha ugyanaz az útvonal helyes, és a csomagok mégis eltűnnek, ami azt jelenti, hogy egy másik, hasonló tünetű problémát látsz. A döntés három kérdésre szűkül, és ezek rossz sorrendben való feltevése az oka annak, hogy az emberek egy egész estét útvonalak törlésével és újra hozzáadásával töltenek.
Három kérdés bármilyen parancs előtt
Először: van-e bejegyzés a helyi előtaghoz, és a fizikai adapterre mutat-e? Másodszor: kap-e a kliens csatlakozáskor engedélyt vagy elutasítást a helyi hálózatra az átjárótól? Harmadszor: csak kimenő hozzáférés kell a LAN-hoz, vagy valaminek az interneten is el kell érnie egy gépeden futó szolgáltatást?
Az első kérdés elválasztja az útválasztási hibát a szűrési hibától. A második megmondja, hogy az útvonal-javítás egyáltalán működhet-e. A harmadik megváltoztatja a javítást: az útvonal a kimenő forgalmat javítja, míg az elérhetetlen bejövő szolgáltatás általában a fogadó hozzákötésének és a visszaútnak a problémája, amelyet az útvonal csak ront.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Első kérdés: útvonal, szűrő vagy név
Olvasd el a táblázatot, mielőtt bármit hozzáadsz. Az interfész indexe számít, mert az alábbi útvonalparancsok mind hozzá vannak horgonyozva:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricA közvetlenül csatlakoztatott alhálózat általában megtartja az on-link útvonalat akkor is, amikor az alagút fent van, tehát létezhet bejegyzés, és a forgalom mégis meghiúsulhat. Ez a kombináció az útválasztás után futó szűrő aláírása, és ez az az eset, amikor egy második, pontosabb útvonal semmit sem változtat.
Teszteld külön cím és név szerint. Ha a ping 192.168.1.50 válaszol, a net view 192.168.1.50 pedig nem, az útvonaltábla soha nem volt a probléma: az alagút megváltoztatta a feloldót, és a helyi név már nem oldódik fel. Útvonalat hozzáadni ehhez elvesztegetett munka.
Második kérdés: engedélyezi az átjáró a helyi LAN elérését?
Egy kereskedelmi kliens többet telepít, mint útvonalakat. Csatlakozáskor szabályt kap, és az a szabály tartalmazhat kifejezett helyi hálózati engedélyt. A Cisco IPsec telepítésekben a csoportszabály hordozza a split-tunneling beállítást és egy külön helyi LAN hozzáférési jelzőt; a kliens jelölőnégyzete kérés, amelyet az átjáró elutasíthat. Az AnyConnectben a profil vezérli a split belefoglalási és kizárási listáit és ugyanazt az engedélyt. A Windows RRAS esetében a megfelelők a profil alapértelmezett átjáró opciója plusz a kiszolgáló által kiosztott statikus útvonalak.
Amikor a jelző ki van kapcsolva, a dokumentált viselkedés az, hogy a kliens blokkolja a forgalmat a közvetlenül csatlakoztatott alhálózat felé, pedig létezik érvényes, pontosabb útvonal. Ezért is tűnhetnek el a kliens tulajdonában nem lévő útvonalak másodpercekkel a hozzáadásuk után: a kliens újraépíti azt az állapotot, amelyet építenie utasítottak, nem harcol ellened.
A kliens naplója rögzíti a döntést csatlakozáskor, és elolvasása gyorsabb bármilyen gépen végzett kísérletnél. Ha a napló azt mondja, hogy a helyi hozzáférés blokkolva van, állj meg: semmilyen parancssori javítás nem éli túl ezt, és csak a szabály módosítása, az erőforrás elérése az alagúton keresztül, vagy a kliens virtuális gépbe zárása és a gazdagép helyi hálózaton hagyása marad.
Harmadik kérdés: melyik irányra van szükséged?
A közeli eszközhöz menő kimenő forgalom útválasztási kérdés. Irányítsd a LAN előtagot a helyi átjáróra olyan metrikával, amely elég alacsony ahhoz, hogy legyőzze az alagút alapértelmezett útvonalát:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pA második forma egyetlen eszközt rögzít, és ezt akarod, amikor egyetlen cím a teljes követelmény. A netsh megfelelője ugyanezt a döntést az index helyett az interfész nevével rögzíti:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentAz útvonalparancsok A paraméter helytelen hibával hiúsulnak meg, ha a cím és a maszk nem egyezik, például egy gazdagép-cím /24-es maszkkal. Használj hálózati címet az alhálózati útvonalhoz és gazdagép-maszkot egyetlen gazdagéphez.
A bejövő más. Ugyanazon a gépen futó VNC vagy SSH kiszolgáló elérhetetlenné válik, amikor a bejövő kapcsolat válaszai a VPN átjárón keresztül távoznak és soha nem térnek vissza. Ellenőrizd, min figyel a szolgáltatás, mielőtt az útvonalakhoz nyúlsz:
netstat -ano | findstr :5900Az egy adott címhez kötött fogadó nem fog válaszolni a másik interfészen. Minden interfészhez kötni tudatos döntés, amelyet a megbízott hálózatra korlátozott tűzfal-szabállyal együtt hoznak. Csak ezután állítja helyre az útvonal-javítás a visszautat.
A legkisebb illő változtatást alkalmazd
A másik gyakori lépés a „Alapértelmezett átjáró használata távoli hálózaton” jelölésének törlése az IPv4 speciális tulajdonságai között. Ez helyben tartja az internetes forgalmat, de egyszerre két dolgot tesz: a VPN megszűnik alapértelmezett útvonalnak lenni, és a kliens nem kap többé útvonalakat a távoli hálózathoz, beleértve a multicastot is. Töröld a jelölést, és a távoli LAN eltűnik, kivéve ha a kiszolgáló betolja a minden klienshez szükséges konkrét távoli előtagokat.
Ez az aszimmetria dönti el a munka sorrendjét. Ha a távoli oldalnak teljesen elérhetőnek kell maradnia, tolja a kiszolgáló a távoli alhálózatokat, és hagyd békén a helyi alapértelmezettet. Ha nem tudod módosítani a kiszolgálót, adj hozzá állandó útvonalat a távoli előtaghoz azon a címen keresztül, amelyet az alagút kiosztott, és ellenőrizd a route print segítségével, hogy az előtag a VPN interfészre mutat, miközben az alapértelmezett továbbra is a fizikai átjáróra mutat.
Ezután igazold, hogy a javítás túléli az újracsatlakozást, mert a nem állandó útvonalak az adapterrel együtt meghalnak, és az egyes csatlakozások után futó szkript az őszinte helyük. Tesztelj egy helyi eszközt és egy távoli erőforrást ugyanabban a munkamenetben, szakítsd meg, csatlakozz újra, és teszteld ismét. Ha a helyi eszköz továbbra is meghiúsul, miközben az útvonal helyesnek tűnik, térj vissza a második kérdéshez: a kliens szűr, és a válasz a szabály módosítása, nem egy második versengő útvonal.