Azure VPN помеѓу локации со партнер зад NAT: контролна листа

Изведете ги овие проверки по ред и застанете на првата што не успева. Повеќето извештаи дека Azure не поддржува уред зад NAT всушност се адреса на партнер до која Azure не може да стигне, или тунел што никогаш не започнува од правилната страна. Надворешниот транспорт и внатрешното рутирање се два различни проблема, а нивното мешање троши попладне. Секој чекор подолу дава набљудување што можете да му го предадете на некој друг.

Чекор 1: потврдете дека партнерот воопшто е зад NAT

Споредете ја адресата на WAN интерфејсот на уредот со адресата што Azure ја гледа за него. Ако се разликуваат, нешто преведува, и тој преведувач сега е дел од вашиот VPN дизајн. Прашајте го давателот дали мапирањето е статично или споделено, бидејќи споделеното мапирање го менува она на што можете да се потпрете. Уред со приватна WAN адреса и без препраќање е различен случај од уред зад NAT на операторско ниво со стабилно јавно мапирање.

Ако двете адреси се совпаѓаат, застанете тука: NAT не е вашиот проблем и остатокот од листата нема да помогне.

Запишете ги двете адреси и моделот на преведувачот во тикетот. Таа една линија го спречува следниот круг прашања зошто конфигурираниот партнер не одговара.

Чекор 2: договорете се кој иницира

Најчесто поставувани прашања за Azure VPN Gateway наведуваат поддршка за NAT-T и додаваат дека локалниот уред треба да го иницира IPsec тунелот кога е зад NAT. Тоа одговара на тоа како работи преводот со состојба, бидејќи преведувачот држи мапирање затоа што внатрешниот уред го испратил првиот пакет. Ако се очекува Azure да иницира, а ништо не доаѓа за да го создаде тоа мапирање, тунелот никогаш не започнува.

Конфигурирајте го партнерот така што грешката само-одговарач да биде очигледна, и проверете дали уредот сам се обидува повторно или му треба тригер. Некои уреди креваат тунел само кога ќе се појави интересен сообраќај, што е во ред сè додека интересниот сообраќај не е здравствена проверка што никогаш не доаѓа.

Набљудувајте ја IKE размената на уредот при рачно иницирање; тишината таму е одговор на рутирањето или огнениот ѕид, не одговор на Azure.

Чекор 3: поставете ја правилно адресата на партнерот

Azure бара достапна јавна адреса за партнерот во објектот на локалниот мрежен портал, обично јавната адреса на преведувачот, а не внатрешната адреса на уредот. Идентитетот со кој уредот се автентификува е одделно поле и може законски да се разликува од адресата што Azure ја бира. Држете ги двете одвоени, бидејќи нивната замена создава грешка при автентикација што изгледа точно како проблем со NAT.

Ако јавната адреса се промени, тој објект мора да се промени со неа. Име што се решава на застарена адреса е полошо од статична адреса што морате рачно да ја ажурирате.

Запишете ги сите три вредности: локалната адреса на уредот, преведената јавна адреса и конфигурираниот идентитет на партнерот.

Чекор 4: отворете ги само портите што ги бара NAT-T

NAT-T го пренесува ESP внатре во UDP, а RFC 3948 го опишува тоа инкапсулирање со порта 4500 што се користи по почетното преговарање на портата 500. Вашиот огнен ѕид и преведувачот мора да ја дозволат размената и нејзиниот повратен сообраќај. Дозволувањето на неврзана TCP порта не докажува ништо за овој пат, а правило што дозволува излез но не и одговор сè уште ќе не успее.

Статично препраќање на влезна порта не е автоматски потребно кога партнерот иницира и преведувачот држи состојба. Станува потребно кога мапирањето е нестабилно или кога нешто на патот агресивно ја истекува состојбата.

Снимете еднаш од двете страни на преведувачот; разликата во инкапсулирањето е веднаш видлива.

Чекор 5: одвојте го надворешниот транспорт од внатрешното рутирање

Тунел што се воспоставува и не пренесува ништо е проблем со рутирањето, не проблем со NAT-T. Локациите сè уште бараат компатибилни селектори на сообраќај, соодветни адресни простори, правила за пристап и повратен пат за апликациските мрежи. Ништо од тоа не го обезбедува успешна IKE размена.

Ако двете локации користат преклопувачки приватни опсези, преводот внатре во тунелот е одделен дизајн со свои правила. Не пренумерувајте подмрежа само затоа што надворешниот портал случајно е зад домашен рутер.

Класифицирајте го дефектот по фаза пред да промените нешто, и задржете ја таа класификација во тикетот за следната личност да започне каде што застанавте.