Повний тунель Access Server на EC2: чому одного прапорця недостатньо

Вимкнення перевірки джерела та призначення на екземплярі EC2 — найчастіше повторювана відповідь на питання про вихід Access Server в інтернет, і сама по собі вона нічого не робить для ваших клієнтів. Перевірка — це обмеження пересилання в AWS: вона дозволяє екземпляру приймати пакети, джерело або призначення яких не є його власною адресою. Вона не каже клієнту Access Server надсилати інтернет-трафік через тунель, не створює маршрут угору і не додає NAT. Міф у тому, що прапорець і є функція.

Що перевірка насправді контролює

Кожен мережевий інтерфейс EC2 відкидає трафік, який йому не адресований, якщо тільки екземпляр не працює як маршрутизатор, пристрій NAT або VPN-шлюз і ви не вимкнете цю перевірку. Вимкнення дає дозвіл пересилати. Дозвіл — не конфігурація: екземпляру все ще потрібен маршрут до інтернет-шлюзу або пристрою NAT, таблиці маршрутів VPC усе ще потрібен відповідний запис, групи безпеки все ще мають дозволяти потік, а сервер усе ще має транслювати або маршрутизувати зворотний трафік.

Перевірте поточне значення за допомогою aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, перш ніж щось змінювати. Якщо ви змінюєте його в консолі, робіть це тому, що екземпляр пересилає за інших, а не тому, що клієнт не може потрапити в інтернет.

Політика маршрутизації клієнта належить Access Server

У Access Server 3 відкрийте Access Controls і знайдіть розділ Internet Access and DNS. Вибір Internet Gateway пропонує повний або розділений тунель; повний тунель велить клієнту спрямовувати типовий трафік у VPN, розділений залишає інтернет-трафік на локальному шляху клієнта. Збережіть і застосуйте через робочий процес продукту, потім перепідключіть тестового клієнта, бо політика доставляється в момент підключення.

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

Простежте пакет після тунелю

Коли клієнт надсилає інтернет-трафік у тунель, сервер має його переслати і зазвичай транслювати. Access Server керує власними правилами NAT і маршрутизації, тож читайте фактичну конфігурацію, а не додавайте правила Community OpenVPN до згенерованих файлів; некеровані правила перезаписуються або конфліктують під час наступного оновлення продукту. sudo iptables -t nat -L -n -v або еквівалент nftables показує, що насправді транслюється.

Бік AWS — окремий шлях. Екземпляр у публічній підмережі досягає інтернет-шлюзу напряму і зберігає свою публічну адресу або еластичний IP. Екземпляру в приватній підмережі потрібен маршрут до NAT-шлюзу або NAT-екземпляра, а пристрою NAT потрібен власний маршрут до інтернет-шлюзу. Приєднання інтернет-шлюзу до VPC саме по собі не дає жодному приватному джерелу публічної зворотної адреси, тому те саме налаштування Access Server працює в одній підмережі й тихо відмовляє в іншій.

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

Тримайте вихід IP і DNS окремо

Спочатку перевірте літерал адреси, потім ім’я, з того самого клієнтського застосунку. Якщо curl -4 https://checkip.amazonaws.com повертає публічну адресу, але імена хостів не працюють, тунель і шлях NAT працюють, а проблема в DNS: надісланий резолвер, стан резолвера клієнта або група безпеки, що блокує резолвер. Налаштування DNS Access Server розташовані в тій самій області Internet Access, але вони йдуть іншим шляхом коду.

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

Не дозволяйте одному прапорцю закрити розслідування

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

Насамкінець перевірте відключений стан. Вибір повного тунелю описує політику маршрутизації під час підключення, а не те, що станеться, коли тунель упаде. Якщо вимога в тому, щоб жоден трафік не витік за межі VPN, це питання kill-switch і міжмережевого екрана, і воно потребує власної перевірки, а не висновку з таблиці маршрутів.