NAT във Azure VPN не решава проблема със застъпващи се адреси на VNet

И двете 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, така че функцията не е отметка, която се появява при всяка връзка на шлюз.

Собственият VNet-to-VNet също изисква диапазоните на VNet и локалната мрежа да не се застъпват от самото начало, което е в съответствие с изключването. VNet peering не е решение за застъпване по същата причина.

Има поддържана алтернатива, която хората бъркат със собствения тип: представете другата VNet като локална мрежа и я свържете като връзка между площадки. Това е различен ресурс и различен дизайн, затова третирайте преименуваната връзка като промяна, която трябва да се валидира, а не като просто преименуване.

Преномерирайте или транслирайте с нещо, което притежава псевдонима

Ако и двете VNet са ваши, сравнете планираното преномериране с текущата цена на транслацията. Преномерирането засяга конфигурацията на приложенията, DNS записите, правилата за сигурност и всяка съществуваща връзка, но оставя мрежа, която след това се чете нормално. Правете го по една подмрежа наведнъж, с DNS промяната последна. Наполовина преномериран диапазон е по-лош от двете опции, защото тогава и двата префикса изглеждат авторитетни за този, който прочете таблицата следващия.

Където преномерирането не е практично, използвайте транслиран дизайн с реален собственик на псевдонима. Извикващите в VNet A може да достигат 10.40.1.10 на VNet B като 10.140.1.10, но този псевдоним се нуждае от устройство, което транслира, маршрут към него и съответно поведение за отговора. Адрес, добавен само в DNS, не е транслация.

Запишете и двата диапазона в двете посоки: какво набира извикващият, какво дестинацията вижда като източник и коя страна може да инициира. Собствените NAT правила на Azure включват обратната транслация за своите SNAT преобразувания, така че не пишете съответно DNAT правило на ръка, но това удобство спира при типовете връзки, които функцията поддържа.

Какво няма да работи

Маршрут, дефиниран от потребителя, или метрика на маршрут не могат да създадат липсващо разграничение на адреси. И двете работят върху дестинация, която все още е двусмислена, и пакетът пристига при следващия хоп, който таблицата предпочита.

Добавянето на дублиращия се диапазон към таблица за маршрутизация като по-конкретен префикс само премества двусмислието с една стъпка. То също така често чупи другата посока, където отговорът вече има два вероятни източника.

Приемете дизайна с трафик в двете посоки

Докажете дизайна с прясна разрешена операция от всяка страна, а не със статус на тунела. Свързан IPsec тунел казва, че партньорите са съгласни за криптографията; той не казва нищо за това дали дестинациите са станали различими.

След това пуснете забранените пътища: адрес, който трябва да остане недостъпен, и услуга, която политиката трябва да блокира. Ако и двете все още успяват, транслацията е по-широка, отколкото дизайнът е предвиждал.

Завършете с фактите, които по-късно обясняват настройката: оригиналният диапазон, представеният диапазон, устройството, което транслира, и посоката, в която всяка страна може да инициира. Ако някое от тях липсва, следващият инженер наследява мрежа, в която два хоста споделят име и никой не помни защо един от тях отговаря.