Azure P2S VPN-də cavab trafiki yalnız bir istiqamətdə işləyir

Tunel nişanı yaşıldır, NSG icazəli görünür, effektiv marşrutlar düzgün görünür, lakin VM hələ də qoşulmuş müştəriyə geri bağlantı aça bilmir. Adi fərziyyə belədir: işləyən point-to-site tuneli simmetrikdir — müştəri VM-ə çatırsa, VM də müştəriyə çatır. Bu fərziyyə konfiqurasiyada deyil, düşüncə tərzindəki xətadır. Tunel tələb olunmamış axının bir istiqamətini daşıya, digərini isə ata bilər və düzəliş onu hansı qatın atdığından asılıdır.

Mif: qoşulmuş tunel ikitərəfli tuneldir

VPN tuneli məftil deyil, siyasət yoludur. Hər istiqamət seçicilərə, marşrutlara və filtrlərə uyğun yoxlanılır və onlardan hər hansı biri bir istiqamətə icazə verib digərini bloklaya bilər.

Praktikada asimmetriya o qədər geniş yayılıb ki, istiqamət son yoxlamada deyil, ilk yoxlamada olmalıdır. Müştəri başladır, şlüz axını izləyir və cavab yaradılmış vəziyyətə uyğun gəlir. Yeni axın başladan VM-də belə vəziyyət yoxdur, ona görə də geri yolun açıq şəkildə marşrutlaşdırıla bilən və icazəli olmasından asılıdır. Bu yol olmadıqda, bağlantı cəhdi heç bir tətbiq onu görməmişdən əvvəl ölür.

Əlçatanlığı yoxlamadan əvvəl istiqaməti yoxlayın

Bir müştəri ünvanı, bir VM ünvanı və bir protokol seçin. Müştəridən qoşulun və nəticəni qeyd edin; sonra eyni testi VM-dən başladın və onu da qeyd edin. Birincisi uğurlu, ikincisi uğursuz olarsa, müştəri hovuzu, şlüz assosiasiyası və müştəri-VNet yolu işləyir.

Növbəti addım daha çox qayda deyil, sübutdur. VM alt şəbəkəsindəki NSG-ni hər iki istiqamətdə yoxlayın, VM NIC-də effektiv marşrutları oxuyun və müştəri trafik göndərərkən VM-də paketləri tutun. Cavabsız gələn sorğu filtr və ya geri marşrut problemidir; heç gəlməyən sorğu yol problemidir. Uğursuz ping-i VM-in əlçatmaz olduğuna sübut kimi qəbul etməyin, çünki ICMP siyasəti TCP işləyərkən cavabı ata bilər.

IKEv2 point-to-site geri yolu adi şübhəlidir

Bu məqalənin arxasındakı Azure hesabatında müştəri VM-lərə IKEv2 ilə çata bilirdi, lakin VM-dən müştəriyə gələn ICMP, şlüzün tunel növü OpenVPN-ə keçirilməyənə qədər uğursuz oldu. Hesabat müəllifi bildirir ki, Microsoft IKEv2 point-to-site yolunda məhdudiyyəti təsdiqləyib: VM-dən müştəriyə cavab trafiki, sessiyanı müştəri başlatmayıbsa, simmetrik şəkildə marşrutlaşdırılmır. IKEv2 trafik seçicilərinə əsaslanır və şlüz həmin halda geri istiqaməti nəzərə almadı.

Bu, OpenVPN-i ümumiyyətlə daha yaxşı tunel növü etmir. Bu, tunel növünü bu iş yükü üçün test matrisində dəyişən edir.

Tunel növlərini dəyişmək keçid deyil, xidmət dəyişikliyidir. Hər müştəriyə uyğun profil lazımdır və şlüzə fərqli sertifikat və ya autentifikasiya quruluşu lazım ola bilər. Birtərəfli davranışı bir test müştərisi və bir test VM ilə təkrarlayın, növü təsdiqlənmiş cədvəl üzrə dəyişin və sonra eyni istiqamət testlərini təkrarlayın. Davranış keçiddən sonra da qalırsa, tunel növü səbəb deyildi və istehsala toxunmadan problemi daraltmısınız.

Mif: yayım kəşfi VNet sərhədini keçir

İkinci fərziyyə əlaqəsiz səbəbdən uğursuz olur. Azure virtual şəbəkəsi yayım trafikini daşımır, ona görə də VM site-to-site və ya point-to-site bağlantısı üzərindən yerli şəbəkədən yayım kadrları ala bilməz. Həmyaşıdlarını yayımla tapan tətbiqlər, məsələn köhnə fayl baxışı və ya bəzi cihaz kəşf protokolları, marşrutlar necə yazılmasından asılı olmayaraq uzaq tərəfi heç vaxt görməyəcək.

Yayım kəşfini DNS adları, kataloq xidməti və ya açıq həmyaşıd siyahısı ilə əvəz edin. Tətbiqin unicast alternativi yoxdursa, dizayna daha geniş tunel deyil, fərqli kəşf mexanizmi lazımdır.

Nəyi dəyişmək və bunu necə sübut etmək

İstiqamət testi yalnız IKEv2-də uğursuz olursa, şlüzün tunel növünü, müştəri ünvan hovuzunu və dəqiq ICMP və ya TCP testini qeyd edin, sonra təsirlənmiş müştərilər üçün təsdiqlənmiş OpenVPN profilini qiymətləndirin. Hər tunel növündə uğursuz olursa, geri yol üzərində işləyin: müştəri ünvanı VM alt şəbəkəsindən marşrutlaşdırıla bilməlidir, istifadəçi tərəfindən müəyyən edilmiş hər hansı marşrut etibarlı növbəti hopa işarə etməlidir və müştəri firewall-u daxil olan axını qəbul etməlidir. NSG və marşrut sübutlarını bilete əlavə edin.

Tətbiqlə yoxlayın, ping ilə deyil. Dəyişiklikdən sonra uğurlu ICMP mübadiləsi xidmət portu, onun autentifikasiyası və ya ad həlli haqqında heç nə demir. Yenidən qoşulduqdan sonra testi təkrarlayın, çünki hovuzdan fərqli ünvan alan müştəri nəticəni dəyişə bilər. Sonra müştəri yatıb oyandıqdan sonra bir daha təkrarlayın, çünki davam etdirilən sessiya birtərəfli davranışın tez-tez yenidən göründüyü yerdir.