Azure UDR-dən VPN şlüzünə: bütün çıxış deyil, bir təyinat

Bir xarici prefiks üçün istifadəçi tərəfindən təyin edilən marşrut əlavə edir, onu VPN şlüzünə yönəldirsiniz və trafik yenə də Azure-un internet yolundan çıxır. Ya da düzgün çıxır və cavab heç vaxt qayıtmır. Hər iki nəticə eyni səhvdən doğur: Azure növbəti atlamasını bütün dizayn kimi qəbul etmək. Marşrut cədvəli yalnız paketin Azure daxilində hansı çıxışı götürəcəyini müəyyən edir. Tuneldən sonra onunla nə baş verdiyi və cavabın necə qayıtdığı qurmalı olduğunuz ikinci yarıdır.

Növbəti atlama şlüzdür, cihazın IP-si deyil

UDR uyğun prefiksi növbəti atlama tipinə göndərir və VirtualNetworkGateway ünvan deyil, tipdir. İnsanlar şlüzün özəl IP-sini VirtualAppliance marşrutuna yapışdırır və sonra heç nəyin uyğun gəlmədiyinə təəccüblənirlər, çünki bu tip əvəzində NIC və ya daxili yük balanslaşdırıcısı gözləyir. Microsoft-un marşrutlaşdırma sənədləri də şlüz növbəti atlamasını yalnız şlüzü VPN şlüzü olan virtual şəbəkə ilə məhdudlaşdırır. ExpressRoute, Route Server və Virtual WAN mərkəzi bu seçimlə ünvanlanmır.

Marşrutu yazmadan əvvəl virtual şəbəkənin həqiqətən nəyə sahib olduğunu yoxlayın. Dizayn mərkəz vasitəsilə marşrutlaşırsa, marşrut redaktə etdiyiniz spoka deyil, mərkəzin marşrutlaşdırma sahibinə aiddir.

Hər hansı dəyişiklik etməzdən əvvəl effektiv marşrutu oxuyun

Azure sistem marşrutlarını, BGP ilə öyrənilmiş prefiksləri və UDR-ləri hər NIC üçün effektiv marşrut cədvəlində birləşdirir və ən uzun uyğun prefiks haradan gəldiyindən asılı olmayaraq qalib gəlir. Eyni prefiks üçün UDR BGP marşrutunu üstələyir. Bu sıra əvvəlki təcrübədən qalan köhnə UDR-in tuneldən yenicə öyrəndiyiniz prefiksi səssizcə üstələyə bilməsinin səbəbidir.

Əvvəlcə effektiv cədvələ baxın, sonra marşrut əlavə etdiyinizi yoxsa birini əvəz etdiyinizi qərarlaşdırın:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Prefikslə yanaşı mənbə sütununu da oxuyun. Düzgün prefiksli və yanlış mənbəli marşrut hansı obyekti redaktə etməli olduğunuzu deyir və birinciyə uduzan ikinci marşrut əlavə etməyinizin qarşısını alır.

Marşrutu real prefiks və alt şəbəkəyə görə yazın

Forum yazısından köçürülmüş publik diapazon əvəzinə, həqiqətən çatdığınız xidmətdən götürülmüş həqiqi təyinat prefiksini istifadə edin. Bütün çıxışı köçürən defolt marşrutu düşünməzdən əvvəl bir təsdiqlənmiş xidmətlə başlayın. Sonra marşrut cədvəlini yük alt şəbəkəsinə bağlayın. Şlüz alt şəbəkəsinin öz tələbləri var və cədvəlinizi oraya bağlamaq yükü yönləndirmək əvəzinə şlüzü sındırır.

Marşrutu yaradın, sonra cədvəli yükü yerləşdirən alt şəbəkəyə bağlayın:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Yayılma da vacibdir. Həmin cədvəldə BGP yayılması aktiv olduqda, öyrənilmiş prefikslər yazdıqlarınızın yanında görünür və daha dəqiq öyrənilmiş prefiks daha geniş UDR-i üstələyə bilər. Yayılmanı yalnız UDR dəstinin həmin alt şəbəkə üçün səlahiyyətli olmasını istədikdə söndürün.

Şəbəkə daxili yarısını tamamlayın, əks halda axın orada ölür

Şəbəkə daxili şlüz Azure mənbəyini qəbul etməli, onu təyinata yönəltməli və tətbiqə icazə verməlidir. Onun sonrakı yolu internet çıxışı və ya başqa özəl atlama ola bilər, lakin bu qərar Azure marşrut cədvəlinə deyil, plana aiddir. Adi uğursuzluq cavab yoludur. İnternet təyinatı özəl Azure mənbəyini sizə geri marşrutlaşdırmayacaq, buna görə cavab öz defolt şlüzünə gedib ölür və ya heç çıxmır.

İki dizayn bunu həll edir və onlar bir-birini əvəz etmir. Mənbəyi çıxışda tərcümə edin, belə ki, təyinat şəbəkə daxili şəbəkənin sahib olduğu publik ünvana cavab verir. Ya da mənbəyi qoruyun və cavabların tuneldən qayıtması üçün marşrutlaşdırılmış geri əlaqə qurun. Birini seçin və tətbiqin hansı ünvanı görəcəyini yazın.

Selektorlar və icazə siyahıları bütün bunlardan ayrıdır. Azure növbəti atlamasını seçmək VPN trafik selektorlarını genişləndirmir və xarici xidmətin mənbə icazə siyahısını dəyişmir.

Təyinatın gördüyü mənbə ilə yoxlayın

Sorğunu başqa alt şəbəkədəki keçid hostundan deyil, real yükdən göndərin, sonra təyinatın gördüyü mənbə ünvanını oxuyun. Bu tək dəyər iki cavab dizaynından hansının qurulduğunu deyir. Sonra cavab yolunu yoxlayın və VM-ə adi idarəetmə trafikinin hələ də işlədiyini təsdiqləyin, çünki təsadüfən əlavə edilmiş defolt marşrut özünü sınıq tətbiqdən çox əvvəl sınıq SSH sessiyası kimi göstərir.

Seçilmiş prefiks üzərindən tranzit məcburi tuneldən qat-qat dar bir dəyişiklikdir. Onu dar saxlayın və geri qaytarma bir marşrutun silinməsidir.