Azure P2S VPN özel uç nokta adını çözemiyor

Noktadan siteye tüneli bağlarsınız, özel adrese ping atarsınız, uygulamayı açarsınız ve bunun yerine 403 ya da sertifika hatası alırsınız. İki belirti de DNS'i işaret eder, ama farklı arızalardır: biri istemcinin genel adresi çözdüğü, diğeri özel adresi çözüp ardından sertifikanın kapsamadığı bir ad sunduğu anlamına gelir. Aşağıdaki denetimleri sırayla yapın ve ilk hatada durun, çünkü bir hosts girdisi ya da önbellekteki yanıt sonraki her denetimi yanlış nedenle geçirebilir. Bu sırayı VPN profillerimin yanındaki bir metin dosyasında tutuyorum, çünkü düzeltme tünelde hiçbir şeyi, istemcinin bildiklerinde ise her şeyi değiştirir.

İstemcinin gerçekten aldığı adresle başlayın

Uygulamaya güvenmek yerine çözümleyiciye doğrudan sorun. Windows'ta nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net istemcinin hangi görünümü aldığını gösterir. Genel bir yanıt, aşağıda hiçbir şeyin uç noktaya ulaşmayacağı anlamına gelir; uç noktanın özel adresi ise DNS'in bittiği ve sıradaki denetimin bağlantının kendisi olduğu anlamına gelir.

Özel uç nokta hizmeti yeniden adlandırmaz. Hesap ya da uygulama olağan tam nitelikli adını korur ve uç nokta yalnızca sanal ağ içindeki istemciler için bu adın çözüldüğü adresi değiştirir. Bu yüzden aynı ana bilgisayar adı ağdaki bir VM'den özel, özel görünüm hiç verilmemiş bir dizüstü bilgisayardan ise genel olarak çözülür.

Tünelden önce bölgeyi, bağlantısını ve kaydı denetleyin

Üç koşul birlikte geçerli olmalıdır: özel bölge vardır, VPN ağ geçidinin ve istemcilerin Azure'a girdiği sanal ağa bağlıdır ve uç nokta için özel adresi gösteren bir A kaydı içerir. Bölgeyi ilgisiz bir ağa bağlarsanız ağ geçidi genel kaydı çözmeye devam eder, tüneldeki her şey sağlıklı görünür.

Bölge adları hizmetlere aittir, genel olarak özel bağlantılara değil. App Service genellikle privatelink.azurewebsites.net kullanır, depolama ve SQL'in kendi ad alanları vardır ve başka bir hizmetin bölgesini ödünç almak, var olan ama yararlı hiçbir şey yanıtlamayan bir bölge üretir.

İstemciye gerçekten erişebildiği bir çözümleyici verin

168.63.129.16 Azure sanal makinelerinden yanıt verir ve noktadan siteye tünelin karşı tarafındaki bir dizüstü bilgisayar için DNS sunucusu değildir. İstemcinin tünel üzerinden erişilebilen bir çözümleyiciye ihtiyacı vardır: Azure DNS Private Resolver'ın gelen uç noktası, sanal ağ içinde bir yönlendirici ya da istemcinin sanal ağa doğrudan sorması için VPN istemci profilinde taşınan DNS sunucusu girdileri.

Yapılandırılmış ama erişilemez bir çözümleyici tam olarak hiç çözümleyici yokmuş gibi davranır ve belirti yanlış yanıt değil zaman aşımıdır, bu yüzden güvenlik duvarı sorunu olarak yanlış okunur. Tünelin taşıması gereken bir sorguyla test edin, yerel bağlantı üzerinden nasılsa başarılı olacak genel bir adla değil.

Ayarları itmek yerine yönlendiriyorsanız, özel bölgenin sahip olduğu ad alanını yönlendirin, tüm azurewebsites.net yerine privatelink.azurewebsites.net. Ana üst soneki yutan koşullu yönlendirici, yerel kalması gerekenler de dahil olmak üzere hizmetin her aramasını Azure'a gönderir.

Sertifikanın düzenlendiği adı kullanın

Adres doğru olduğunda ikinci arıza ortaya çıkar. Depolama ve App Service privatelink takma adını yayımlar ve bu takma ad sertifikadaki ad olmak zorunda değildir. privatelink.blob.core.windows.net adresine gönderilen bir AzCopy yüklemesi doğrulamayı geçemedi; aynı yükleme <account>.blob.core.windows.net/<container> adresine özel adrese çözüldü ve geçti, böylece herhangi bir atlatma olmadan özel yolda kaldı.

Kural tarayıcıda ve App Service için de geçerlidir: sertifikanın kapsadığı ana bilgisayar adıyla bağlanın ve özel adresi DNS sağlasın. Doğrulamayı atlatmaya yönelmeyin, çünkü bu bir adlandırma hatasını güvenlik gerilemesine dönüştürür. Başarılı bir ping yolu kanıtlar ve el sıkışmanın içindeki ad hakkında hiçbir şey söylemez, bu yüzden bunlar ayrı denetimler olarak kalır.

Her katmanı yalıtan dört adımlı bir sıra

1. VPN istemcisinin noktadan siteye havuzundan bir adres ve uç noktanın özel adresine bir yol taşıdığını doğrulayın.
2. Uygulamanın kullandığı tam adı çözün ve yanıtı uç noktanın adresiyle karşılaştırın.
3. Hizmet bağlantı noktasında uç noktaya bir TCP bağlantısı açın, ardından o bağlantıda sunulan sertifika adını okuyun.
4. Yetkilendirmeyi ancak şimdi test edin, çünkü çalışan bir yol ve geçerli bir sertifika hâlâ kaynağa erişim vermez.

Adres doğruyken reddedilen bir bağlantı DNS'e değil ağ güvenlik grubuna ya da özel uç nokta bağlantısının durumuna işaret eder, bu yüzden çözümleyici ayarlarını yeniden düzenlemeden önce bunları denetleyin. TLS adı uyuşmazlığı sizi URL'deki ana bilgisayar adına ve sertifikanın subject alanına geri gönderir. Çözümleme çıktısını, sertifika adını ve tam URL'yi bir arada tutun; bu üç değer ağ geçidine dokunmadan bu durumların çoğunu açıklar.

Kontrol olarak sanal ağ içindeki bir VM kullanın. Ad orada özel, tünelden ise genel olarak çözülüyorsa bölge ve kayıt doğrudur ve tek fark istemcinin çözümleyici yoludur, bu da uç nokta yapılandırmasına bir tur daha atmaktan daha hızlı doğrulanır.

İstemciler de önbelleğe alır. On dakika önce genel yanıt veren bir kayıt, bölgeyi düzelttikten sonra da yanıtlamayı sürdürür, bu yüzden yeniden test etmeden önce önbelleği boşaltın. Windows'ta ipconfig /flushdns istemci önbelleğini temizler; ad çözümleme ilkesi kuralları kalır, hangi sonekin hangi sunucuya gideceğini belirler ve ad alanını az önce değiştirdiğiniz çözümleyiciye göndermeye devam edebilir.

hosts girdisi nereye ait

Uç noktanın adresini bir hosts dosyasına eklemek iyi bir tanı ve kötü bir tasarımdır. Ad-adres eşlemesinin eksik parça olduğunu kanıtlar ve o adımdan sonra her şeyi test etmenizi sağlar, ama kullanıcılarınız için görünmezdir, uç noktanın adresi değiştiğinde bozulur ve yanıtlaması gereken bölgeyi gizler.

Kalan bir test girdisi eski bir önbellekten daha kötüdür, çünkü hatanın yönüne göre onarılmış yolu bozuk ya da bozuk yolu onarılmış gibi gösterebilir. Son turdan önce kaldırın ve yalnızca üretim çözümleyicisiyle çözün.

Kısa adlar arama sonekine ihtiyaç duyar, tam nitelikli adlar duymaz, bu yüzden önce tam nitelikli adı test edin, sonra iş akışının istemci profiliyle itilen bir soneke ihtiyacı olup olmadığına karar verin. Microsoft, hizmet bazında bölge adlarını ve kayıt biçimlerini özel uç noktalar için DNS yönergelerinde belgeler; başka bir hizmetten bölge kopyalamak yerine kendi hizmetinizin girdisini okuyun.