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 вкрстувањето исто така не е решение за преклопување од истата причина.
Постои поддржана алтернатива што луѓето ја мешаат со нативниот тип: моделирајте ја другата VNet како локална мрежа и поврзете ја како врска од локација до локација. Тоа е друг ресурс и друг дизајн, па преименуваната врска третирајте ја како промена што треба да се валидира, а не како обично преименување.
Пренумерирајте или преведувајте со нешто што го поседува алијасот
Ако двете VNet се ваши, споредете го планираното пренумерирање со тековниот трошок за превод. Пренумерирањето допира конфигурација на апликации, DNS записи, безбедносни правила и секоја постоечка врска, но остава мрежа што потоа се чита нормално. Правете го една подмрежа по една, со промената на DNS последна. Полу-пренумериран опсег е полош од двете опции, бидејќи тогаш двата префикси изгледаат авторитетни за тој што следен ќе ја прочита табелата.
Каде што пренумерирањето не е практично, користете преведен дизајн со вистински сопственик за алијасот. Повикувачите во VNet A може да достигнат 10.40.1.10 на VNet B како 10.140.1.10, но тој алијас бара уред што преведува, рута кон него и соодветно однесување за одговорот. Адреса додадена само во DNS не е превод.
Запишете ги двата опсези во двете насоки: што бира повикувачот, што гледа дестинацијата како извор и која страна смее да иницира. Сопствените NAT правила на Azure ја вклучуваат обратната транслација за нивните SNAT мапирања, па не пишувате соодветно DNAT правило рачно, но таа погодност запира кај типовите врски што функцијата ги поддржува.
Што нема да работи
Кориснички дефинирана рута или метрика на рута не можат да создадат разлика во адресите што недостасува. Двете работат на дестинација што е сѐ уште двосмислена, а пакетот пристигнува на следниот скок што табелата го претпочита.
Додавањето на дупликат опсегот во табела за рутирање како поконкретен префикс ја поместува двосмисленоста само еден чекор. Исто така, обично го крши спротивниот правец, каде одговорот сега има два веројатни извори.
Прифатете го дизајнот со сообраќај во двете насоки
Докажете го дизајнот со свежа дозволена операција од секоја страна, а не со статус на тунелот. Поврзан IPsec тунел кажува дека партнерите се согласни за криптографија; не кажува ништо за тоа дали дестинациите станале разликливи.
Потоа пуштете ги забранетите патишта: адреса што треба да остане недостапна и услуга што политиката треба да ја блокира. Ако двете сѐ уште успеваат, преводот е поширок од она што дизајнот го предвидел.
Завршете со фактите што подоцна ќе го објаснат поставувањето: оригиналниот опсег, претставениот опсег, уредот што преведува и насоката во која секоја страна смее да иницира. Ако нешто од тоа недостасува, следниот инженер наследува мрежа каде два домаќини делат име и никој не се сеќава зошто еден од нив одговара.