Windows'ta bir VPN'in PowerShell'de gerçekte neyi yönlendirdiğini nasıl denetlersiniz

Bağlı VPN kutucuğu kapsama kanıtlamaz. Kayıtlı profil bayrağını, canlı yol tablosunu ve NRPT kurallarını bu sırayla okuyun.

VPN istemcisini bir Windows 11 dizüstü bilgisayarda bağladım, kutucuk Connected durumuna geçti, dahili bir dosya paylaşımı açıldı ve bir genel site hâlâ doğrudan ofisin Wi-Fi ağından yükleniyordu. Bu karışım bozuk bir tünel gibi görünüyor. Oysa bu, trafiğin bir kısmını VPN üzerinden gönderip geri kalanını fiziksel bağdaştırıcıda bırakan bir profilin normal çıktısıdır. Zorlamalı tünelleme, Windows'un hangi varsayılan yolu tercih ettiğini değiştirir; daha belirgin yolları silmez ve bağlantı koptuğunda trafiğin duracağını vaat etmez. Aşağıdakiler, bir istemci kapsama iddia ettiğinde izlediğim sıradır: istemci durumu, kayıtlı profil, uygulanan yollar, çözümleyici ve ardından gerçek akışlar.

İstemciden başlayın, sonra ona güvenmeyi bırakın

İstemci, yalnızca hangi profilin etkin olduğunu söylediği için doğru başlangıç noktasıdır. Bağlantı özelliklerini açın ve tam profil adını, bunun geçerli kullanıcı için mi yoksa makinedeki herkes için mi oluşturulduğunu ve bağlandıktan sonra ncpa.cpl içinde hangi bağdaştırıcının göründüğünü not edin. Test dizüstü bilgisayarımda bağdaştırıcı profil adını taşıyordu, bu da yol çıktısını okumayı kolaylaştırdı. Diğer makinelerde WAN Miniport girdisi olarak görünür ve ad size hiçbir şey söylemez.

İstemcinin size söyleyemeyeceği şey kapsamadır. Bağlı kutucuk tünelin durumunu açıklar, hedeflerin envanterini değil. Üçüncü taraf istemciler de kendi yapılandırmalarını tutar, bu nedenle yerel Windows profili ve ondan okuyacağınız her özellik, o istemcinin kurduğu şeyle ilgili olmayabilir. VPN AnyConnect, OpenVPN GUI, WireGuard veya bir satıcı aracısı üzerinden geldiyse aşağıdaki PowerShell denetimleri çoğunlukla geçerli değildir ve bunun yerine o istemcinin kendi split-tunnel ve yönlendirme ayarlarını okumalısınız.

Kayıtlı profili okuyun, kutucuğu değil

Yerel Windows profili için (IKEv2, L2TP, SSTP veya MDM tarafından itilen bir profil) kayıtlı split-tunnel kararı tek bir özelliktir:

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

Profil cihazdaki herkes için oluşturulduysa -AllUserConnection ekleyin. Bu olmadan geçerli kullanıcının listesini okursunuz; bu liste boş olabilir veya benzer adlı başka bir girdi içerebilir. False değeri SplitTunneling içinde olması, profilin tam tünel olarak kaydedildiği anlamına gelir: Windows, VPN bağdaştırıcısı üzerinden varsayılan bir yol kurar. True split tunnel anlamına gelir ve kapsama tamamen o profilin ittiği yollara ve ad çözümleme kurallarına bağlıdır.

Bu değeri yapılandırma olarak ele alın, gözlem olarak değil. Bağlantı anında profilin ne istediğini kaydeder. Windows, başka bir arabirimin daha belirgin yolu, bir ilke ayarı veya önceki bir bağlantıdan kalan girdi nedeniyle farklı uygulanan yollarla sonuçlanabilir, bu nedenle Boolean soruyu tek başına asla çözmez.

Kayıtlı değeri uygulanan yol tablosuyla karşılaştırın

Bağlandıktan sonra tüm tabloyu kaydırmak yerine tünel bağdaştırıcısındaki yolları listeleyin:

$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 yararlı olan yarıdır. İstemcinin asla yanıtlamadığı soruyu yanıtlar: bu hedef için Windows hangi arabirimi ve hangi kaynak adresi gerçekte kullanacak? Bunu dahili bir ana bilgisayar, genel bir ana bilgisayar ve kasıtlı istisna saydığınız her şey için çalıştırın. Tam tünel profili genel adres için tünel arabirimini göstermelidir. Split tunnel profili genellikle orada fiziksel bağdaştırıcıyı gösterirken dahili önekler hâlâ VPN'e çözümlenir.

«Yanlış yöne yönlendiriyor» bildirimlerinin çoğunu iki tuzak açıklar. En belirgin önek her zaman kazanır, bu nedenle fiziksel bağdaştırıcıdaki /24, tünelin ölçütü ne kadar düşük olursa olsun VPN'deki varsayılan yolu yener. Ölçüt yalnızca aynı önek için yollar arasındaki eşitliği bozar. Ve IPv4 ile IPv6 ayrı ayrı kararlaştırılır: 0.0.0.0/0 kapsayan bir profil IPv6'yı yerel bağlantıda bırakabilir ve bu da çift yığınlı bir siteyi yarı tünellenmiş gösterir. Tünelin iyi olduğu sonucuna varmadan önce Get-NetRoute -AddressFamily IPv6 denetleyin.

What you seeMost likely causeCheck next
Public traffic leaves the physical adapter while SplitTunneling reads FalseA more specific route on that adapter wins over the tunnel defaultFind-NetRoute for the exact destination, then look for a /24 or host route on the physical interface
Internal name fails, internal IP worksNo NRPT rule for that namespace, or a broader rule matches firstGet-DnsClientNrptPolicy and the namespace order
A dual-stack site opens directly while IPv4 uses the tunnelThe profile covers only the IPv4 default routeThe IPv6 route table on both interfaces
Routes look right but one app still goes directThe app uses its own proxy, or the client keeps a per-app listThe app's proxy settings and the client's application list

Ad çözümlemeyi NRPT ile ayrıca denetleyin

Dahili adlar başarısız olurken dahili IP adresleri çalışıyorsa bu yönlendirmeye değil çözümleyici ilkesine işaret eder. Windows her ad alanı için DNS'i ad çözümleme ilkesi tablosu üzerinden belirler ve bu tablo yol tablosundan bağımsızdır:

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

Bir kural *.corp.example ile eşleştiğinde o ad alanı için sorgular tünelin DNS sunucularına gider, split tunnel modunda bu sunuculara giden veri yolu fiziksel bağdaştırıcıda kalsa bile. Tasarım budur ve bu nedenle genel bir siteyi açan tarayıcı testi dahili adlar hakkında hiçbir şey söylemez. Bağdaştırıcı beklenen sunucuları listeliyor ama aramalar yine başka yere gidiyorsa NRPT kural sırasını karşılaştırın ve daha belirgin bir ad alanının önce eşleşip eşleşmediğini denetleyin.

Akışları doğrulayın, sonra gerçekte ne istediğinize karar verin

Sonuçlar makineler arasında karşılaştırılabilir olsun diye hedefleri sabit bir sırayla inceleyin: genel adres, dahili adres, dahili ad ve yerel yazıcı ya da görüntülü görüşme gibi kasıtlı bir istisna. Her biri için Find-NetRoute'nin döndürdüğü arabirimi ve kaynak adresi not edin. Herhangi bir ilke değişikliğinden sonra yeniden bağlanın ve aynı dört denetimi yineleyin; yeniden bağlanma sonrası yol tablosu yeni profilin yürürlüğe girdiğinin tek kanıtıdır.

Ardından yönlendirmeyi zorlamadan ayırın. Zorlamalı tünelleme, tünel ayaktayken kapsanan trafik için tüneli tercih eder. Bu bir kill switch değildir. Gereksinim tünel düştüğünde makineden hiçbir şeyin çıkmamasıysa bu, engelleyen bir tasarımdan gelmelidir: tünel durumuna bağlı bir güvenlik duvarı profili, trafik filtreleri olan sürekli açık bir profil veya satıcı istemcisinin kendi hatada-kapanma seçeneği. Zorlamalı tünelleme ayrıca VPN sunucusunun kendi adresini tünelin dışından erişilebilir bırakmalıdır ve bunu «her şeyi zorla» adına engellemek, uygulamaya çalıştığınız bağlantıdan kendinizi kilitlemenin güvenilir bir yoludur.

Herhangi bir şeyi değiştirmeden önce bu listeyi gözden geçirin. Başarısız olan her madde gerçek sorunun nerede olduğunu daraltır.

  • Profil adı ve kapsamı doğrulandı, makine geneli profiller için -AllUserConnection kullanıldı.
  • SplitTunneling okundu ve kapsama kanıtı değil, yapılandırma olarak ele alındı.
  • Tünel bağdaştırıcısının yolları IPv4 ve IPv6 için ayrı ayrı listelendi.
  • Find-NetRoute bir genel, bir dahili ve bir istisna hedef için çalıştırıldı.
  • Ad hatası için yolları suçlamadan önce NRPT kuralları denetlendi.
  • Engelleme gereksinimi yeniden okundu: tercih edilen yönlendirme, uygulanan engellemeyle aynı değildir.

Tam veya split tünel kararı profilin sahibine aittir ve Microsoft'un yönlendirme notları, bir profil bunu ayarladığında Windows'un uyguladığı davranışı açıklar. Microsoft: zorlamalı ve split tünelleme çıktıyı okurken açık tuttuğum başvurudur.

İlgili makaleler