Чому GRE і ESP не проходять через шлюз NAT в AWS

Тунель не працює, група безпеки вже дозволяє весь трафік, і робиться висновок, що AWS блокує VPN. Вона нічого не блокує. Керований шлюз NAT пересилає задокументований набір зовнішніх протоколів, і власні GRE або ESP до нього не входять, тому жодне додане правило не змусить шлюз їх передавати. Правило дозволу й здатність транспорту — дві різні речі, і змінити можна лише одну з них.

Набір правил — не набір протоколів

Група безпеки вирішує, якому трафіку дозволено залишати інстанс. Шлюз NAT вирішує, що він здатен транслювати й пересилати. Коли діє друге обмеження, дозвільне правило створює саме той симптом, який люди помилково читають як проблему брандмауера: пакети залишають інстанс, обмін керування може навіть завершитися, а до партнера нічого не доходить.

Специфікація протоколів шлюзу NAT від AWS перелічує TCP, UDP та ICMP для керованої служби. Це весь підтримуваний набір. Правило дозволу для іншого протоколу IP не може його розширити, бо правило оцінюється задовго до того, як досягається шлях пересилання шлюзу.

Це розрізнення важливе, позаяк обидві несправності виглядають з боку клієнта однаково і мають зовсім різні виправлення.

PPTP показує, чому перевірка порту бреше

PPTP — найяскравіший старий приклад перевірки порту, яка нічого не доводить. Він відкриває керівне з'єднання TCP на порту 1723, а потім передає дані тунелю через GRE, тобто протокол IP 47. Протокол 47 — не порт TCP 47, і ці два числа не мають нічого спільного одне з одним, крім спільних цифр.

Оператор, який перевіряє зв'язність із 1723 і бачить завершене рукостискання, доходить висновку, що шлях працює. Далі канал даних не пропускає жодного пакета, бо шлюзу нема чого запропонувати як підтримку GRE. Це тлумачення вимог старого протоколу, а не порада розгортати PPTP, який застарів багато років тому.

Ті самі міркування стосуються будь-якого протоколу, чий керівний канал — TCP або UDP, а шлях даних — ні.

IPsec виживає лише як UDP

IPsec — це випадок, коли відповідь умовна, а не категоричне ні. AWS документує NAT traversal як підтримувану схему для IPsec через шлюз NAT. За узгодженого NAT-T ESP інкапсулюється в UDP, і шлюз бачить звичайний UDP замість протоколу 50.

Дозвіл UDP 4500 не змушує кінцеві точки використовувати NAT traversal. Він лише дозволяє пакети, якщо вони вже мають таку форму. Підтвердьте з власного виводу узгодження клієнта, яку інкапсуляцію обрано, і підтвердьте на боці приймання, що партнер її прийняв. Дві кінцеві точки, налаштовані на власний ESP, продовжать надсилати власний ESP, хоч би що казав набір правил.

VPN на основі TCP або UDP вписується в задокументований набір транспортів і все одно може відмовити через маршрутизацію, фільтрування чи автентифікацію. Відповідність набору необхідна, але недостатня.

Перевірте шлях, перш ніж розширювати політику

Перевірте фактичний маршрут підмережі робочого навантаження та ідентичність її наступного стрибка спершу. Прямий публічний шлях, екземпляр NAT, керований шлюз NAT і приватний шлях через транзитний шлюз — чотири різні схеми, і лише одна з них є описаною тут керованою службою.

Потім зафіксуйте випробувану кінцеву точку, родину адрес, зовнішній протокол і порт, якщо протокол його має. Використовуйте діагностику клієнта та спостереження за потоком власника мережі замість успішного запиту браузера, який доводить лише те, що TCP і UDP працюють. Після цього перегляньте групу безпеки, ACL підмережі, брандмауер гостьової системи та політику служби для обох напрямків потоку.

Не відкривайте весь трафік, щоб компенсувати транспорт, який служба не може передати. Зміна правила це не виправить, і вона переживе інцидент.

Коли транспорт не підходить

Якщо зовнішній протокол поза підтримуваним набором, виправлення архітектурне: виберіть транспорт, який шлях може передати, або перенесіть вихід на те, що передає потрібний вам. OpenVPN через UDP, WireGuard через UDP і тунелі на основі TLS усі вписуються в задокументований набір. Екземпляр NAT під керуванням клієнта — варіант, коли конкретний протокол має пройти і експлуатаційні витрати на його утримання прийнятні.

Хостинг вхідного VPN-сервера — окрема проблема з окремою відповіддю. Шлюз NAT забезпечує вихідну трансляцію і не дає загального переадресування вхідних портів, тому серверу за ним потрібен свій схвалений публічний вхід, спроєктований на власних умовах.

Порядок роботи: назвіть зовнішній протокол, підтвердьте наступний стрибок, порівняйте його із задокументованим набором, потім змініть архітектуру або транспорт. Інший номер порту не перетворить GRE на TCP, і ще одне дозвільне правило не перетворить завершений обмін керування на робочий канал даних.