Windows-da VPN-in PowerShell-də həqiqətən nəyi yönəltdiyini necə yoxlamaq olar

Windows 11 noutbukda VPN müştərisini qoşdum, plitə «Qoşuldu» vəziyyətinə keçdi, daxili fayl paylaşımı açıldı, amma açıq sayt yenə də birbaşa ofis Wi-Fi-dan yükləndi. Bu qarışıq pozulmuş tunel kimi görünür. Bu, trafikin bir hissəsini VPN-dən keçirib qalanını fiziki adapterdə saxlayan profilin normal nəticəsidir. Məcburi tunelleşdirmə Windows-un hansı default marşruta üstünlük verdiyini dəyişir; daha dəqiq marşrutları silmir və əlaqə kəsiləndə trafikin dayanacağına zəmanət vermir. Bundan sonra müştəri əhatə iddia edəndə işlədiyim sıra belədir: müştəri vəziyyəti, saxlanılan profil, tətbiq olunmuş marşrutlar, həlledici, sonra real axınlar.

Müştəridən başlayın, sonra ona etibar etməyi dayandırın

Müştəri yalnız hansı profilin aktiv olduğunu dediyi üçün başlamaq üçün düzgün yerdir. Qoşulma xassələrini açın və dəqiq profil adını, onun cari istifadəçi üçün, yoxsa maşındakı hamı üçün yaradıldığını və qoşulduqdan sonra ncpa.cpl-də hansı adapterin göründüyünü qeyd edin. Test noutbukumda adapter profil adını daşıyırdı və bu, marşrut çıxışını oxumağı asanlaşdırırdı. Digər maşınlarda o, WAN Miniport girişi kimi görünür və ad sizə heç nə demir.

Müştərinin deyə bilmədiyi şey əhatədir. Qoşulmuş plitə tunelin vəziyyətini təsvir edir, təyinatların inventarını yox. Üçüncü tərəf müştəriləri də öz konfiqurasiyalarını saxlayır, ona görə doğma Windows profili və ondan oxuyacağınız hər xassə o müştərinin quraşdırdığı şeylə heç bir əlaqəsi olmaya bilər. VPN AnyConnect, OpenVPN GUI, WireGuard və ya satıcı agenti ilə gəlibsə, aşağıdakı PowerShell yoxlamaları çox vaxt tətbiq olunmur və əvəzində həmin müştərinin öz split-tunnel və marşrut parametrlərini oxumalısınız.

Saxlanılan profili oxuyun, plitəni yox

Doğma Windows profili üçün (IKEv2, L2TP, SSTP və ya MDM tərəfindən itələnən) saxlanılan split-tunnel qərarı tək bir xassədir:

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

Profil cihazdakı hamı üçün yaradılıbsa -AllUserConnection əlavə edin. Onsuz cari istifadəçinin siyahısını oxuyursunuz; bu siyahı boş ola bilər və ya oxşar adlı başqa giriş saxlaya bilər. False dəyəri SplitTunneling-də profilin tam tunel kimi saxlandığını bildirir: Windows VPN adapteri vasitəsilə default marşrut quraşdırır. True split tunel deməkdir və əhatə tamamilə profilin itələdiyi marşrutlardan və ad həlli qaydalarından asılı olur.

Bu dəyəri müşahidə kimi deyil, konfiqurasiya kimi qəbul edin. O, profilin qoşulma anında nə istədiyini qeyd edir. Windows fərqli tətbiq olunmuş marşrutlarla qala bilər: başqa interfeysin daha dəqiq marşrutu, siyasət parametri və ya əvvəlki qoşulmadan qalıq giriş buna səbəb ola bilər, ona görə Boolean sualı təkbaşına həll etmir.

Saxlanılan dəyəri tətbiq olunmuş marşrut cədvəli ilə müqayisə edin

Qoşulduqdan sonra bütün cədvəli sürüşdürmək əvəzinə tunel adapterindəki marşrutları sadalayı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 faydalı yarıdır. O, müştərinin heç vaxt cavablandırmadığı suala cavab verir: bu təyinat üçün Windows hansı interfeysi və hansı mənbə ünvanını həqiqətən istifadə edəcək? Bunu daxili host, açıq host və qəsdən istisna saydığınız hər şey üçün işlədin. Tam tunel profili açıq ünvan üçün tunel interfeysini göstərməlidir. Split tunel profili adətən orada fiziki adapteri göstərir, daxili prefikslər isə yenə VPN-ə həll olunur.

İki tələ «səhv istiqamətə yönəldir» hesabatlarının çoxunu izah edir. Ən dəqiq prefiks həmişə qalib gəlir, ona görə fiziki adapterdəki /24 tunel metrikası nə qədər aşağı olsa da VPN-dəki default marşrutu üstələyir. Metrika yalnız eyni prefiksli marşrutlar arasında bərabərliyi pozur. Və IPv4 ilə IPv6 ayrıca qərarlaşdırılır: 0.0.0.0/0-ı əhatə edən profil IPv6-nı yerli linkdə qoya bilər və bu, iki yığınlı saytı yarım tunellənmiş göstərir. Tunelin qaydasında olduğu qənaətinə gəlməzdən əvvəl Get-NetRoute -AddressFamily IPv6 yoxlayın.

Ad həllini NRPT ilə ayrıca yoxlayın

Daxili adlar uğursuz olub daxili IP ünvanları işləyəndə bu, marşruta deyil, həlledici siyasətinə işarə edir. Windows DNS-i hər ad sahəsi üçün Ad Həlli Siyasəti Cədvəli vasitəsilə qərar verir və bu, marşrut cədvəlindən asılı deyil:

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

Qayda *.corp.example ilə uyğunlaşanda həmin ad sahəsi üçün sorğular tunelin DNS serverlərinə gedir, hətta split tunel rejimində həmin serverlərə data yolu fiziki adapterdə qalsa belə. Dizayn budur və buna görə açıq sayt açan brauzer testi daxili adlar haqqında sizə heç nə demir. Adapter gözlənilən serverləri sadalayır, lakin axtarışlar yenə başqa yerə gedirsə, NRPT qayda sırasını müqayisə edin və daha dəqiq ad sahəsinin əvvəl uyğunlaşıb-uyğunlaşmadığını yoxlayın.

Axınları yoxlayın, sonra əslində nə istədiyinizə qərar verin

Nəticələr maşınlar arasında müqayisə oluna bilsin deyə təyinatları sabit sıra ilə işləyin: açıq ünvan, daxili ünvan, daxili ad və yerli printer və ya video zəng kimi bir qəsdən istisna. Hər biri üçün Find-NetRoute-nin qaytardığı interfeysi və mənbə ünvanını qeyd edin. Hər hansı siyasət dəyişikliyindən sonra yenidən qoşulun və eyni dörd yoxlamanı təkrarlayın; yeni profilin qüvvəyə mindiyinə dair yeganə dəlil yenidən qoşulmadan sonrakı marşrut cədvəlidir.

Sonra marşrutlaşdırmanı məcbur etmədən ayırın. Məcburi tunelleşdirmə əhatə olunan trafik üçün tunel qalxanda tuneli üstün tutur. O, dayandırma açarı deyil. Tələb tunel düşəndə heç nəyin maşından çıxmamasıdırsa, bu, bloklayıcı dizayndan gəlməlidir: tunel vəziyyətinə bağlı firewall profili, trafik filtrləri olan həmişə-açıq profil və ya satıcı müştərisinin öz uğursuzluqda-bağlama seçimi. Məcburi tunelleşdirmə həm də VPN serverinin öz ünvanını tuneldən kənarda əlçatan saxlamalıdır və «hər şeyi məcbur etmək» adına onu bloklamaq, məcbur etməyə çalışdığınız bağlantıdan özünüzü kilidləməyin etibarlı yoludur.

Nəyisə dəyişməzdən əvvəl bu siyahıdan keçin. Uğursuz olan hər bənd əsl problemin yerini daraldır.

• Profil adı və əhatəsi təsdiqləndi, maşın üzrə profillər üçün -AllUserConnection istifadə olunur.
• SplitTunneling oxundu və əhatə sübutu deyil, konfiqurasiya kimi qəbul edildi.
• Tunel adapterinin marşrutları IPv4 və IPv6 üçün ayrıca sadalandı.
• Bir açıq, bir daxili və bir istisna təyinat üçün Find-NetRoute işlədildi.
• Ad uğursuzluğuna görə marşrutları günahlandırmazdan əvvəl NRPT qaydaları yoxlanıldı.
• Bloklama tələbi yenidən oxundu: üstün tutulan marşrutlaşdırma məcbur edilmiş bloklama ilə eyni deyil.

Tam tunel və split tunel qərarı profilin sahibinə aiddir və Microsoft-un marşrut qeydləri profilin təyin etdiyi zaman Windows-un tətbiq etdiyi davranışı təsvir edir. Microsoft: məcburi və split tunelleşdirmə çıxışı oxuyarkən açıq saxladığım mənbədir.