Kako provjeriti šta VPN na Windowsu zapravo usmjerava u PowerShellu
Povezana VPN pločica ne dokazuje pokrivenost. Pročitajte sačuvanu zastavicu profila, živu tablicu ruta i NRPT pravila ovim redom.
Povezao sam VPN klijent na prijenosnom računaru sa Windows 11, pločica je prešla u Connected, otvorio se interni dijeljeni fajl, a javni sajt se i dalje učitavao direktno sa uredskog Wi-Fi-ja. Ta mješavina izgleda kao pokvaren tunel. To je normalan izlaz profila koji dio saobraćaja šalje kroz VPN a ostatak ostavlja na fizičkom adapteru. Prinudno tuneliranje mijenja koju zadatu rutu Windows preferira; ne briše specifičnije rute i ne obećava da će saobraćaj stati kad veza padne. Ono što slijedi je redoslijed kojim radim kad klijent tvrdi pokrivenost: stanje klijenta, sačuvani profil, primijenjene rute, razrješivač, pa stvarni tokovi.
Počnite od klijenta, pa prestanite da mu vjerujete
Klijent je pravo mjesto za početak samo zato što vam kaže koji je profil aktivan. Otvorite svojstva veze i zabilježite tačan naziv profila, da li je napravljen za trenutnog korisnika ili za sve na računaru, i koji se adapter pojavljuje u ncpa.cpl nakon povezivanja. Na mom testnom prijenosniku adapter je nosio naziv profila, što je olakšalo čitanje izlaza ruta. Na drugim računarima pojavljuje se kao WAN Miniport unos i naziv vam ne govori ništa.
Ono što vam klijent ne može reći jeste pokrivenost. Povezana pločica opisuje stanje tunela, a ne popis odredišta. Klijenti trećih strana takođe drže vlastitu konfiguraciju, pa izvorni Windows profil, i svako svojstvo koje ćete iz njega pročitati, možda nema nikakve veze s onim što je taj klijent instalirao. Ako je VPN stigao kroz AnyConnect, OpenVPN GUI, WireGuard ili agenta dobavljača, donje PowerShell provjere uglavnom se ne primjenjuju i umjesto toga treba čitati vlastita podešavanja split-tunela i rutiranja tog klijenta.
Čitajte sačuvani profil, a ne pločicu
Za izvorni Windows profil (IKEv2, L2TP, SSTP, ili onaj koji gura MDM) sačuvana odluka o split-tunelu je jedno svojstvo:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixDodajte -AllUserConnection kad je profil napravljen za sve na uređaju. Bez toga čitate listu trenutnog korisnika, koja može biti prazna ili držati drugi unos sličnog naziva. Vrijednost False u SplitTunneling znači da je profil sačuvan kao puni tunel: Windows instalira zadatu rutu kroz VPN adapter. True znači split tunel, a pokrivenost tada potpuno zavisi od ruta i pravila razrješavanja imena koje taj profil gura.
Tretirajte tu vrijednost kao konfiguraciju, ne kao opažanje. Ona bilježi šta je profil tražio u trenutku povezivanja. Windows može završiti s drukčijim primijenjenim rutama — zbog specifičnije rute drugog interfejsa, postavke politike ili ostatka unosa iz prethodne veze, pa logička vrijednost nikada ne rješava pitanje sama.
Uporedite sačuvanu vrijednost s primijenjenom tablicom ruta
Nakon povezivanja, izlistajte rute na tunelskom adapteru umjesto da skrolate cijelu tablicu:
$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 je korisna polovina. Odgovara na pitanje koje klijent nikad ne odgovara: za ovo odredište, koji interfejs i koja izvorna adresa će Windows stvarno koristiti? Pokrenite ga za interni host, javni host i sve što smatrate namjernim izuzetkom. Profil punog tunela treba pokazati tunelski interfejs za javnu adresu. Profil split tunela obično tamo pokazuje fizički adapter, dok se interni prefiksi još razrješavaju kroz VPN.
Dvije zamke objašnjavaju većinu izvještaja „ruta ide u pogrešnom smjeru“. Najspecifičniji prefiks uvijek pobjeđuje, pa /24 na fizičkom adapteru pobjeđuje zadatu rutu na VPN-u koliko god niska bila metrika tunela. Metrika samo razrješava izjednačenje između ruta za isti prefiks. A IPv4 i IPv6 se odlučuju odvojeno: profil koji pokriva 0.0.0.0/0 može ostaviti IPv6 na lokalnom linku, zbog čega dual-stack sajt izgleda napola tuneliran. Provjerite Get-NetRoute -AddressFamily IPv6 prije nego zaključite da je tunel u redu.
| 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 |
Provjerite razrješavanje imena odvojeno pomoću NRPT-a
Interna imena koja ne rade dok interne IP adrese rade upućuju na politiku razrješivača, a ne na rutiranje. Windows odlučuje DNS po imenskom prostoru kroz tablicu politike razrješavanja imena, koja je nezavisna od tablice ruta:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKad pravilo odgovara *.corp.example, upiti za taj imenski prostor idu na DNS servere tunela čak i ako data put do tih servera ostaje na fizičkom adapteru u split-tunel režimu. Takav je dizajn i zato test u pregledniku koji otvori javni sajt ne govori ništa o internim imenima. Ako adapter navodi očekivane servere ali pretrage i dalje idu drugdje, uporedite redoslijed NRPT pravila i provjerite da li se specifičniji imenski prostor podudara prvi.
Provjerite tokove, pa odlučite šta ste zapravo tražili
Prođite kroz odredišta u fiksnom redu da rezultati budu uporedivi među računarima: javna adresa, interna adresa, interno ime i jedan namjerni izuzetak kao što je lokalni printer ili video poziv. Zabilježite interfejs i izvornu adresu koje Find-NetRoute vraća za svako. Nakon svake promjene politike ponovo se povežite i ponovite iste četiri provjere; tablica ruta nakon ponovnog povezivanja jedini je dokaz da je novi profil stupio na snagu.
Zatim razdvojite rutiranje od provođenja. Prinudno tuneliranje preferira tunel za pokriveni saobraćaj dok je podignut. To nije kill switch. Ako je zahtjev da ništa ne napušta računar kad tunel padne, to mora doći iz blokirajućeg dizajna: firewall profil vezan za stanje tunela, profil stalno-uključen sa filterima saobraćaja ili vlastita opcija zatvaranja na neuspjeh u klijentu dobavljača. Prinudno tuneliranje takođe mora ostaviti vlastitu adresu VPN servera dostupnom izvan tunela, a blokiranje iste u ime „forsiranja svega“ pouzdan je način da se zaključate iz veze koju pokušavate provesti.
Prije nego što bilo šta promijenite, prođite ovu listu. Svaka stavka koja padne sužava gdje je pravi problem.
- Naziv i obim profila potvrđeni, s
-AllUserConnectionza profile na nivou računara. SplitTunnelingpročitan i tretiran kao konfiguracija, a ne dokaz pokrivenosti.- Rute tunelskog adaptera izlistane odvojeno za IPv4 i IPv6.
Find-NetRoutepokrenut za jedno javno, jedno interno i jedno izuzetno odredište.- NRPT pravila provjerena prije nego što rute okrivite za neuspjeh imena.
- Zahtjev za blokiranje ponovo pročitan: preferirano rutiranje nije isto što i provedeno blokiranje.
Odluka o punom ili split tunelu pripada onome ko posjeduje profil, a Microsoftove bilješke o rutiranju opisuju ponašanje koje Windows primjenjuje kad ga profil postavi. Microsoft: prinudno i split tuneliranje referenca je koju držim otvorenom dok čitam izlaz.