Bölünmüş tüneliniz uygulamaya ulaşır ama DNS sunucusuna ulaşmaz
Bölünmüş bir tünel uygulamanın alt ağını yönlendirip yanındaki çözümleyiciyi yine de düşürebilir. Ana bilgisayar yolunu ekleyin, ardından Windows'un gerçekte hangi sunucuyu seçtiğini kontrol edin.
Uygulamanın alt ağını yönlendirmek bölünmüş tünelin bariz kısmıdır ve işin tamamı değildir. Çözümleyici çoğu zaman hizmet ettiği uygulamadan farklı bir adreste oturur, bu yüzden çalışan bir tünel aramayı yine de dışarıda bırakabilir. Yalnızca 10.80.0.0/16 taşıyan bir profil, 10.90.0.53 için sorguyu yerel arabirimden dışarı gönderir; orada özel bir bölge yoktur. Çözümleyicinin yolunu ekleyin, ardından sorunun ikinci yarısına bakın: istemcinin gerçekte hangi sunucuyu seçtiğine.
Efsane: tek bir yol tüm hizmeti kapsar
Bölünmüş tünel, bağlantıdan geçen hedeflerin listesidir; bir hizmetin tanımı değildir. Uygulamanın alt ağı ile çözümleyicinin adresi iki hedeftir ve bir profil birini diğeri olmadan taşıyabilir. Bu olduğunda uygulamaya adresle ulaşılır ama adı çözülemez; bu, yönlendirme boşluğundan çok DNS arızası gibi görünür.
Çözümleyicinin çevresindeki alt ağ da otomatik olarak kapsanmaz. Tek bir adrese ana bilgisayar yolu o çözümleyici için yeterlidir ve komşularını açmaz. Ana bilgisayar yolunun anlamı budur: tasarımı gereği dar ve sonraki hizmet aynı alt ağda göründüğünde unutulması kolay.
Aramanın çalışması için üç şey doğru olmalıdır: istemci çözümleyicinin adresini tünelden yönlendirir, ağ geçidi bu isteği kabul edip iletir ve çözümleyici aldığı kaynağı kabul eder. Yanıt da anlaşılan yoldan geri gelmelidir. Bunlardan biri eksikse belirti aynıdır, bu yüzden bir yapılandırmaya dokunmadan önce adres tablosunu yazmakta yarar var.
Profilin hangi adresleri taşıması gerektiğini belirleyin
Hedefleri sırayla listeleyin: uygulamanın ağı, çözümleyicinin adresi ve tünelin kendisini sonlandıran genel uç nokta. Üçüncüsü asla tünele yönlendirilmemelidir, çünkü dış bağlantı tünelden önce var olan bir yola ihtiyaç duyar.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS için hem UDP hem de TCP ekleyin, çünkü uygulamalardan UDP'nin yanında TCP desteği beklenir ve engellenen TCP yolu temiz değil yavaş, kısmi arızalar üretir. Özel bölge IPv6 üzerinden de sunuluyorsa, eşdeğer ana bilgisayar istisnası bir IPv6 adresi ve öneki kullanır ve ayrı bir girdidir.
Bir şey eklemeden önce profilin hâlihazırda neyi kapsadığını yazın. Yinelenen yol zararsızdır, ancak beklenmedik mevcut bir yol, profilin size verilenden farklı bir adres planı için tasarlandığını söyler.
Ana bilgisayar yolunu bağlantının sahibi üzerinden ekleyin
Yerel olarak yönetilen yerel bir Windows profili için yol, makinenin genel yönlendirme tablosuna değil bağlantıya aittir. Önce eklemeyi önizleyin, sonra profilin kullandığı aynı kapsamla uygulayın.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
İlk komut hiçbir şey yüklemeden değişikliği önizler, ikincisi profilin şu anda taşıdığı yolları listeler. Microsoft'un Add-VpnConnectionRoute başvurusu kullanıcı başına ve tüm kullanıcılar için kapsamları belgeler; tüm kullanıcılar profili kendi kapsam parametresine ihtiyaç duyar ve tüm kullanıcılar profiline karşı kullanıcı başına komut başarısız olur veya yanlış yere düşer.
Profil yönetiliyorsa veya bir satıcı istemcisinden geliyorsa, değişiklik o sahibine aittir. Kalıcı bir sistem yolunu bağlantı ilkesinin üzerine yığmak, ilke yeniden uygulanana ve yol kaybolana kadar çalışır; bu genellikle test sırasında değil, bir destek görüşmesi sırasında olur. Bu arıza sessizdir: yol kaybolur, ad çözülmeyi bırakır ve kimse iki olayı birbirine bağlamaz. Değişikliği sahibin kendi kaydına koyun ki bir sonraki yeniden uygulama onu silmek yerine taşısın.
Uyguladıktan sonra yolun yürürlüğe girdiğini varsaymak yerine profili yeniden bağlayın. Canlı bir bağlantıdaki yol değişiklikleri her zaman alınmaz ve yeniden bağlanma, kullanıcılarınızın gerçekte sahip olacağı durumu da yeniden üretir.
İstemcinin gerçekte hangi çözümleyiciyi kullandığını kontrol edin
Bir yol, çözümleyiciye adreslenen paketleri denetler. Hangi adların oraya gönderilmesi gerektiğine karar vermez ve bu seçim ayrı bir mekanizmadır. Windows'ta etkin ad alanı kuralları her etki alanı için bir çözümleyici seçebilirken profilin DNS ayarları bir varsayılan sağlar. Bu iki katman herhangi bir hata üretmeden çelişebilir, bu yüzden doğrudan sorgu kanıtın yalnızca yarısıdır.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
İlk komut yürürlükteki ad alanı ilkesini yazdırır, ikincisi özel çözümleyiciye doğrudan uygulamanın adını sorar. Doğrudan yanıt yolun ve çözümleyicinin çalıştığını kanıtlar; uygulamanın kendi aramasının o sunucuyu seçtiğini kanıtlamaz. Bunu aynı adın normal aramasıyla ve uygulamanın aldığı yanıtla karşılaştırın.
Önbellekleri ve tarayıcı düzeyindeki güvenli DNS'i hesaba katın; bu, kullanıcının yazdığı adlar için sistem çözümleyicisini tamamen atlayabilir. Arama soneki bir başka yanıltıcı izdir: kısa bir adı tam nitelikli bir ada genişletir ve hangi sunucunun yanıtladığıyla hiçbir ilgisi yoktur.
Yeniden bağlanarak ve normal aramayı yineleyerek bitirin, ardından olağan taramanın hâlâ onaylanmış ilkesini izlediğini doğrulayın. Özel çözümleyiciyi, ilgisiz bir ad çözülsün diye genel bir çözümleyiciyle değiştirmek bir düzeltme değildir ve özel sorguları hiç gitmemeleri gereken yere sessizce taşır.