Тунель піднято, інтернету немає: де зупиняється пересилання

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

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

Переконайтеся, що вихід в інтернет узагалі був задуманий

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

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

Простежте один публічний запит

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Якщо шлюз ніколи не бачить пакет, маршрут клієнта або вибір тунелю неправильні. Якщо пакет надходить і не виходить, проблема на шлюзі, і діють три перевірки, що залишилися.

Перевірте пересилання, маршрут і трансляцію

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Трансляція джерела — звичайний відсутній елемент. З нею шлюз підміняє джерело клієнта на свою публічну адресу і відстежує потік; без неї відповіді нікуди йти. Хмарні платформи додають другу межу, де таблиця маршрутів або група безпеки екземпляра можуть відкинути трафік, який дозволяє гостьовий міжмережевий екран. Цю межу легко проґавити, бо гостьова система зсередини виглядає налаштованою правильно.

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

Зворотний шлях і розв’язувач імен — дві різні відповіді

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

Сайт, що повертає помилку HTTP, доводить, що пересилання в інтернет працює. Ім’я, яке не розв’язується, тоді як доступ за адресою працює, — це проблема розв’язувача, а не NAT.

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

Схожі статті