Azure P2S VPN xüsusi endpoint adını həll edə bilmir

Point-to-site tunelini qurursunuz, xüsusi ünvana ping edirsiniz, tətbiqi açırsınız və əvəzində 403 və ya sertifikat xətası alırsınız. Hər iki simptom DNS-ə işarə edir, amma bunlar fərqli nasazlıqlardır: biri müştərinin ictimai ünvanı həll etdiyini, digəri xüsusi ünvanı həll edib sertifikatın əhatə etmədiyi adı təqdim etdiyini bildirir. Aşağıdakı yoxlamaları sıra ilə keçin və ilk uğursuzluqda dayanın, çünki hosts qeydi və ya keşlənmiş cavab sonrakı bütün yoxlamaları səhv səbəbdən keçirə bilər. Mən bu sıranı VPN profillərimin yanındakı mətn faylında saxlayıram, çünki düzəliş tuneldə heç nəyi, müştərinin bildiklərində isə hər şeyi dəyişir.

Müştərinin həqiqətən aldığı ünvandan başlayın

Tətbiqə güvənmək əvəzinə resolverdən birbaşa soruşun. Windows-da nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net müştərinin hansı görünüşü aldığını göstərir. İctimai cavab heç nəyin endpointə çatmayacağı anlamına gəlir; endpointin xüsusi ünvanı isə DNS-in bitdiyini və növbəti yoxlamanın bağlantının özü olduğunu bildirir.

Xüsusi endpoint xidməti yenidən adlandırmır. Hesab və ya tətbiq adi tam kvalifikasiyalı adını saxlayır və endpoint yalnız virtual şəbəkə daxilindəki müştərilər üçün həmin adın həll olunduğu ünvanı dəyişir. Buna görə eyni host adı şəbəkədəki VM-dən xüsusi, xüsusi görünüş verilməmiş noutbukdan isə ictimai olaraq həll olunur.

Tuneldən əvvəl zonanı, onun bağlantısını və qeydi yoxlayın

Üç şərt birlikdə yerinə yetməlidir: xüsusi zona mövcuddur, VPN şlüzünün və müştərilərin Azure-a daxil olduğu virtual şəbəkəyə bağlıdır və endpoint üçün xüsusi ünvana işarə edən A qeydi saxlayır. Zonanı əlaqəsiz şəbəkəyə bağlasanız, şlüz ictimai qeydi həll etməyə davam edər, tuneldəki hər şey isə sağlam görünər.

Zona adları xidmətlərə aiddir, ümumilikdə xüsusi linklərə deyil. App Service adətən privatelink.azurewebsites.net istifadə edir, yaddaş və SQL-in öz ad məkanları var, başqa xidmətin zonasını borc almaq isə mövcud olan, amma faydalı heç nə cavablandırmayan zona yaradır.

Müştəriyə həqiqətən çata bildiyi resolver verin

168.63.129.16 Azure virtual maşınlarından cavab verir və point-to-site tunelinin o biri tərəfindəki noutbuk üçün DNS serveri deyil. Müştəriyə tuneldən əlçatan resolver lazımdır: Azure DNS Private Resolver inbound endpointi, virtual şəbəkə daxilində forwarder, ya da VPN müştəri profilində daşınan DNS server qeydləri ki, müştəri birbaşa virtual şəbəkədən soruşsun.

Konfiqurasiya edilmiş, amma əlçatmaz resolver heç resolver olmaması kimi davranır və simptom səhv cavab deyil, timeout olur, buna görə də firewall problemi kimi oxunur. Onu tunelin daşımalı olduğu sorğu ilə yoxlayın, lokal linkdə onsuz da keçəcək ictimai adla deyil.

Ayarları itələmək əvəzinə forward edirsinizsə, xüsusi zonanın sahib olduğu ad məkanını forward edin, bütün azurewebsites.net yerinə privatelink.azurewebsites.net. Bütün valideyn suffiksini udan şərti forwarder xidmət üçün hər axtarışı Azure-a göndərir, o cümlədən lokal qalmalı olanları.

Sertifikatın verildiyi addan istifadə edin

Ünvan düzgün olandan sonra ikinci nasazlıq üzə çıxır. Yaddaş və App Service privatelink ləqəbi yayımlayır və bu ləqəb mütləq sertifikatdakı ad deyil. privatelink.blob.core.windows.net ünvanına göndərilən AzCopy yükləməsi validasiyadan keçmədi; eyni yükləmə <account>.blob.core.windows.net/<container> ünvanına xüsusi ünvana həll olundu və keçdi, yəni override olmadan xüsusi yolda qaldı.

Qayda brauzerdə və App Service üçün də keçərlidir: sertifikatın əhatə etdiyi host adı ilə qoşulun və xüsusi ünvanı DNS versin. Validasiyanın yan keçməsinə əl atmayın, çünki bu, adlandırma səhvini təhlükəsizlik reqressiyasına çevirir. Uğurlu ping marşrutu təsdiqləyir və handshake daxilindəki ad haqqında heç nə demir, buna görə də bunlar ayrı yoxlamalar olaraq qalır.

Hər təbəqəni təcrid edən dörd addımlı sıra

1. VPN müştərisinin point-to-site hovuzundan ünvan aldığını və endpointin xüsusi ünvanına marşrutu olduğunu təsdiqləyin.
2. Tətbiqin istifadə etdiyi dəqiq adı həll edin və cavabı endpointin ünvanı ilə müqayisə edin.
3. Endpointə xidmət portunda TCP bağlantısı açın, sonra həmin bağlantıda təqdim olunan sertifikat adını oxuyun.
4. Yalnız indi avtorizasiyanı yoxlayın, çünki işlək yol və etibarlı sertifikat hələ resursa giriş vermir.

Ünvan düzgün olduğu halda rədd edilən bağlantı DNS-ə deyil, şəbəkə təhlükəsizlik qrupuna və ya xüsusi endpoint bağlantısının vəziyyətinə işarə edir, buna görə resolver ayarlarını yenidən redaktə etməzdən əvvəl onları yoxlayın. TLS ad uyğunsuzluğu sizi URL-dəki host adına və sertifikatın subyektinə qaytarır. Həll çıxışını, sertifikat adını və dəqiq URL-i birlikdə saxlayın; bu üç dəyər bu halların çoxunu şlüzə toxunmadan izah edir.

Nəzarət üçün virtual şəbəkə daxilindəki VM-dən istifadə edin. Ad orada xüsusi, tuneldən isə ictimai həll olunursa, zona və qeyd düzgündür və yeganə fərq müştərinin resolver yoludur ki, bunu təsdiqləmək endpoint konfiqurasiyasına yenidən baxmaqdan sürətlidir.

Müştərilər də keşləyir. On dəqiqə əvvəl ictimai cavab verən qeyd zonanı düzəltdikdən sonra da cavab verməyə davam edir, buna görə yenidən test etməzdən əvvəl keşi təmizləyin. Windows-da ipconfig /flushdns müştəri keşini təmizləyir; ad həlli siyasəti qaydaları isə qalır, hansı suffiksin hansı serverə getdiyini müəyyən edir və ad məkanını təzəcə əvəz etdiyiniz resolverə göndərməyə davam edə bilər.

Hosts qeydi hara aiddir

Endpoint ünvanını hosts faylına əlavə etmək yaxşı diaqnostika və pis dizayndır. O, ad-ünvan uyğunluğunun çatışmayan hissə olduğunu sübut edir və sonrakı hər şeyi test etməyə imkan verir, amma istifadəçiləriniz üçün görünməzdir, endpoint ünvanı dəyişdikdə pozulur və cavab verməli olan zonanı gizlədir.

Qalmış test qeydi köhnə keşdən pisdir, çünki xətanın istiqamətindən asılı olaraq düzəldilmiş yolu pozulmuş, pozulmuş yolu isə düzəldilmiş kimi göstərə bilər. Yekun keçiddən əvvəl onu silin və yalnız istehsal resolveri ilə həll edin.

Qısa adlar axtarış suffiksi tələb edir, tam kvalifikasiyalı adlar isə etmir, buna görə əvvəlcə tam kvalifikasiyalı adı test edin, sonra iş axınının müştəri profili ilə ötürülən suffiksə ehtiyacı olub-olmadığını qərar verin. Microsoft hər xidmət üzrə zona adlarını və qeyd formalarını xüsusi endpoint DNS təlimatında sənədləşdirir; başqa xidmətdən zona kopyalamaq əvəzinə öz xidmətinizin qeydini oxuyun.