Näin tarkistat, mitä Windowsin VPN oikeasti reitittää PowerShellissä
Yhdistetty VPN-ruutu ei todista kattavuutta. Lue tallennettu profiililippu, elävä reititystaulu ja NRPT-säännöt tässä järjestyksessä.
Yhdistin VPN-asiakkaan Windows 11 -kannettavassa, ruutu vaihtui Connected-tilaan, sisäinen tiedostojako avautui ja julkinen sivusto latautui edelleen suoraan toimiston Wi-Fi-verkosta. Tämä yhdistelmä näyttää rikkinäiseltä tunnelilta. Se on kuitenkin normaali tulos profiilista, joka lähettää osan liikenteestä VPN:n kautta ja jättää loput fyysiselle sovittimelle. Pakotettu tunnelointi muuttaa sitä, mitä oletusreittiä Windows suosii; se ei poista tarkempia reittejä eikä lupaa, että liikenne pysähtyy yhteyden katketessa. Seuraavaksi kerron järjestyksen, jolla etenen, kun asiakas väittää kattavuutta: asiakkaan tila, tallennettu profiili, sovelletut reitit, selvittäjä ja sitten todelliset virrat.
Aloita asiakkaasta ja lakkaa sitten luottamasta siihen
Asiakas on oikea aloituspaikka vain siksi, että se kertoo, mikä profiili on aktiivinen. Avaa yhteyden ominaisuudet ja kirjaa tarkka profiilin nimi, onko se luotu nykyiselle käyttäjälle vai kaikille koneella, ja mikä sovitin ilmestyy ncpa.cpl-kohtaan yhteyden muodostamisen jälkeen. Testikannettavassani sovitin kantoi profiilin nimeä, mikä teki reittitulosteen lukemisesta helppoa. Muilla koneilla se näkyy WAN Miniport -merkintänä, eikä nimi kerro sinulle mitään.
Sen, mitä asiakas ei voi kertoa sinulle, on kattavuus. Yhdistetty ruutu kuvaa tunnelin tilaa, ei kohdeluetteloa. Kolmannen osapuolen asiakkaat pitävät myös omaa kokoonpanoaan, joten Windowsin natiivilla profiililla ja jokaisella siitä lukemallasi ominaisuudella ei välttämättä ole mitään tekemistä sen kanssa, mitä kyseinen asiakas asensi. Jos VPN tuli AnyConnectin, OpenVPN GUI:n, WireGuardin tai toimittajan agentin kautta, alla olevat PowerShell-tarkistukset eivät useimmiten päde, ja sinun kannattaa lukea kyseisen asiakkaan omat split-tunnel- ja reititysasetukset.
Lue tallennettu profiili, älä ruutua
Natiiville Windows-profiilille (IKEv2, L2TP, SSTP tai MDM:n työntämä) tallennettu split-tunnel-päätös on yksi ominaisuus:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixLisää -AllUserConnection, kun profiili luotiin kaikille laitteella. Ilman sitä luet nykyisen käyttäjän luetteloa, joka voi olla tyhjä tai sisältää toisen samannimisen merkinnän. Arvo False kohdassa SplitTunneling tarkoittaa, että profiili tallennettiin täydeksi tunneliksi: Windows asentaa oletusreitin VPN-sovittimen kautta. True tarkoittaa split-tunnelia, ja kattavuus riippuu silloin täysin reiteistä ja nimien selvityssäännöistä, joita profiili työntää.
Käsittele arvoa kokoonpanona, älä havaintona. Se tallentaa, mitä profiili pyysi yhteyden muodostamisen hetkellä. Windows voi päätyä erilaisiin sovellettuihin reitteihin toisen liittymän tarkemman reitin, käytäntöasetuksen tai edellisen yhteyden jäänteen vuoksi, joten Boolean ei ratkaise kysymystä yksinään.
Vertaa tallennettua arvoa sovellettuun reititystauluun
Yhteyden muodostamisen jälkeen luettele tunnelisovittimen reitit sen sijaan, että selaisit koko taulun:
$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 1Find-NetRoute on hyödyllinen puolisko. Se vastaa kysymykseen, johon asiakas ei koskaan vastaa: minkä liittymän ja minkä lähdeosoitteen Windows todella käyttää tälle kohteelle? Aja se sisäiselle isännälle, julkiselle isännälle ja kaikelle, mitä pidät tarkoituksellisena poikkeuksena. Täystunneliprofiilin pitäisi näyttää tunneliliittymä julkiselle osoitteelle. Split-tunneliprofiili näyttää siellä yleensä fyysisen sovittimen, kun taas sisäiset etuliitteet selvitetään edelleen VPN:n kautta.
Kaksi ansaa selittää suurimman osan «se reitittää väärin» -raporteista. Tarkin etuliite voittaa aina, joten fyysisen sovittimen /24 voittaa VPN:n oletusreitin riippumatta siitä, kuinka matala tunnelin metriikka on. Metriikka ratkaisee vain saman etuliitteen reittien väliset tasapelit. Ja IPv4 ja IPv6 päätetään erikseen: profiili, joka kattaa 0.0.0.0/0, voi jättää IPv6:n paikalliseen linkkiin, mikä saa kaksoispino-sivuston näyttämään puoliksi tunneloidulta. Tarkista Get-NetRoute -AddressFamily IPv6, ennen kuin päättelet tunnelin olevan kunnossa.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Tarkista nimien selvitys erikseen NRPT:llä
Sisäiset nimet, jotka epäonnistuvat sisäisten IP-osoitteiden toimiessa, viittaavat selvittäjän käytäntöön, eivät reititykseen. Windows päättää DNS:n nimiavaruuksittain nimien selvityskäytännön taulun kautta, joka on riippumaton reititystaulusta:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKun sääntö vastaa *.corp.example-merkintää, kyseisen nimiavaruuden kyselyt menevät tunnelin DNS-palvelimille, vaikka datapolku näille palvelimille pysyisi fyysisellä sovittimella split-tunnel-tilassa. Se on suunnittelun tarkoitus, ja siksi selainkoe, joka avaa julkisen sivuston, ei kerro sisäisistä nimistä mitään. Jos sovitin luettelee odotetut palvelimet mutta haut menevät silti muualle, vertaa NRPT-sääntöjen järjestystä ja tarkista, täsmääkö tarkempi nimiavaruus ensin.
Tarkista virrat ja päätä sitten, mitä oikeastaan pyysit
Käy kohteet läpi kiinteässä järjestyksessä, jotta tulokset ovat vertailukelpoisia koneiden välillä: julkinen osoite, sisäinen osoite, sisäinen nimi ja yksi tarkoituksellinen poikkeus, kuten paikallinen tulostin tai videopuhelu. Kirjaa liittymä ja lähdeosoite, jonka Find-NetRoute palauttaa kustakin. Kun käytäntöä muutetaan, yhdistä uudelleen ja toista samat neljä tarkistusta; uudelleenyhdistämisen jälkeinen reititystaulu on ainoa todiste siitä, että uusi profiili tuli voimaan.
Erottele sitten reititys valvonnasta. Pakotettu tunnelointi suosii tunnelia katetun liikenteen osalta, kun se on pystyssä. Se ei ole kill switch. Jos vaatimus on, että mitään ei poistu koneelta tunnelin pudotessa, sen on tultava estävästä suunnittelusta: tunnelin tilaan sidottu palomuuriprofiili, aina päällä oleva profiili liikennesuodattimilla tai toimittajan asiakkaan oma sulje-viassa-vaihtoehto. Pakotetun tunnelin on myös jätettävä VPN-palvelimen oma osoite saavutettavaksi tunnelin ulkopuolelta, ja sen estäminen «kaiken pakottamisen» nimissä on luotettava tapa lukita itsensä ulos yhteydestä, jota yrität valvoa.
Ennen kuin muutat mitään, käy tämä luettelo läpi. Jokainen epäonnistuva kohta kaventaa, missä todellinen ongelma on.
- Profiilin nimi ja laajuus vahvistettu,
-AllUserConnectionkäytetty koneenlaajuisissa profiileissa. SplitTunnelingluettu ja käsitelty kokoonpanona eikä todisteena kattavuudesta.- Tunnelisovittimen reitit lueteltu erikseen IPv4:lle ja IPv6:lle.
Find-NetRouteajettu yhdelle julkiselle, yhdelle sisäiselle ja yhdelle poikkeuskohteelle.- NRPT-säännöt tarkistettu ennen kuin reittejä syytettiin nimivirheestä.
- Estovaatimus luettu uudelleen: suosittu reititys ei ole sama kuin toteutettu esto.
Päätös täydestä tai split-tunnelista kuuluu profiilin omistajalle, ja Microsoftin reititysohjeet kuvaavat käyttäytymisen, jonka Windows toteuttaa, kun profiili asettaa sen. Microsoft: pakotettu ja split-tunnelointi on viite, jonka pidän auki tulostetta lukiessani.