Azure VPN NAT üst-üstə düşən VNet ünvanlarını həll etmir
Eyni özəl diapazona malik iki VNet yalnız NAT olduğu üçün birləşməyəcək. Əvvəlcə bağlantı növünü yoxlayın, sonra nömrələri dəyişin və ya tərcümə ləqəbinə sahib olun.
Hər iki VNet 10.40.1.0/24 diapazonundan istifadə edir, tunellər qalxır və heç nə işləmir. İkinci VPN şlüzəsi əlavə etmək bunu dəyişmir, daha aşağı marşrut metriki də dəyişmir, çünki problem yol seçimində deyil. Eyni özəl ünvana cavab verən iki iş yükü hər paketi qeyri-müəyyən təyinat və yoxlanıla bilməyən qayıdış yolu ilə qoyur. Hər hansı tərcümə planlaşdırmadan əvvəl hansı bağlantı növünü həqiqətən yaratdığınızı öyrənin, çünki bu tək seçim Azure-un NAT funksiyasının ümumiyyətlə mövcud olub-olmadığını müəyyən edir.
Simptom əslində sizə nə deyir
VNet A-dakı host 10.40.1.10 ünvanına göndərdikdə, marşrut cədvəli onu yalnız bir yerə yönəldə bilər. Əgər VNet B-də də 10.40.1.10 varsa, bu ünvan yolun ayırd edə biləcəyi təyinat deyil; bu, iki sahibi olan bir ünvandır.
İnsanların adətən yerləşdirdiyi ikinci şlüzə kömək etmir. O sizə başqa tunel verir, başqa ünvan yox, və təkrarlanan diapazon tunelin içində dəyişmədən hərəkət edir. O, həm də ardıcıl saxlamalı olduğunuz konfiqurasiyanı ikiqat artırır. Edə bilmədiyi şey bir ünvanın iki host mənasına gəlməsini təmin etməkdir.
VPN həmkarlarının ictimai ünvanlarını dəyişmək də heç nə etmir. Bu ünvanlar tunelin son nöqtələrini müəyyən edir, toqquşma isə onun içində daşınan özəl diapazondadır.
Bağlantı növü NAT-ın mövcud olub-olmadığını müəyyən edir
Azure VPN Gateway həqiqətən NAT qabiliyyətinə malikdir və bu, müəyyən şlüzə SKU-larında marşruta əsaslanan IPsec sahələrarası bağlantılar üçün sənədləşdirilib. Eyni sənədlər VNet-to-VNet və point-to-site bağlantılarını istisna edir, buna görə funksiya hər şlüzə əlaqəsində görünən bir işarə qutusu deyil.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Doğma VNet-to-VNet həm də VNet və yerli şəbəkə diapazonlarının əvvəlcədən üst-üstə düşməməsini tələb edir, bu da istisna ilə uyğundur. VNet peerinqi də eyni səbəbdən üst-üstə düşmə həlli deyil.
İnsanların doğma növlə qarışdırdığı dəstəklənən bir alternativ var: digər VNet-i yerli şəbəkə kimi modelləşdirin və onu sayt-sayt bağlantısı kimi qoşun. Bu fərqli resurs və fərqli dizayndır, buna görə adı dəyişdirilmiş bağlantıya ad dəyişikliyi kimi deyil, yoxlanılmalı dəyişiklik kimi baxın.
Nömrələri dəyişin və ya ləqəbə sahib olan bir şeylə tərcümə edin
Hər iki VNet sizindirsə, planlaşdırılmış nömrə dəyişikliyini tərcümənin davamlı xərci ilə müqayisə edin. Nömrə dəyişikliyi tətbiq konfiqurasiyasına, DNS qeydlərinə, təhlükəsizlik qaydalarına və hər mövcud bağlantıya toxunur, amma sonradan normal oxunan bir şəbəkə buraxır. Bunu bir alt şəbəkə ilə edin, DNS dəyişikliyi ən sonda olsun. Yarı nömrələnmiş diapazon hər iki variantdan pisdir, çünki o zaman hər iki prefiks cədvəli sonra oxuyan üçün etibarlı görünür.
Nömrə dəyişikliyi praktik olmadıqda, ləqəb üçün həqiqi sahibi olan tərcümə edilmiş dizayn istifadə edin. VNet A-dakı çağıranlar VNet B-nin 10.40.1.10 ünvanına 10.140.1.10 kimi çata bilər, lakin bu ləqəb tərcümə edən cihaz, ona doğru marşrut və cavab üçün uyğun davranış tələb edir. Yalnız DNS-ə əlavə edilmiş ünvan tərcümə deyil.
Hər iki diapazonu hər iki istiqamətdə qeyd edin: çağıranın yığdığı ünvan, təyinatın mənbə kimi gördüyü ünvan və hansı tərəfin başlada biləcəyi. Azure-un öz NAT qaydaları SNAT xəritələmələri üçün əks tərcüməni ehtiva edir, buna görə uyğun DNAT qaydasını əl ilə yazmırsınız, lakin bu rahatlıq funksiyanın dəstəklədiyi bağlantı növlərində bitir.
Nə işləməyəcək
İstifadəçi tərəfindən müəyyən edilmiş marşrut və ya marşrut metriki çatışmayan ünvan fərqini yarada bilməz. Hər ikisi hələ də qeyri-müəyyən olan təyinat üzərində işləyir və paket cədvəlin üstün tutduğu növbəti hopa çatır.
Təkrarlanan diapazonu marşrut cədvəlinə daha dəqiq prefiks kimi əlavə etmək qeyri-müəyyənliyi yalnız bir addım irəli aparır. O, həm də digər istiqaməti pozmağa meyllidir, çünki cavabın artıq iki ehtimal olunan mənbəyi var.
Dizaynı hər iki istiqamətdə trafiklə qəbul edin
Dizaynı tunel statusu ilə deyil, hər tərəfdən yeni icazəli əməliyyatla sübut edin. Qoşulmuş IPsec tuneli həmkarların kripto barədə razılaşdığını deyir; təyinatların fərqləndirilə bilən olub-olmadığı barədə heç nə demir.
Sonra rədd edilən yolları işə salın: əlçatmaz qalmalı olan ünvan və siyasətin bloklamalı olduğu xidmət. Əgər hər ikisi hələ də uğur qazanırsa, tərcümə dizaynın nəzərdə tutduğundan daha genişdir.
Quraşdırmanı sonradan izah edən faktlarla yekunlaşdırın: orijinal diapazon, təqdim edilən diapazon, tərcümə edən cihaz və hər tərəfin başlada biləcəyi istiqamət. Bunlardan hər hansı biri yoxdursa, növbəti mühəndis iki hostun eyni adı paylaşdığı və heç kimin birinin niyə cavab verdiyini xatırlamadığı bir şəbəkə miras alır.