Azure nöqtədən sayta qoşulur, lakin heç bir şəxsi resurs cavab vermir

Qoşulma tunelin vəziyyətidir, əlçatanlıq barədə ifadə deyil. Nöqtədən sayta müştəri IKE-ni tamamlaya, ünvan ala və yenə də heç nəyə çata bilməz, çünki şlüz yalnız VNet-in artıq bildiyi şəbəkələr üçün trafiki yönləndirir. Bu beş yoxlamanı sıra ilə aparın və ilk uğursuzluqda dayanın. İrəli atlamaq DNS probleminin bir saat firewall problemi kimi qəbul edilməsinin yoludur.

Sıra siyahıdan daha vacibdir.

Yoxlama 1: tunelin nə daşımalı olduğunu müəyyənləşdirin

Azure VPN Gateway tuneli dayandırır və VNet-ə aid trafiki yönləndirir; o,ümumi internet çıxışı deyil. İstifadəçilər brauzerlərinin Azure vasitəsilə çıxmasını gözləyirlərsə, hər hansı müştəri ayarı ortaya çıxmadan dizayn səhvdir. Bölünmüş tuneli (split tunneling) aktivləşdirin ki, yerli internet yerli yoldan istifadə etsin və sabit çıxış ünvanı həqiqətən tələb olunduqda NAT instansiyası və ya saytdan sayta tunel istifadə edin.

Nəyi sınaqdan keçirməzdən əvvəl müştərinin nəyə çatmalı olduğunu yazın. Bu siyahı olmadan hər qismən nəticə tərəqqi kimi görünür.

Yoxlama 2: sertifikatlardan əvvəl ünvan məkanlarını müqayisə edin

Üst-üstə düşmə daha geniş diapazonlara görə qiymətləndirilir, ona görə subnet səviyyəsində fərqli görünən iki şəbəkə, valideyn blokları üst-üstə düşərsə yenə toqquşur. Şlüz subneti ayrılmış və SKU üçün kifayət qədər böyük olmalıdır, müştəri ünvan hovuzu isə VNet ilə və ya peering vasitəsilə əlçatan olan hər şeylə toqquşmamalıdır. Planı dəyişin və yenidən yerləşdirin, çünki kompensasiya üçün marşrut əlavə etmək bəzi təyinatlar üçün işləyən, digərləri üçün isə izahsız işləməyən tunel yaradır. Təchizat burada uca səslə uğursuz olur və bu yaxşı haldır.

Doğrulama növbəti qapıdır. Sertifikat, RADIUS və Entra ID profilləri bir-birini əvəz etmir və müştəri paketi hər biri üçün fərqlidir.

Yoxlama 3: şəxsi adı içəridən həll edin

Müştəri, endirilən profil VNet DNS serverlərini daşımadıqca öz həlledicisini saxlayır və həmin siyahı endirmə vaxtı daxil edilir. VNet daxilində forwarder əlavə edin, onu VNet DNS serveri kimi qeyd edin, sonra müştəri paketini yenidən endirin və idxal edin. Köhnə paketin təkrar istifadəsi yalnız köhnə həlledici siyahısını sınaqdan keçirir.

Əvvəlcə ünvanı sınayın, çünki bu, marşrutlaşdırmanı adlandırmadan bir addımda ayırır: Test-NetConnection 10.20.1.4 -Port 3389.

Ünvan cavab verirsə, ad vermirsə, həlledicidən birbaşa soruşun: Resolve-DnsName files.corp.example -Server 10.20.0.4. Əgər hər ikisi uğursuz olarsa, problem DNS deyil və DNS ayarlarını redaktə etməyi dayandırmalısınız. 168.63.129.16 ünvanındakı Azure platforma DNS-i yalnız VNet daxilindən cavab verir, ona görə ondan kənarda olan müştəri bu ünvanı həlledici kimi istifadə edə bilməz.

Yoxlama 4: tunelin arxasındakı xidməti sınayın

Sağlam tunel və bağlı port müştəri tərəfindən eyni görünür. Qonaq firewall-u, sonra subnet və ya NIC üzərindəki şəbəkə təhlükəsizlik qrupunu, sonra xidmətin yalnız loopback-da deyil, şəxsi ünvanda dinlədiyini yoxlayın. İnternetə qayda açmaq əvəzinə müştəri hovuzuna mənbə kimi icazə verin və unutmayın ki, Azure Files-a SMB üçün şəxsi endpoint yolu tuneldən keçməlidir. Resurs IP ilə cavab verib adla vermirsə, şlüza toxunmaq əvəzinə yoxlama 3-ə qayıdın.

İşləyərkən qatları bir cədvəl ayırır:

Yoxlama 5: eskalasiyadan əvvəl profili qeyd edin

Tiketə şlüz növünü, tunel növünü, doğrulama metodunu və müştəri əməliyyat sistemini yazın. Sertifikatlı IKEv2 profili və RADIUS profili fərqli səbəblərdən uğursuz olur və başqa tunel növü üçün qurulmuş müştəri yalnız şlüz uyğun protokol təklif etdikdə qoşulur.

Kiçik komanda üçün davamlı dizayn bir VNet, bir DNS forwarder və sənədləşdirilmiş split-tunnel müştəridir. Tələb sabit ictimai çıxışdırsa, nəzarət etdiyiniz firewall üzərində saytdan sayta tunel qurun və internet trafikini ora yönləndirin, nöqtədən sayta şlüzundan heç vaxt üçün qurulmadığı bir işi tələb etmək əvəzinə.