Сервер і клієнт OpenVPN на одному хості: чому клієнти відпадають

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

Одна машина, дві ролі й дві несумісні відповіді на питання, куди мають іти відповіді.

Той самий пул, два сервери: хто перемагає

Кожному екземпляру сервера потрібна власна підмережа тунелю. Копіювання рядка на кшталт server 10.8.0.0 255.255.255.0 у другу конфігурацію дає двом екземплярам той самий префікс, і підсумок — або відмова запускатися, або тиха боротьба, у якій клієнти одного сервера отримують адреси, які інший теж вважає своїми. Різні UDP-порти й різні імена пристроїв не допомагають, бо ні те ні те не зачіпає адресний простір. Змініть другий пул і змініть його всюди, де маршрути про нього згадують.

Перелічіть, що вже працює, перед редагуванням: ip -4 addr show показує тунельні пристрої, ss -lunp показує слухачів, а systemctl list-units називає юніти. Одного погляду на адреси тунелів достатньо, щоб вирішити, чи перетинаються пули.

Що клієнтський профіль додає до таблиці

Клієнтська половина записує маршрути щойно підключається. redirect-gateway def1 ділить маршрут за замовчуванням на 0.0.0.0/1 плюс 128.0.0.0/1, обидва йдуть через новий пристрій, разом із маршрутом до хоста віддаленого сервера, навмисно прикріпленим до фізичного інтерфейсу. Це прикріплення потрібне, щоб тунель зберігав шлях для власного транспорту. Усе інше, включно з відповідями, які локальний сервер винен своїм клієнтам, тепер іде новим маршрутом за замовчуванням і виходить через віддалений канал.

Отже, друга колізія — не зламаний тунель. Це робочий тунель не на своєму місці в таблиці.

Три способи розвести ролі

Найменш інвазивне виправлення прибирає маршрут за замовчуванням із клієнтського профілю: route-nopull плюс явні рядки route для віддалених префіксів, тож локальна таблиця змінюється лише там, де ви просили. Наступний крок — правило політики, яке звільняє локальну підмережу тунелю: відповіді локальним клієнтам виходять через той інтерфейс, яким прийшли, навіть коли є маршрут за замовчуванням. Найґрунтовніше — окремий мережевий простір імен для клієнтської ролі: він повністю прибирає спільну таблицю, але потребує другого контексту маршрутизації в обслуговуванні.

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

Котрий із двох екземплярів винен

Зупиніть клієнтський екземпляр і перевірте початкових клієнтів ще раз. Миттєве відновлення означає маршрутизацію, а не сервер. Поверніть клієнт і простежте одну відповідь за допомогою ip route get, якому задано і адресу джерела, і адресу призначення: він показує шлях, який обере ядро, після чого подивіться на інтерфейс, який пакети реально використовують, за допомогою tcpdump -ni any port 1194. Файл стану сервера, який записується кожні кілька секунд через директиву status, містить список підключених клієнтів і лічильники байтів в обидва боки.

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