Azure P2S: bir Windows istemcisi VNet değişikliğinden sonra rotalarını kaybetti

İki dizüstü bilgisayar aynı Azure point-to-site ağ geçidinde kimlik doğrular ve yalnızca biri yeni bağlanan VNet'e ulaşır. İkisi de Connected gösterir, yani kimlik doğrulama fark değildir; fark tuttukları hedef rotalardır. Başarısız olan istemciden başlayın, tek bir hedefi karşılaştırın ve ancak ondan sonra boşluğun ağ geçidi paketine mi yoksa yerel yönlendirme tablosuna mı ait olduğuna karar verin.

Ağ geçidinden değil, başarısız olan istemciden başlayın

Dizüstü bilgisayarı suçlamadan önce topolojiyi doğrulayın. Hangi VNet'lerin ağ geçidi VNet'ine bağlı olduğunu ve yeni ağın doğrudan mı eşlendiğini yoksa ayrı bir site-to-site tüneliyle mi erişildiğini kontrol edin. Yeni VNet ağ geçidi VNet'ine hiç bağlı değilse, hiçbir istemci paketi oraya yönlendirme yapamaz ve çalışan dizüstü bilgisayar açıklanması gereken anormalliktir. Yanıtı yazın, çünkü bir istemciyi mi yoksa ağ geçidini mi hata ayıkladığınızı o belirler.

Topoloji doğruysa iki dizüstü bilgisayarı yan yana koyun. Aynı ağ geçidi, aynı adres havuzu, aynı protokol ve aynı istemci yapısı istediğiniz karşılaştırmadır; geri kalan her şey daha sonra ortadan kaldırmanız gereken ikinci bir değişkendir.

route print ile tek bir hedefi karşılaştırın

İzin verilen bir kaynak IP'si seçin ve iki dizüstü bilgisayarı iki kez karşılaştırın: bağlantı kesilmişken, sonra bağlıyken. Windows'ta route print -4 IPv4 rotalarını hedef öneki, arabirim, sonraki atlama ve metrikle listeler. VPN sözcüğünü içeren girdileri saymak yerine o hedef için gerçekten kazanacak satırı kaydedin.

Seçim önce en uzun önek, sonra metrik ile yapılır, bu yüzden daha belirgin bir yerel rota yanlış görünmeden tünel rotasını yenebilir. Hedeflenen hedef 10.24.0.0/16 içindeyse, sağlıklı bir istemci VPN arabiriminde eşleşen bir rota gösterirken başarısız istemci aynı adresi varsayılan ağ geçidine gönderir.

Çakışan bir yerel önek aynı belirtiyi üretebilir. Herhangi bir şey eklemeden önce iki durumdan hangisine sahip olduğunuza karar verin: hiç tünel rotası yok, ya da daha belirgin bir rotaya yenilen tünel rotası var.

TTL expired bir rota dağıtım hatası değildir

TTL expired in transit döndüren bir ping, paketin atlama kotasını tükettiğini söyler; bu genellikle bozuk bir VPN sürücüsü değil, bir yönlendirme döngüsü anlamına gelir. Windows ping'i 255'e kadar TTL kabul eder ve değeri yükseltmek döngüyü onarmaz; yalnızca aynı hatayı geciktirir. Mesajı yolun belirtisi olarak ele alın, rota dağıtımına ilişkin kanıt olarak değil.

Yolun nerede tekrarlandığını görmek için tracert -4 10.24.1.10 kullanın. Aynı iki atlama tekrar tekrar görünüyorsa, tünele giden trafiği tekrar tünele veya geri gönderen yerel bir yönlendiriciye yollayan bir rota arayın.

Paketi sahibi olan ağ geçidinde yeniden oluşturun

Microsoft, Windows istemci paketlerinin ilgili topoloji değişikliklerinden sonra yeniden indirilmesi ve kurulması gerektiğini belgeler. Bu profili sunan Azure ağ geçidinden geçerli paketi alın ve ardından o istemci için desteklenen süreçle uygulayın. İlgisiz bir VPN uygulamasının çalıştırılabilir dosyasını değiştirmek, ağ geçidine özgü ayarları yeniden oluşturmakla aynı işlem değildir. Paketi yeniden indirmek ucuzdur; yerel rotaları tahmin etmek değildir.

Yeniden bağlanın ve özgün hedefin rotasını yeniden okuyun. Değişiklik kaydıyla birlikte önceki ve sonraki satırları saklayın, böylece sonuç istemciyi yeniden kurdum ifadesinden daha kesin olur.

Azure P2S yönlendirme senaryoları doğrudan eşlenen VNet'leri diğer tünellerle erişilen ağlardan ayırır ve yeni bir paket eşlemeyi geçişli hale getiremez. Bazı Windows site-to-site veya BGP senaryoları elle yapılandırılmış uzak rotalar da gerektirir, bu nedenle paket yenileme evrensel bir rota dağıtım mekanizması değildir.

Geçici bir rotayı geçici tutun

Elle bir rota eksik istemci rotasını yalıtabilir, ancak onu gerçek tasarımdan kurun: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, kalıcı bayrak olmadan, böylece yeniden başlatmada kaybolsun. Arabirim dizinini ve sonraki atlamayı bağlı VPN bağdaştırıcısından seçin, tahminden değil.

Deneysel bir rotayı kalıcı rakip sahip olarak bırakmayın. Gelecekteki profil güncellemeleri aynı öneki farklı bir metrikle ekleyebilir ve o zaman elle girilen kayıt hangi yolun kazanacağına sessizce karar verir. Kaldırma adımını değişikliğe kaydedin.

Doğru rota etkinleştikten sonra ping yerine hedef uygulamayı test edin. Paketler Azure'a ulaşıyor ama hizmet hâlâ başarısız oluyorsa, ağ güvenlik grubunu ve dönüş yolunu kontrol edin, çünkü bunlar dizüstü bilgisayarın öneki öğrenip öğrenmediğinden bağımsızdır.