NVA olmadan ExpressRoute üzərindən Azure özəl IP VPN

Mif budur ki, ExpressRoute özəl peering üzərində trafiki şifrələmək üçün şəbəkə virtual cihazı tələb olunur. Bu doğru deyil. Azure, tunel son nöqtəsi dövrə üzərindən daşınan özəl RFC1918 ünvanı olan Site-to-Site VPN Gateway-i dəstəkləyir və cihaz struktur deyil, opsionaldır. Cihaz mifinin gizlətdiyi hissə isə həqiqətən problem yaradan hissədir: özəl son nöqtəni iki obyekt yerinə bir obyektdə aktivləşdirmək və birbaşa peering marşrutunun səssizcə şifrələnmiş yoldan üstün gəlməsinə icazə vermək.

Mif haradan gəldi

İddianın hörmətli kökü var. İllər boyu özəl peering üzərində IPsec üçün praktik resept NVA idi, çünki idarə olunan gateway yalnız açıq son nöqtələr təqdim edirdi. Bu dəyişdi və dəyişiklikdən əvvəl yazılmış cavablar hələ də tarixi heç kimin yoxlamadığı müzakirələrdə sitat gətirilir. Düzəliş dardır: özəl ünvanlı VPN gateway mövcuddur və o, son nöqtəni dəyişir, onun ətrafındakı marşrutlaşdırma məntiqini deyil.

Bunların heç biri NVAnı təqaüdə çıxarmır. O, yalnız cihazın tələbin yeganə yolu olması fərziyyəsini təqaüdə çıxarır.

Özəl son nöqtəni hər iki səviyyədə aktivləşdirin

VPN gateway-in yerləşdiyi VNet-ə bağlanmış işlək ExpressRoute özəl peering bağlantısından başlayın. Yerli tərəf artıq həmin dövrə üzərindən müvafiq özəl ünvanlara çatmalıdır, çünki tunel bu ünvanları nəqliyyat kimi istifadə edəcək. Sonra gateway ilkin şərti: özəl IP VPN üçün Microsoft proseduru Standard açıq IP resursu üzərində qurulmuş gateway tələb edir. Özəl tunel ünvanlaması bu tələbi aradan qaldırmır; bu, «özəl» sözünün «heç yerdə açıq IP yoxdur» demək olduğunu düşünənləri təəccübləndirir.

İndi bayrağı hər iki yerdə aktivləşdirin. Gateway konfiqurasiyasının özəl IP-lər üçün öz açarı var, ayrı-ayrı Site-to-Site bağlantısının isə həmin bağlantının özəl ünvandan istifadə etməsini təmin edən ikinci açarı var. Birini qurub digərini qurmamaq ən çox rast gəlinən natamam konfiqurasiyadır; tunel ya qurulmur, ya da səhv son nöqtədə qurulur.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Xüsusiyyət adlarını quraşdırılmış CLI versiyası ilə yoxlayın, çünki portal etiketləri ilə CLI xüsusiyyətləri həmişə eyni ifadəni paylaşmır. Aktiv-aktiv gateway iki özəl tunel ünvanı təqdim edir və bu artıqlığın mənası olmasını istəyirsinizsə, yerli cihazda hər iki peer konfiqurasiya edilməlidir. Yalnız bu özəl ünvanlı tuneli qaldırmaq üçün BGP tələb olunmur, baxmayaraq ki, o, adətən prefiksləri paylamağın bir hissəsidir.

İkinci mif: qurulmuş tunel trafiki şifrələyir

İndi tətbiq şəbəkəsinə iki yol çatır: birbaşa özəl peering yolu və VPN vasitəsilə yol. Hər ikisi işləyir. Yalnız biri bu IPsec qatını tətbiq edir. Microsoft sənədləşdirir ki, eyni prefikslər həm ExpressRoute, həm də VPN üzərindən elan edildikdə Azure birbaşa ExpressRoute yoluna üstünlük verir, buna görə sağlam tunel və sağlam sayğaclar tətbiq paketlərinin hara getdiyi barədə heç nə sübut etmir.

Sənədləşdirilmiş yönləndirmə üsulları ExpressRoute üzərində əhatə edən diapazon və VPN üzərində daha konkret qorunan diapazon, ya da iki yolda bir-birini kəsməyən prefikslərdir. Nümunə üçün, özəl peering 10.40.0.0/16 daşıya bilər, VPN isə 10.40.12.0/24 elan edir. Daha konkret prefiks qalib gəlir və diapazonun qalanı birbaşa qalır.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Eyni yoxlamanı yerli istiqamətdə də edin, çünki marşrutlaşdırıcınızın üstünlüyü çıxan trafikin hansı tərəfə getdiyini müəyyən edir. Və tunelin öz nəqliyyatını ExpressRoute yolunda saxlayın; gateway-in özəl son nöqtəsini tunelin içinə çəkən marşrut tuneli özündən asılı vəziyyətə salır.

Tunel düşəndə nə olacağına qərar verin

Tunel düşəndə daha konkret VPN marşrutu yox olur, daha geniş birbaşa marşrut isə qalır. Sonra trafik şifrələnmədən axır və hər şey sağlam görünür; bu, şifrələməni zəmanət etmək üçün mövcud olan tələb üçün ən pis nasazlıq rejimidir. Əgər tələb bu geri dönüşü qadağan edirsə, marşrutlaşdırma və giriş siyasəti tunelin mövcudluğuna güvənmək əvəzinə bunu açıq şəkildə bildirməlidir.

Hansı prefikslərin birbaşa əlçatan qala biləcəyini və hansıların şifrələnmiş yol olmadıqda dayanmalı olduğunu yazın. Sonra icazə verilən halı real trafiklə sınayın və bağlantı sayğaclarını müqayisə edin, çünki yalnız marşrut cədvəli şifrələmə tələbinin hələ də qüvvədə olub-olmadığını sizə deməyəcək.

Bu çərçivə həm də NVAnı son nöqtə özəl olduğu üçün almaq əvəzinə, onun həqiqi funksiyalarına — çoxsaylı tunellər, ötürmə qabiliyyəti və ya təchizatçı yoxlaması — görə qiymətləndirməyə imkan verir.