VPN Windows'ta yerel LAN'ı engelliyor: rota mı, istemci politikası mı?

Kendi masanızdaki yazıcı, NAS ya da geliştirme makinesi iş VPN'i bağlandığı anda yanıt vermeyi keser. Bazen tek bir rota komutu bunu saniyeler içinde düzeltir; bazen aynı rota doğrudur ve paketler yine de kaybolur, bu da benzer belirtili başka bir soruna baktığınız anlamına gelir. Karar üç soruya iner ve bunları yanlış sırayla sormak insanların bütün akşamı rotaları silip yeniden ekleyerek geçirmesinin nedenidir.

Herhangi bir komuttan önce üç soru

Birincisi: yerel önek için bir girdi var mı ve fiziksel bağdaştırıcıya mı işaret ediyor? İkincisi: istemci bağlanırken ağ geçidinden yerel ağ için izin ya da ret alıyor mu? Üçüncüsü: yalnızca LAN'a giden erişime mi ihtiyacınız var, yoksa internetteki bir şeyin de makinenizde çalışan bir hizmete ulaşması mı gerekiyor?

İlk soru yönlendirme arızasını filtreleme arızasından ayırır. İkincisi bir rota düzeltmesinin çalışmasına izin verilip verilmediğini söyler. Üçüncüsü onarımı değiştirir: rota giden trafiği düzeltir, oysa ulaşılamayan gelen hizmet genellikle dinleyici bağlaması ve dönüş yolu sorunudur ve rotayı daha da kötüleştirir.

Soru bir: rota, filtre ya da ad

Herhangi bir şey eklemeden önce tabloyu okuyun. Arayüz dizini önemlidir, çünkü aşağıdaki her rota komutu ona bağlıdır:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Doğrudan bağlı bir alt ağ, tünel açıkken bile genellikle bağlantı üzeri rotayı korur, bu yüzden girdi var olabilir ve trafik yine de başarısız olabilir. Bu bileşim, yönlendirmeden sonra çalışan bir filtrenin imzasıdır ve ikinci, daha belirgin bir rotanın hiçbir şeyi değiştirmediği durum budur.

Adrese ve ada göre ayrı ayrı test edin. ping 192.168.1.50 yanıt verip net view 192.168.1.50 vermiyorsa yönlendirme tablosu hiçbir zaman sorun değildi: tünel çözümleyiciyi değiştirdi ve yerel ad artık çözümlenmiyor. Bunun için rota eklemek boşa emektir.

Soru iki: ağ geçidi yerel LAN erişimine izin veriyor mu?

Ticari bir istemci rotalardan fazlasını kurar. Bağlanırken bir politika alır ve bu politika açık bir yerel ağ izni içerebilir. Cisco IPsec dağıtımlarında grup politikası split-tunneling ayarını ve yerel LAN erişimi için ayrı bir bayrağı taşır; istemcideki onay kutusu ağ geçidinin reddedebileceği bir istektir. AnyConnect'te profil split'in dahil etme ve hariç tutma listelerini ve aynı izni denetler. Windows RRAS'ta karşılıkları profildeki varsayılan ağ geçidi seçeneği ve sunucunun atadığı statik rotalardır.

Bayrak kapalıyken belgelenen davranış, geçerli ve daha belirgin bir rota olsa bile istemcinin doğrudan bağlı alt ağa giden trafiği engellemesidir. İstemcinin sahip olmadığı rotaların ekledikten saniyeler sonra kaybolabilmesinin nedeni de budur: istemci kendisine söylenen durumu yeniden kuruyor, sizinle savaşmıyor.

İstemci günlüğü bağlantı anındaki kararı kaydeder ve onu okumak makinedeki herhangi bir denemeden hızlıdır. Günlük yerel erişimin engellendiğini söylüyorsa durun: hiçbir komut satırı düzeltmesi bunu atlatamaz ve kalan yollar politika değişikliği, kaynağa tünel üzerinden ulaşmak ya da istemciyi sanal makineye kapatıp ana makineyi yerel ağda bırakmaktır.

Soru üç: hangi yöne ihtiyacınız var?

Yakındaki bir aygıta giden trafik bir yönlendirme sorusudur. LAN önekini yerel ağ geçidine, tünelin varsayılan rotasını yenecek kadar düşük bir metrikle yönlendirin:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

İkinci biçim tek bir aygıtı sabitler ve tek bir adres tüm gereksinim olduğunda istediğiniz budur. netsh eşdeğeri aynı kararı dizin yerine arayüz adıyla kaydeder:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Adres ve maske uyuşmadığında rota komutları Parametre yanlış ile başarısız olur, örneğin /24 maskeli bir ana bilgisayar adresi. Alt ağ rotası için ağ adresini, tek ana bilgisayar için ana bilgisayar maskesini kullanın.

Gelen trafik farklıdır. Aynı makinedeki VNC ya da SSH sunucusu, gelen bağlantıya verilen yanıtlar VPN ağ geçidinden çıkıp geri dönmediğinde ulaşılamaz hale gelir. Rotalara dokunmadan önce hizmetin neyi dinlediğini kontrol edin:

netstat -ano | findstr :5900

Belirli bir adrese bağlı bir dinleyici diğer arayüzde yanıt vermez. Onu tüm arayüzlere bağlamak, güvendiğiniz ağla sınırlı bir güvenlik duvarı kuralıyla birlikte alınan bilinçli bir karardır. Ancak ondan sonra rota onarımı dönüş yolunu geri getirir.

Uyan en küçük değişikliği uygulayın

Diğer yaygın hamle, IPv4 gelişmiş özelliklerinde „Uzak ağda varsayılan ağ geçidini kullan” seçeneğinin işaretini kaldırmaktır. Bu internet trafiğini yerel tutar ama aynı anda iki şey yapar: VPN artık varsayılan yol değildir ve istemci uzak ağ için rotaları, multicast dahil, almayı bırakır. İşareti kaldırın ve sunucu her istemcinin ihtiyaç duyduğu belirli uzak önekleri itmedikçe uzak LAN kaybolur.

Bu asimetri iş sırasını belirler. Uzak taraf tamamen erişilebilir kalmalıysa uzak alt ağları sunucudan itin ve yerel varsayılanı rahat bırakın. Sunucuyu değiştiremiyorsanız, tünelin atadığı adres üzerinden uzak öneke kalıcı bir rota ekleyin ve route print ile önekin VPN arayüzüne, varsayılanın ise hâlâ fiziksel ağ geçidine işaret ettiğini doğrulayın.

Ardından onarımın yeniden bağlanmadan sağ çıktığını doğrulayın, çünkü kalıcı olmayan rotalar bağdaştırıcıyla birlikte ölür ve her bağlantıdan sonra çalışan bir betik onlar için dürüst yerdir. Aynı oturumda bir yerel aygıtı ve bir uzak kaynağı test edin, bağlantıyı kesin, yeniden bağlanın ve tekrar test edin. Rota doğru görünürken yerel aygıt hâlâ başarısız oluyorsa soru ikiye dönün: istemci filtreliyor ve yanıt ikinci bir rakip rota değil, politika değişikliğidir.