Azure peering, yoxsa VNet-dən VNet-ə VPN? Marşrut əlavə etməzdən əvvəl qərar verin

Azure sizə iki virtual şəbəkəni birləşdirməyin ən azı iki yolunu verir və bunlar eyni obyekt üzərində bir-birini əvəz edən parametrlər deyil. Peering VNet-ləri Microsoft-un magistralında şlüz olmadan birləşdirir; VNet-dən VNet-ə VPN isə yerləşdirdiyiniz, ölçüləndirdiyiniz və izlədiyiniz iki şlüz arasında IPsec əlaqəsi qurur. Qərar üç şərtdən asılıdır və əgər marşrut əlavə etməzdən əvvəl hər üçünə cavab verə bilmirsinizsə, heç vaxt seçmədiyiniz model üçün müvəqqəti həll qurmaq üzrəsiniz.

Modeli müəyyən edən üç şərt

Birincisi, tələbin hər hansı hissəsinin sizə məxsus və göstərə biləcəyiniz IPsec sərhədinə ehtiyacı olub-olmadığıdır. İkincisi, ünvan məkanlarının təmiz olub-olmadığı və iki VNet-in yalnız bir-biri ilə danışmalı olub-olmadığıdır. Üçüncüsü, hər hansı tranzitiv marşrutun və şlüz hesabının kimə məxsus olmasıdır. Onlara bu sıra ilə cavab verin, çünki birinci şərt ikincisi nə qədər cəlbedici görünsə də peeringi istisna edə bilər.

Hər iki modelin ortaq olduğu şey sərt ünvanlama qaydasıdır: VNet ünvan məkanları üst-üstə düşməməlidir. Nə peering, nə də VNet-dən VNet-ə VPN iki eyni diapazonu birmənalı etməyin dəstəklənən yolu deyil və üst-üstə düşmə fərqli əlaqə növü deyil, xəritələmə dizaynı və ya yenidən layihələndirmə tələb edir.

Şərt 1: sizə məxsus IPsec sərhədinə ehtiyacınız var?

Peering trafiki Azure-un şəxsi magistralı ilə daşıyır və peering əlaqəsinin özü üçün VPN şlüzü tələb etmir. Bu nəqliyyat barədə ifadədir, auditə «biz IPsec işlədirik» kimi təqdim edə biləcəyiniz şifrələmə ifadəsi deyil. Əgər tələb müştərinin konfiqurasiya etdiyi tuneli, konkret IKE siyasətini və ya nəzarət etdiyiniz avadanlıqda bitən sərhədi adlandırırsa, magistral nə qədər şəxsi olsa da, peering onu ödəmir.

VNet-dən VNet-ə VPN həmin sərhədi həqiqətən təmin edir: iki şlüz, IPsec/IKE əlaqəsi, ortaq açarlar və bununla gələn bütün əməliyyat səthi. Siz tunel vəziyyətini, şlüz tutumunu, SKU limitlərini və tunelin işlədiyini sübut edən monitorinqi miras alırsınız. Tələb məhz bu sərhəd barədə olduqda düzgün cavab budur və bu, peering icmalında peeringdən fərqli əlaqə növü kimi təsvir olunur.

Digər istiqamətdə də eyni dərəcədə diqqətli olun. «VNet-lər arasında şifrələmə lazımdır» ifadəsi çox vaxt iş yükünün öz TLS-i ilə ödənilir və o zaman şlüz arxasında heç bir tələb olmayan xərcdir. Mexanizmi seçməzdən əvvəl auditorun oxuyacağı cümləni yazın.

Şərt 2: topologiya birbaşadır, yoxsa nəyinsə tranziti lazımdır?

Peering tranzitiv deyil. Bir mərkəzə peer olunmuş iki VNet bununla bir-birinə qoşulmuş olmur və bir istiqamətdə işləyən kimi görünən marşrut adətən yalnız bir tərəfdə Connected vəziyyətinə çatmış peeringdir. Hər iki tərəf mövcud olmalı və hər ikisi Connected göstərməlidir; trafik səssizcə yox olduqda ilk yoxlanılan budur.

Tələb mərkəz vasitəsilə yerli şəbəkəyə çıxışdırsa, şlüz tranziti xüsusi rolları olan ayrı dizayndır: şlüz mərkəzə məxsusdur, filial peeringi şlüz tranzitinə icazə verir və filial yönləndirilmiş trafika icazə verməlidir. Bunlar peering üzərində xassələrdir, VNet-lərin birləşdirilməsinin avtomatik nəticələri deyil:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Effektiv marşrut cədvəli «yol mövcuddurmu?» sualına dürüst cavabdır. Platformanın həqiqətən istifadə edəcəyi növbəti atlama növünü göstərir, ona görə konfiqurasiya edilmiş görünən amma qoşulmamış peering sirr kimi deyil, çatışmayan və ya səhv marşrut kimi görünür.

Şərt 3: tranzitiv marşrut və hesab kimə məxsusdur?

Hər əlavə atlamanın sahibi var. Peeringdə yeni VNet hər iki tərəfdə yeni peering cütü, tranzit üçün isə trafiki yönləndirməyə davam edən mərkəz və ona işarə edən marşrut cədvəli deməkdir. VPN-də yeni VNet başqa şlüz və ya mövcud şlüz üzərində başqa əlaqə deməkdir və onun öz izlənilməli tutum həddi var.

Xərc eyni formanı izləyir, amma eyni maddələri deyil: peering ödənişləri əlaqə və məlumat ötürülməsidir, VPN isə şlüz saatlarını və öz ötürmə ödənişlərini əlavə edir. Bir il ərzində həqiqətən işlədəcəyiniz topologiyanın cəmini müqayisə edin, ikinci tunel və monitorinq daxil olmaqla, bugünkü bir əlaqənin qiymətini deyil. Heç kimin fakturalamadığı əməyi də daxil edin: kimsə açarları döndərməli, tunel vəziyyətini izləməli və şlüz yenidən başladıqda gecə saat üçdə siqnala cavab verməlidir. Adətən mübahisəni məhz bu maddə həll edir, çünki qiymət təklifində heç vaxt görünməyən yeganə maddə odur.

Hansını seçsəniz də, üç axını sınayın: nəzərdə tutulanı, rədd edilmiş qalmalı olanı və mərkəz şlüzünün və ya peeringin işləmədiyi bərpa halını. Yalnız xoşbəxt yolu izah edən model yoxlanılmayıb, nümayiş etdirilib.

Seçimi öz iddiası ilə yoxlayın

Modeli, sərhədi və sahibi adlandıran bir cümlə yazın, sonra yerləşdirilmiş vəziyyətin ona uyğun olduğunu yoxlayın. Peering üçün bu, hər iki peering vəziyyətinin Connected olması, effektiv marşrutun təyinat prefiksi üçün peering növbəti atlamasını göstərməsi və yolda şlüz olmaması deməkdir. VNet-dən VNet-ə VPN üçün bu, hər iki əlaqənin Connected olması, hər iki şlüzdə uyğun açarlar və siyasətlər, və növbəti atlaması virtual şəbəkə şlüzü olan marşrut deməkdir.

Yoxlamalar cümlə ilə ziddiyyət təşkil edirsə, əvvəlcə cümləni düzəldin. Bu dizaynlardakı qarışıqlığın çoxu heç kimin təsvir etmədiyi hibriddən gəlir: iş yükü alt şəbəkəsi üçün peering, bir köhnə xidmət üçün VPN və səssizcə birini üstün tutan marşrut cədvəli.