Чому маршрут повного тунелю відрізає сервер, який його несе

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

Маршрут, що їсть власний транспорт

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

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

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

Установіть виняток до маршруту за замовчуванням

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

Більшість клієнтів роблять це без прохання. OpenVPN шукає віддалену адресу й закріплює її, перш ніж переписати шлюз за замовчуванням, а його параметр route-delay існує для платформ, де ця послідовність змагається. wg-quick обирає зовсім інший шлях, позначаючи пакети й звертаючись до правила політики замість додавання винятку. Різні механізми, одна вимога: зовнішній пакет мусить утекти з тунелю, який сам створює.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

Дзеркальне відображення на сервері

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

Винятки, які тунель постійно краде

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

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

Виняток, якого ніхто не записав, — це виняток, який наступна перезбірка тихо відкине.

Доведіть це після перепідключення, а не до нього

Перевірте три призначення, а не одне: кінцеву точку, приватну адресу за тунелем і публічну адресу за ним. Один успішний пошук майже нічого не каже про два інші.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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