Вкладений VPN: який тунель несе зовнішнє з'єднання?

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

Три умови вирішують вкладеність

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

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

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

Умова перша: яка кінцева точка потребує якого шляху

ip route get 203.0.113.10 відповідає на це питання безпосередньо: команда друкує маршрут, адресу джерела та інтерфейс, який ядро використало б для цього призначення просто зараз.

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

Умова друга: перегляньте шлях на кожному рівні

Вибір маршруту на сучасному клієнті — це більше, ніж головна таблиця. Правила політики можуть надсилати позначені пакети до іншої таблиці, клієнт може прив'язати свій сокет до інтерфейсу, а контейнер або простір імен має власні таблиці. ip rule і ip route show table all — це спосіб з'ясувати, який із цих механізмів задіяний.

Клієнт, який ставить SO_MARK на власний сокет або налаштований на прив'язку до конкретного пристрою, обходить маршрут за замовчуванням, який ви, як вам здавалося, налаштували. Це особливість, а не помилка, і вона означає, що єдина надійна перевірка — та, що виконується в тому самому просторі імен, що й клієнт. Якщо клієнти працюють у контейнерах, виконуйте перевірки в цих контейнерах, а не на хості.

Умова третя: що відбувається, коли зовнішній тунель падає

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

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

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

Чого ланцюг не дає

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

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