Azure Virtual Network daxilində VM-lər və ya xidmətlər arasında əlaqə kəsilir, internetə çıxış alınmır və ya sorğular time-out edir. Məsələn, bir VM digərinə ping atdıqda cavab ala bilmir, RDP/SSH bağlantısı qurulmur, yaxud PaaS xidmətlərinə (məsələn, Azure Storage, Azure SQL) VNet üzərindən qoşulmaq mümkün olmur. Bu hallar adətən şəbəkə filtrəsi, marşrutlama və ya ad həlli problemi olduğunu göstərir.
Mümkün kök səbəblər:
- Şəbəkə Təhlükəsizlik Qrupu (NSG) qaydaları trafiki bloklayır. NSG-lərin inbound/outbound qaydaları VNet daxilində və ya internetlə əlaqəni məhdudlaşdıra bilər. Məsələn, lazımi portu/ünvanı icazə verməyən qayda trafikə mane ola bilər[1][2].
- İstifadəçi Təyinli Marşrut (UDR) xətalıdır. Yanlış konfiqurasiya edilmiş UDR trafiki düzgün ünvana yönləndirmir və ya “qara dəliyə” göndərir. Xüsusən, 0.0.0.0/0 kimi marşrutlar bütün çıxışı NVA-ya yönəldib internetə çıxışı kəsə bilər.
- DNS problemi var. VNet üçün təyin edilmiş DNS serveri səhvdir və ya əlçatmazdır. Nəticədə VM-lər daxili adları və ya xidmətlərin URL-lərini çözə bilmir. Bu hal PaaS xidmətlərinə qoşulma səhvinə səbəb ola bilər (məsələn, “internet connectivity test failed…” xətası yanlış DNS səbəbindən yarana bilər)[3].
- Service Endpoint konfiqurasiyası düzgün aparılmayıb. Xidmət son nöqtəsi aktiv edildikdə, PaaS xidmətinə trafik VNet-in özəl IP-si ilə gedir. Əgər həmin xidmətin firewall-u əvvəlcə yalnız ictimai IP-lərə icazə verirdisə, indi özəl IP-lərdən gələn trafiki bloklaya bilər. Nəticədə bağlantı kəsintisi baş verə bilər[4]. Həmçinin, service endpoint aktiv edilib, lakin qarşı tərəfdə (məs., Storage hesabında) VNet icazəsi verilməyibsə, bağlantı uğursuz olacaq[5].
Diaqnostika üsulları
Azure Network Watcher alətlərindən istifadə edərək problemi araşdırın. Məsələn, IP Flow Verify vasitəsilə konkret VM NIC üzrə verilmiş mənbə/təyinat IP və porta görə trafikin icazəli və ya bloklandığını öyrənmək mümkündür. Bu alət trafikin icazə verilib-verilmədiyini və bloklanıbsa məhz hansı NSG qaydasına görə bloklandığını göstərir[2]. Connection Troubleshoot (Şəbəkə bağlantısının sınağı) isə iki nöqtə arasında paketlərin marşrutunu yoxlayır və yol üzərindəki maneələri (NSG, UDR, NVA və s.) aşkar edir[6]. Bu alətin nəticəsində “ConnectionStatus: Unreachable” və Hops siyahısında “Issue: NetworkSecurityRule” və ya “Issue: UserDefinedRoute” kimi qeydlər problemin NSG və ya UDR-dən qaynaqlandığını təsdiqləyə bilər[7].
NSG Flow Logs və Effective Security Rules kimi vasitələr də faydalıdır. NSG axın jurnalları müəyyən bir NSG-dən keçən trafik barədə məlumat verir – burada gözlənilməz Deny (imtina) qeydləri problemin filtrdən qaynaqlandığını göstərə bilər[8]. Azure Portalında NIC üçün “Effective security rules” bölməsinə baxaraq VM-ə tətbiq olunan birləşik NSG qaydalarını görə bilərsiniz; bu, bir-birini üstələyən qaydaları üzə çıxara bilər.
DNS problemini diaqnostika etmək üçün VM üzərində nslookup/dig ilə lazım olan domen adının həllini yoxlayın. Əgər həll olunmursa, VNet-in DNS sazlamalarını yoxlamaq lazımdır. Azure Portal > Virtual Network > DNS settings bölməsində Azure-provided DNS (Default 168.63.129.16) əvəzinə xüsusi DNS göstərilibsə, həmin DNS serverinin düzgün işlədiyindən və VNet-dən ona birbaşa çıxış olduğundan əmin olun[9]. Məsələn, on-prem DNS serveri təyin olunubsa, VPN bağlantısının aktiv və DNS sorğularını cavablandırdığına əmin olmaq lazımdır.
Service Endpoint üçün diaqnostika: Əvvəl, aidiyyəti PaaS xidmətinin (məsələn, Storage account) Firewall və virtual networks bölməsində VNet-inizin həmin xidmətə icazəli olduğuna əmin olun. Sonra, Network Watcher Next Hop sınağı ilə paketlərin marşrutunu yoxlayın – service endpoint aktiv olduqda, müvafiq xidmət trafikinin növbəti hop-u VirtualNetworkServiceEndpoint olmalıdır. Əgər trafik səhvən internetə yönəlirsə, UDR-ləri yoxlayın. Bəzi hallarda, bütün çıxışı on-prem şlüzünə yönləndirən UDR service endpoint trafikinin də ora getməsinə səbəb olur; bu halda ya UDR-i dəyişmək, ya da Private Link kimi alternativə keçmək gərəkdir[10][11].
Həll yolları:
Problemin kök səbəbindən asılı olaraq müvafiq tədbirlər alınmalıdır:
- NSG qaydalarının tənzimlənməsi: Əvvəlcə NSG-lərdə default icazə qaydalarının (Allow VNet Inbound, Allow AzureLoadBalancer, Allow Internet Outbound və s.) silinmədiyini yoxlayın. Əgər xüsusi qayda zəruri trafikə maneə törədirsə, onu redaktə edin və ya silin[7]. Məsələn, VNet daxilində bütün trafiki bloklayan bir qayda varsa, həmin qaydanı deaktiv edin. Həmçinin, eyni qaydaların həm subnet, həm NIC üzərində tətbiq olunması arzuolunmazdır – üst-üstə düşən qaydalar ziddiyyət yaradıb trafikə gözlənilməz təsir göstərə bilər. Buna görə NSG-ləri ya yalnız subnetə, ya da yalnız NIC-ə tətbiq etmək tövsiyə olunur (hər ikisinə birdən deyil)[12].
- UDR-in düzəlişi: Diaqnostika nəticəsində hansı marşrutun problemi yaratdığı məlumdursa, həmin UDR-i yeniləyin və ya silin[13]. Məsələn, internet çıxışı üçün default yol qeyri-düzgün yönləndirilibsə, onu korrekt şəkildə Internet next hop-u ilə dəyişin. Əgər marşrutu silmək mümkün deyilsə (tələb olunursa), onda NVA üzərində lazımi yönləndirməni qurmaq lazım gələcək ki, trafik təyinat nöqtəsinə çata bilsin[14].
- DNS probleminin həlli: VNet üçün düzgün DNS serverini təyin edin. Əgər xüsusi DNS server istifadə olunursa, onun əlçatan olduğunu yoxlayın (bunun üçün həmin VNet-də test VM-dən nslookup ilə sorğu göndərib cavab almaq olar). DNS serverinin IP ünvanının düzgün məqaləldığına və VNet-lə əlaqəsinə əmin olun[9]. Alternativ olaraq, Azure-un daxili DNS xidmətindən yararlana bilərsiniz (əgər mürəkkəb ad həlli tələbləri yoxdursa). Private DNS zone istifadə edilirsə, həmin zonanın VNet-ə link olunduğunu və lazımi DNS qeydlərinin mövcud olduğunu təsdiqləyin.
- Service Endpoint/Şəxsi son nöqtə konfiqurasiyası: Əgər service endpoint aktiv edilibsə, qarşı tərəfdəki Azure xidmətinin şəbəkə ayarlarında müvafiq VNet-in icazə siyahısına əlavə olunduğunu yoxlayın[5]. Bunun düzgün ardıcıllığı: öncə VNet-də service endpoint-i yandırın, sonra Azure xidmət tərəfində həmin VNet üçün Virtual Network ACL (icazə siyahısı) qurun[15]. Əks halda təkcə endpoint-i açmaq həmin xidmətə çıxış imkanı vermir. Service endpoint aktiv olduqdan sonra, əgər öncə həmin servisdə konkret ictimai IP-lərə icazə var idisə, artıq trafik özəl IP-lərlə gedəcəyindən əlavə olaraq bu özəl diapazonu da icazəyə daxil etmək lazımdır. Məsələn, əvvəlcə VM-in public IP-si icazəli idisə, endpoint sonrası VM trafiki özəl IP ilə gedir və firewall onu tanımayıb rədd edər[16]. Bu problemi həll etmək üçün ya firewall-a VNet-in address space-ni əlavə etmək, ya da Private Endpoint həllinə keçərək birbaşa özəl qoşulma təmin etmək olar[17][18].
Yuxarıdakı düzəlişlər edildikdən sonra, Network Watcher ilə bağlantı testlərini təkrar keçirin. Connection troubleshoot vasitəsilə alınan nəticədə ConnectionStatus: Reachable olarsa və “Issues” siyahısı boşdursa, problem aradan qalxmış sayılır. Həmçinin, tətbiq/VM daxilindən hədəf ünvanlara ping/RDP/HTTP sorğularını sınayın. Artıq sorğular cavab verirsə, bağlantı bərpa olunub deməkdir.