VPN між сайтами в Azure з партнером за 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.

Якщо два сайти використовують перекривні приватні діапазони, трансляція всередині тунелю — окрема схема з власними правилами. Не перенумеровуйте підмережу лише тому, що зовнішній шлюз випадково стоїть за домашнім маршрутизатором.

Перш ніж щось змінювати, класифікуйте збій за етапом і збережіть цю класифікацію в тікеті, щоб наступна людина почала там, де ви зупинилися.