Hogyan ellenőrizze, mit irányít valójában egy VPN a Windowsban PowerShell-lel

Csatlakoztattam a VPN-klienst egy Windows 11-es laptopon, a csempe Connected állapotba váltott, megnyílt egy belső fájlmegosztás, és egy nyilvános webhely továbbra is közvetlenül az irodai Wi-Fi-ről töltődött. Ez a keverék törött alagútnak tűnik. Pedig ez a normális kimenete egy olyan profilnak, amely a forgalom egy részét a VPN-en küldi, a többit pedig a fizikai adapteren hagyja. A kényszerített alagútépítés megváltoztatja, melyik alapértelmezett útvonalat részesíti előnyben a Windows; nem törli a konkrétabb útvonalakat, és nem ígéri, hogy a forgalom leáll, amikor a kapcsolat megszakad. A következő sorrendet járom végig, amikor egy ügyfél lefedettséget állít: ügyfélállapot, mentett profil, alkalmazott útvonalak, feloldó, majd valódi folyamok.

Kezdje az ügyfélnél, aztán hagyjon fel a bizalmával

Az ügyfél csak azért jó kiindulópont, mert megmondja, melyik profil aktív. Nyissa meg a kapcsolat tulajdonságait, és jegyezze fel a profil pontos nevét, hogy az aktuális felhasználónak vagy a gépen mindenkinek készült-e, és hogy csatlakozás után melyik adapter jelenik meg a ncpa.cpl-ban. A tesztlaptopomon az adapter a profil nevét viselte, ami könnyen olvashatóvá tette az útvonalak kimenetét. Más gépeken WAN Miniport bejegyzésként jelenik meg, és a név semmit sem mond.

Amit az ügyfél nem tud megmondani, az a lefedettség. A csatlakozott csempe az alagút állapotát írja le, nem a célok leltárát. A harmadik féltől származó ügyfelek is saját konfigurációt tartanak, ezért előfordulhat, hogy a natív Windows-profil és minden tulajdonság, amit abból olvasni fog, semmi kapcsolatban nincs azzal, amit az az ügyfél telepített. Ha a VPN AnyConnect, OpenVPN GUI, WireGuard vagy egy szállítói ügynök révén érkezett, az alábbi PowerShell-ellenőrzések többnyire nem érvényesek, és inkább annak az ügyfélnek a saját split-tunnel és útválasztási beállításait kell olvasnia.

A mentett profilt olvassa, ne a csempét

Natív Windows-profil esetén (IKEv2, L2TP, SSTP vagy MDM által kitolt profil) a mentett split-tunnel döntés egyetlen tulajdonság:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Adja hozzá a -AllUserConnection kapcsolót, ha a profil mindenkinek készült az eszközön. Enélkül az aktuális felhasználó listáját olvassa, amely üres lehet, vagy tartalmazhat egy másik, hasonló nevű bejegyzést. A False érték a SplitTunneling-ben azt jelenti, hogy a profil teljes alagútként mentődött: a Windows alapértelmezett útvonalat telepít a VPN-adapteren keresztül. Az True split tunnelt jelent, és a lefedettség akkor teljesen a profil által kitolt útvonalaktól és névfeloldási szabályoktól függ.

Tekintse ezt az értéket konfigurációnak, nem megfigyelésnek. Azt rögzíti, amit a profil csatlakozáskor kért. A Windows végül eltérő alkalmazott útvonalakkal állhat elő egy másik interfész konkrétabb útvonala, egy házirend-beállítás vagy egy korábbi kapcsolat maradék bejegyzése miatt, ezért a logikai érték soha nem dönti el egyedül a kérdést.

Hasonlítsa össze a mentett értéket az alkalmazott útválasztási táblázattal

Csatlakozás után listázza az alagút-adapter útvonalait ahelyett, hogy végiggörgetné a teljes táblázatot:

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

A Find-NetRoute a hasznos fele. Arra a kérdésre válaszol, amelyre az ügyfél soha: ennél a célnál melyik interfészt és melyik forrás-címet fogja a Windows ténylegesen használni? Futtassa belső gazdagéphez, nyilvános gazdagéphez és mindenhez, amit szándékos kivételnek tart. A teljes alagút profiljának az alagút-interfészt kell mutatnia a nyilvános címhez. A split-tunnel profil általában a fizikai adaptert mutatja ott, miközben a belső előtagok továbbra is a VPN-be oldódnak fel.

Két csapda magyarázza a legtöbb „rossz irányba irányít” jelentést. A legkonkrétabb előtag mindig nyer, ezért a fizikai adapteren lévő /24 legyőzi a VPN alapértelmezett útvonalát, bármilyen alacsony is az alagút metrikája. A metrika csak azonos előtagú útvonalak között dönt döntetlent. Az IPv4 és az IPv6 pedig külön dől el: egy 0.0.0.0/0-t lefedő profil az IPv6-ot a helyi kapcsolaton hagyhatja, amitől egy dupla veremű webhely félig alagutazottnak tűnik. Ellenőrizze a Get-NetRoute -AddressFamily IPv6-at, mielőtt arra jutna, hogy az alagút rendben van.

A névfeloldást külön ellenőrizze az NRPT-vel

A belső nevek, amelyek meghiúsulnak, miközben a belső IP-címek működnek, a feloldó házirendjére utalnak, nem az útválasztásra. A Windows a DNS-t névtérenként a névfeloldási házirend táblázatán keresztül dönti el, amely független az útválasztási táblázattól:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Amikor egy szabály megfelel a *.corp.example mintának, az adott névtér lekérdezései az alagút DNS-kiszolgálóira mennek, akkor is, ha az ezekhez a kiszolgálókhoz vezető adatútvonal split-tunnel módban a fizikai adapteren marad. Ez a tervezés, és ezért nem mond semmit a belső nevekről egy böngészőteszt, amely megnyit egy nyilvános webhelyet. Ha az adapter felsorolja a várt kiszolgálókat, de a keresések mégis máshova mennek, hasonlítsa össze az NRPT-szabályok sorrendjét, és ellenőrizze, hogy egy konkrétabb névtér nem illeszkedik-e előbb.

Ellenőrizze a folyamokat, aztán döntse el, mit is kért valójában

Rögzített sorrendben járja végig a célokat, hogy az eredmények gépek között összehasonlíthatók legyenek: egy nyilvános cím, egy belső cím, egy belső név és egy szándékos kivétel, például egy helyi nyomtató vagy egy videóhívás. Jegyezze fel az interfészt és a forrás-címet, amelyet a Find-NetRoute ad mindegyikhez. Bármilyen házirend-változás után csatlakozzon újra, és ismételje meg ugyanazt a négy ellenőrzést; az újracsatlakozás utáni útválasztási táblázat az egyetlen bizonyíték arra, hogy az új profil életbe lépett.

Aztán válassza külön az útválasztást a kényszerítéstől. A kényszerített alagútépítés a lefedett forgalom számára az alagutat részesíti előnyben, amíg az fenn áll. Ez nem kill switch. Ha az a követelmény, hogy semmi ne hagyja el a gépet, amikor az alagút leesik, annak blokkoló kialakításból kell jönnie: az alagút állapotához kötött tűzfalprofilból, forgalomszűrőkkel ellátott mindig bekapcsolt profilból vagy a szállítói ügyfél saját hiba esetén záró opciójából. A kényszerített alagútnak a VPN-kiszolgáló saját címét is elérhetővé kell hagynia az alagúton kívül, és ennek blokkolása „minden kényszerítése” nevében megbízható módja annak, hogy kizárja magát abból a kapcsolatból, amelyet érvényesíteni próbál.

Mielőtt bármit megváltoztatna, menjen végig ezen a listán. Minden meghiúsuló elem szűkíti, hol van a valódi probléma.

• A profil neve és hatóköre megerősítve, a -AllUserConnection a gép szintű profilokhoz használva.
• A SplitTunneling elolvasva és konfigurációként kezelve, nem a lefedettség bizonyítékaként.
• Az alagút-adapter útvonalai külön listázva IPv4-hez és IPv6-hoz.
• A Find-NetRoute lefuttatva egy nyilvános, egy belső és egy kivétel célra.
• Az NRPT-szabályok ellenőrizve, mielőtt az útvonalakat hibáztatnánk egy névhiba miatt.
• A blokkolási követelmény újraolvasva: az előnyben részesített útválasztás nem ugyanaz, mint az érvényesített blokkolás.

A teljes vagy split alagút döntése a profil tulajdonosáé, és a Microsoft útválasztási jegyzetei leírják azt a viselkedést, amelyet a Windows megvalósít, amikor egy profil beállítja. Microsoft: kényszerített és split alagútépítés az a hivatkozás, amelyet nyitva tartok a kimenet olvasása közben.