Kā pārbaudīt, ko VPN sistēmā Windows faktiski maršrutē PowerShell
Pievienota VPN flīze nepierāda pārklājumu. Izlasiet saglabāto profila karodziņu, aktīvo maršrutu tabulu un NRPT noteikumus šajā secībā.
Es pievienoju VPN klientu Windows 11 klēpjdatorā, flīze pārgāja uz Connected, atvērās iekšēja failu koplietošana, un publiska vietne joprojām ielādējās tieši no biroja Wi-Fi. Šis maisījums izskatās kā salauzts tunelis. Taču tas ir normāls profila rezultāts, kas daļu trafika sūta pa VPN, bet pārējo atstāj fiziskajā adapterī. Piespiedu tunelēšana maina to, kuru noklusējuma maršrutu Windows dod priekšroku; tā nedzēš konkrētākus maršrutus un nesola, ka trafiks apstāsies, kad savienojums pārtrūks. Tālāk ir secība, kuru es ievēroju, kad klients apgalvo pārklājumu: klienta stāvoklis, saglabātais profils, piemērotie maršruti, atrisinātājs un tad reālās plūsmas.
Sāciet ar klientu un tad pārstājiet tam uzticēties
Klients ir pareizā sākuma vieta tikai tāpēc, ka tas pasaka, kurš profils ir aktīvs. Atveriet savienojuma rekvizītus un pierakstiet precīzu profila nosaukumu, vai tas izveidots pašreizējam lietotājam vai visiem datorā, un kurš adapters pēc savienošanas parādās ncpa.cpl. Manā testa klēpjdatorā adapters nesa profila nosaukumu, kas atviegloja maršrutu izvades lasīšanu. Citos datoros tas parādās kā WAN Miniport ieraksts, un nosaukums jums neko nepasaka.
To, ko klients nevar pateikt, ir pārklājums. Pievienota flīze apraksta tuneļa stāvokli, nevis galamērķu uzskaitījumu. Trešo pušu klienti arī uztur savu konfigurāciju, tāpēc vietējais Windows profils un katra tā īpašība, ko jūs lasīsiet, var nebūt saistīta ar to, ko šis klients instalēja. Ja VPN ienāca caur AnyConnect, OpenVPN GUI, WireGuard vai piegādātāja aģentu, zemāk minētās PowerShell pārbaudes lielākoties neattiecas, un tā vietā jums jālasa šī klienta paša split-tunnel un maršrutēšanas iestatījumi.
Lasiet saglabāto profilu, nevis flīzi
Vietējam Windows profilam (IKEv2, L2TP, SSTP vai MDM virzītam) saglabātais split-tunnel lēmums ir viena īpašība:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixPievienojiet -AllUserConnection, ja profils izveidots visiem ierīcē. Bez tā jūs lasāt pašreizējā lietotāja sarakstu, kas var būt tukšs vai saturēt citu ierakstu ar līdzīgu nosaukumu. Vērtība False laukā SplitTunneling nozīmē, ka profils saglabāts kā pilns tunelis: Windows instalē noklusējuma maršrutu caur VPN adapteri. True nozīmē split tunnel, un pārklājums tad pilnībā atkarīgs no maršrutiem un nosaukumu atrisināšanas noteikumiem, ko šis profils virza.
Uztveriet šo vērtību kā konfigurāciju, nevis novērojumu. Tā reģistrē, ko profils pieprasīja savienošanas brīdī. Windows var nonākt ar atšķirīgiem piemērotiem maršrutiem cita interfeisa konkrētāka maršruta, politikas iestatījuma vai iepriekšējā savienojuma atlikuma dēļ, tāpēc Būla vērtība nekad neatrisina jautājumu viena pati.
Salīdziniet saglabāto vērtību ar piemēroto maršrutu tabulu
Pēc savienošanas uzskaitiet maršrutus tuneļa adapterī, nevis ritiniet visu tabulu:
$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 ir noderīgā puse. Tā atbild uz jautājumu, uz kuru klients nekad neatbild: šim galamērķim kuru interfeisu un kuru avota adresi Windows faktiski izmantos? Palaidiet to iekšējam resursdatoram, publiskam resursdatoram un visam, ko uzskatāt par tīšu izņēmumu. Pilna tuneļa profilam publiskajai adresei būtu jārāda tuneļa interfeiss. Split-tunnel profils tur parasti rāda fizisko adapteri, kamēr iekšējie prefiksi joprojām tiek atrisināti uz VPN.
Divi slazdi izskaidro lielāko daļu ziņojumu «tas maršrutē nepareizajā virzienā». Viskonkrētākais prefikss vienmēr uzvar, tāpēc /24 fiziskajā adapterī pārspēj noklusējuma maršrutu VPN, lai cik zema būtu tuneļa metrika. Metrika tikai izšķir neizšķirtu starp viena prefiksa maršrutiem. Un IPv4 un IPv6 tiek izlemti atsevišķi: profils, kas aptver 0.0.0.0/0, var atstāt IPv6 vietējā saitē, tāpēc divkāršā steka vietne izskatās pa pusei tunelēta. Pirms secināt, ka tunelis ir kārtībā, pārbaudiet Get-NetRoute -AddressFamily IPv6.
| 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 |
Pārbaudiet nosaukumu atrisināšanu atsevišķi ar NRPT
Iekšējie nosaukumi, kas neizdodas, kamēr iekšējās IP adreses darbojas, norāda uz atrisinātāja politiku, nevis maršrutēšanu. Windows DNS katram nosaukumu apgabalam izlemj, izmantojot nosaukumu atrisināšanas politikas tabulu, kas nav atkarīga no maršrutu tabulas:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKad noteikums atbilst *.corp.example, vaicājumi šim nosaukumu apgabalam dodas uz tuneļa DNS serveriem, pat ja datu ceļš uz šiem serveriem split-tunnel režīmā paliek fiziskajā adapterī. Tāds ir dizains, un tāpēc pārlūka tests, kas atver publisku vietni, neko nepasaka par iekšējiem nosaukumiem. Ja adapters uzskaita gaidītos serverus, bet meklēšana joprojām dodas citur, salīdziniet NRPT noteikumu secību un pārbaudiet, vai konkrētāks nosaukumu apgabals nesakrīt pirmais.
Pārbaudiet plūsmas un tad izlemiet, ko jūs patiesībā prasījāt
Izejiet galamērķus fiksētā secībā, lai rezultātus varētu salīdzināt starp datoriem: publiska adrese, iekšēja adrese, iekšējs nosaukums un viens tīšs izņēmums, piemēram, vietējais printeris vai videozvans. Pierakstiet interfeisu un avota adresi, ko Find-NetRoute atgriež katram. Pēc jebkuras politikas izmaiņas pievienojieties no jauna un atkārtojiet tos pašus četrus pārbaudes; maršrutu tabula pēc atkārtotas pievienošanas ir vienīgais pierādījums, ka jaunais profils stājās spēkā.
Pēc tam atdaliet maršrutēšanu no izpildes. Piespiedu tunelēšana dod priekšroku tunelim aptvertajam trafikam, kamēr tas ir augšā. Tas nav kill switch. Ja prasība ir, lai nekas neizietu no datora, kad tunelis krīt, tam jānāk no bloķējoša dizaina: ar tuneļa stāvokli saistīts ugunsmūra profils, vienmēr ieslēgts profils ar trafika filtriem vai piegādātāja klienta paša aizvēršanas atteices gadījumā opcija. Piespiedu tunelēšanai arī jāatstāj VPN servera paša adrese sasniedzama ārpus tuneļa, un tās bloķēšana «visa piespiešanas» vārdā ir uzticams veids, kā noslēgt sevi ārpus savienojuma, kuru mēģināt ieviest.
Pirms kaut ko maināt, izejiet šo sarakstu. Katrs neizdevušais punkts sašaurina, kur ir īstā problēma.
- Profila nosaukums un tvērums apstiprināti,
-AllUserConnectionizmantots visam datoram paredzētiem profiliem. SplitTunnelingnolasīts un uztverts kā konfigurācija, nevis pārklājuma pierādījums.- Tuneļa adaptera maršruti uzskaitīti atsevišķi IPv4 un IPv6.
Find-NetRoutepalaists vienam publiskam, vienam iekšējam un vienam izņēmuma galamērķim.- NRPT noteikumi pārbaudīti, pirms vainot maršrutus nosaukuma neizdevumā.
- Bloķēšanas prasība pārlasīta: vēlamā maršrutēšana nav tas pats, kas ieviesta bloķēšana.
Lēmums par pilnu vai split tuneli pieder profila īpašniekam, un Microsoft maršrutēšanas piezīmes apraksta uzvedību, ko Windows ievieš, kad profils to iestata. Microsoft: piespiedu un split tunelēšana ir atsauce, ko turu atvērtu, lasot izvadi.