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 обмен.

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

Класифицирайте повредата по етап, преди да промените нещо, и запазете тази класификация в тикета, за да започне следващият човек оттам, където вие сте спрели.