Два шлюзи, один VPN: чому OpenVPN обирає неправильний висхідний канал

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

Адреса тунелю — не кінцева точка

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

Запис remote у профілі називає зовнішнє призначення, тож саме цю адресу треба закріпити. Це також значення, яке змінюється, коли ім'я хоста розв'язується інакше або профіль перелічує кілька remote.

Знайдіть адресу, до якої клієнт справді звертався

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

Закріпіть кінцеву точку і прочитайте порядок політики

Маршрут до хоста конкретніший за будь-який типовий маршрут. Тому /32 для адреси партнера перемагає в таблиці, яка його містить. Звичайна форма явно називає шлюз і пристрій:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

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

Коли кінцева точка переміщується

Ім'я хоста, що розв'язується в кілька адрес, робить постійний /32 недійсним, щойно відповідь змінюється. Профіль із кількома рядками remote має ту саму проблему, бо клієнт може приземлитися на будь-якому з них. Оновлюйте маршрут із власних гачків життєвого циклу клієнта, а не додавайте вручну. Скрипт up, який читає узгодженого партнера і встановлює маршрут до хоста, тримає виняток узгодженим із реальністю, а відповідний скрипт down видаляє його.

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

Тримайте внутрішню політику окремо

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

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

Підтвердьте результат двома незалежними спостереженнями: локальною адресою та пристроєм сокета і маршрутом, у який розв'язується приватне призначення. Коли обидва відповідають вашому задуму, поділ реальний. Посібник OpenVPN 2.6 описує параметри remote і локального прив'язування, які визначають, до якої адреси звертається клієнт.