NAT у Azure VPN-у не решава проблем преклапања адреса VNet мрежа
Две VNet мреже са истим приватним опсегом не повезују се само зато што NAT постоји. Прво проверите тип везе, затим пренумеришите или поседујте алијас превода.
Обе VNet мреже користе 10.40.1.0/24, тунели се подижу и ништа не функционише. Додавање другог VPN гејтвеја то не мења, а ни нижа метрика руте, јер проблем није у избору путање. Два радна оптерећења која одговарају на исту приватну адресу остављају сваки пакет са нејасним одредиштем и непроверљивим повратним путем. Пре него што испланирате било какав превод, откријте који сте тип везе заиста направили, јер тај један избор одређује да ли је NAT функција Azure-а уопште доступна.
Шта вам симптом заправо говори
Када хост у VNet A шаље на 10.40.1.10, табела рута може га само негде усмерити. Ако и VNet B садржи 10.40.1.10, та адреса није одредиште које путања може да разликује; то је једна адреса са два власника.
Други гејтвеј који људи обично постављају не помаже. Даје вам још један тунел, а не још једну адресу, а дуплирани опсег путује унутар тунела непромењен. Такође удвостручује конфигурацију коју морате да одржавате усклађеном. Оно што не може јесте да учини да једна адреса значи два хоста.
Промена јавних адреса VPN партнера такође не чини ништа. Те адресе означавају крајње тачке тунела, док је колизија у приватном опсегу који се преноси унутра.
Тип везе одлучује да ли је NAT доступан
Azure VPN Gateway заиста има NAT могућност, и она је документована за IPsec везе између локација засноване на рутама на одређеним гејтвеј SKU-овима. Иста документација искључује VNet-to-VNet и point-to-site везе, па то није поље за потврду које се појављује на сваком гејтвеј односу.
| 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 |
Изворни VNet-to-VNet такође захтева да се опсези VNet мреже и локалне мреже од почетка не преклапају, што је у складу са искључењем. VNet peering није решење за преклапање из истог разлога.
Постоји подржана алтернатива коју људи бркају са изворним типом: моделујте другу VNet мрежу као локалну мрежу и повежите је као везу између локација. То је други ресурс и други дизајн, па преименовану везу третирајте као промену коју треба валидирати, а не као пуко преименовање.
Пренумеришите, или преводите са нечим што поседује алијас
Ако су обе VNet мреже ваше, упоредите планирано пренумерисање са трајним трошком превода. Пренумерисање дира конфигурацију апликација, DNS записе, безбедносна правила и сваку постојећу везу, али оставља мрежу која се након тога чита нормално. Радите то једну по једну подмрежу, са променом DNS-а на крају. Напола пренумерисан опсег је гори од било које опције, јер тада оба префикса изгледају меродавно ономе ко следећи прочита табелу.
Где пренумерисање није практично, користите преведени дизајн са стварним власником алијаса. Позиваоци у VNet A могу да досегну 10.40.1.10 у VNet B као 10.140.1.10, али тај алијас треба уређај који преводи, руту према њему и одговарајуће понашање за одговор. Адреса додата само у DNS није превод.
Забележите оба опсега у оба смера: шта позивалац бира, шта одредиште види као извор и која страна сме да започне. Azure-ова сопствена NAT правила укључују обрнути превод за своја SNAT мапирања, па не пишете одговарајуће DNAT правило ручно, али та погодност престаје код типова веза које функција подржава.
Шта неће функционисати
Кориснички дефинисана рута или метрика руте не могу да створе разлику адреса која недостаје. Оба раде на одредишту које је још нејасно, а пакет стиже на следећи скок који табела преферира.
Додавање дуплираног опсега у табелу рута као специфичнијег префикса помера нејасноћу само један корак. Такође обично квари други смер, где одговор сада има два веродостојна извора.
Прихватите дизајн са саобраћајем у оба смера
Докажите дизајн свежом дозвољеном операцијом са сваке стране, не статусом тунела. Повезан IPsec тунел каже да су партнери сагласни око криптографије; не каже ништа о томе да ли су одредишта постала разлучива.
Затим покрените забрањене путање: адресу која треба да остане недоступна и услугу коју политика треба да блокира. Ако обоје и даље успева, превод је шири него што је дизајн намеравао.
Завршите чињеницама које касније објашњавају поставку: изворни опсег, представљени опсег, уређај који преводи и смер у којем свака страна сме да започне. Ако нешто од тога недостаје, следећи инжењер наслеђује мрежу у којој два хоста деле име и нико се не сећа зашто један од њих одговара.