Si të kontrolloni çfarë rrugëton në të vërtetë një VPN në Windows në PowerShell

Lidha klientin VPN në një laptop me Windows 11, pllaka kaloi në Connected, u hap një ndarje e brendshme skedarësh dhe një faqe publike ende ngarkohej drejtpërdrejt nga Wi-Fi i zyrës. Kjo përzierje duket si tunel i prishur. Është rezultati normal i një profili që dërgon një pjesë të trafikut përmes VPN-së dhe lë pjesën tjetër në përshtatësin fizik. Tunelimi i detyruar ndryshon cilën rrugë të paracaktuar preferon Windows; nuk fshin rrugë më specifike dhe nuk premton se trafiku ndalon kur lidhja bie. Në vijim është rendi që ndjek kur një klient pretendon mbulim: gjendja e klientit, profili i ruajtur, rrugët e aplikuara, zgjidhësi dhe më pas rrjedhat reale.

Filloni te klienti dhe më pas ndaloni së besuari atij

Klienti është vendi i duhur për të filluar vetëm sepse ju tregon cili profil është aktiv. Hapni vetitë e lidhjes dhe shënoni emrin e saktë të profilit, nëse është krijuar për përdoruesin aktual ose për të gjithë në makinë, dhe cili përshtatës shfaqet në ncpa.cpl pas lidhjes. Në laptopin tim të provës përshtatësi mbante emrin e profilit, gjë që e bënte lehtë të lexohej dalja e rrugëve. Në makina të tjera shfaqet si një zë WAN Miniport dhe emri nuk ju thotë asgjë.

Ajo që klienti nuk mund t'ju thotë është mbulimi. Një pllakë e lidhur përshkruan gjendjen e tunelit, jo një inventar destinacionesh. Klientët e palëve të treta mbajnë gjithashtu konfigurimin e tyre, prandaj profili origjinal i Windows, dhe çdo veti që do të lexoni prej tij, mund të mos ketë asnjë lidhje me atë që instaloi ai klient. Nëse VPN-ja erdhi përmes AnyConnect, OpenVPN GUI, WireGuard ose një agjenti të furnizuesit, kontrollet PowerShell më poshtë në përgjithësi nuk zbatohen dhe në vend të tyre duhet të lexoni cilësimet e split-tunnel dhe të rrugëtimit të atij klienti.

Lexoni profilin e ruajtur, jo pllakën

Për një profil origjinal të Windows (IKEv2, L2TP, SSTP ose një të shtyrë nga MDM), vendimi i ruajtur për split-tunnel është një veti e vetme:

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

Shtoni -AllUserConnection kur profili është krijuar për të gjithë në pajisje. Pa atë lexoni listën e përdoruesit aktual, e cila mund të jetë bosh ose të përmbajë një zë tjetër me emër të ngjashëm. Vlera False në SplitTunneling do të thotë që profili u ruajt si tunel i plotë: Windows instalon një rrugë të paracaktuar përmes përshtatësit VPN. True do të thotë split tunnel, dhe mbulimi atëherë varet plotësisht nga rrugët dhe rregullat e zgjidhjes së emrave që shtyn ai profil.

Trajtojeni atë vlerë si konfigurim, jo si vëzhgim. Ajo regjistron çfarë kërkoi profili në momentin e lidhjes. Windows mund të përfundojë me rrugë të aplikuara të ndryshme, për shkak të një rruge më specifike të një ndërfaqeje tjetër, një cilësimi politike ose një zëri të mbetur nga një lidhje e mëparshme, kështu që vlera booleane nuk e zgjidh kurrë vetë pyetjen.

Krahasoni vlerën e ruajtur me tabelën e aplikuar të rrugëve

Pas lidhjes, listoni rrugët në përshtatësin e tunelit në vend që të rrëshqitni të gjithë tabelën:

$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

Find-NetRoute është gjysma e dobishme. Ai i përgjigjet pyetjes që klienti nuk i përgjigjet kurrë: për këtë destinacion, cila ndërfaqe dhe cila adresë burimore do të përdorë Windows në të vërtetë? Ekzekutojeni për një host të brendshëm, një host publik dhe gjithçka që mendoni se është përjashtim i qëllimshëm. Një profil tuneli të plotë duhet të tregojë ndërfaqen e tunelit për adresën publike. Një profil split tunnel zakonisht tregon atje përshtatësin fizik, ndërsa prefikset e brendshme ende zgjidhen te VPN-ja.

Dy kurthe shpjegojnë shumicën e raporteve «rrugëton në drejtimin e gabuar». Prefiksi më specifik fiton gjithmonë, prandaj një /24 në përshtatësin fizik mund një rrugë të paracaktuar në VPN, sado e ulët të jetë metrika e tunelit. Metrika vendos vetëm barazime midis rrugëve për të njëjtin prefiks. Dhe IPv4 dhe IPv6 vendosen veçmas: një profil që mbulon 0.0.0.0/0 mund ta lërë IPv6 në lidhjen lokale, gjë që e bën një faqe me dy stiva të duket gjysmë e tunelizuar. Kontrolloni Get-NetRoute -AddressFamily IPv6 përpara se të përfundoni se tuneli është në rregull.

Kontrolloni zgjidhjen e emrave veçmas me NRPT

Emrat e brendshëm që dështojnë ndërsa adresat IP të brendshme funksionojnë tregojnë politikën e zgjidhësit, jo rrugëtimin. Windows vendos DNS për çdo hapësirë emrash përmes tabelës së politikës së zgjidhjes së emrave, e cila është e pavarur nga tabela e rrugëve:

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

Kur një rregull përputhet me *.corp.example, pyetësorët për atë hapësirë emrash shkojnë te serverët DNS të tunelit edhe nëse rruga e të dhënave drejt këtyre serverëve në modalitetin split tunnel mbetet në përshtatësin fizik. I tillë është dizajni dhe për këtë arsye një test shfletuesi që hap një faqe publike nuk ju thotë asgjë për emrat e brendshëm. Nëse përshtatësi liston serverët e pritur, por kërkimet vazhdojnë të shkojnë diku tjetër, krahasoni rendin e rregullave NRPT dhe kontrolloni nëse një hapësirë emrash më specifike përputhet e para.

Verifikoni rrjedhat dhe më pas vendosni çfarë kërkuat në të vërtetë

Kalon nëpër destinacionet në një rend fiks që rezultatet të jenë të krahasueshme midis makinave: një adresë publike, një adresë e brendshme, një emër i brendshëm dhe një përjashtim i qëllimshëm si një printer lokal ose një thirrje video. Shënoni ndërfaqen dhe adresën burimore që Find-NetRoute kthen për secilin. Pas çdo ndryshimi politike, rilidhuni dhe përsëritni të njëjtat katër kontrolle; tabela e rrugëve pas rilidhjes është prova e vetme që profili i ri hyri në fuqi.

Më pas ndani rrugëtimin nga zbatimi. Tunelimi i detyruar preferon tunelin për trafikun e mbuluar sa kohë është lart. Nuk është një kill switch. Nëse kërkesa është që asgjë të mos largohet nga makina kur tuneli bie, kjo duhet të vijë nga një dizajn bllokues: një profil firewalls i lidhur me gjendjen e tunelit, një profil gjithmonë aktiv me filtra trafiku ose opsioni i vetë klientit të furnizuesit për mbyllje në dështim. Tunelimi i detyruar duhet gjithashtu ta lërë adresën e vetë serverit VPN të arritshme jashtë tunelit, dhe bllokimi i saj në emër të «detyrimit të gjithçkaje» është një mënyrë e sigurt për t'u mbyllur jashtë lidhjes që po përpiqeni të zbatoni.

Përpara se të ndryshoni ndonjë gjë, kaloni nëpër këtë listë. Çdo artikull që dështon ngushton ku qëndron problemi i vërtetë.

• Emri dhe shtrirja e profilit u konfirmuan, me -AllUserConnection të përdorur për profile në nivel makine.
• SplitTunneling u lexua dhe u trajtua si konfigurim, jo si provë e mbulimit.
• Rrugët e përshtatësit të tunelit u listuan veçmas për IPv4 dhe IPv6.
• Find-NetRoute u ekzekutua për një destinacion publik, një të brendshëm dhe një përjashtim.
• Rregullat NRPT u kontrolluan përpara se rrugët të fajësoheshin për një dështim emri.
• Kërkesa për bllokim u rilexua: rrugëtimi i preferuar nuk është i njëjtë me bllokimin e zbatuar.

Vendimi për tunel të plotë ose split i takon pronarit të profilit, dhe shënimet e Microsoft për rrugëtimin përshkruajnë sjelljen që Windows zbaton kur një profil e vendos atë. Microsoft: tunelimi i detyruar dhe split është referenca që mbaj hapur ndërsa lexoj daljen.