Обслуговування OpenVPN через TCP і UDP з одного хоста
Один процес до 2.7 прив'язує один транспорт. Порівняйте з'єднану мостом пару TAP, дві підмережі TUN і спільний пул, а потім зіставте кожен профіль із його слухачем.
Мережі, що дозволяють лише TCP 443, співіснують із мережами, які без проблем пропускають UDP, і один сервер має обслуговувати обидві. Профіль із proto udp відповідає другій групі й зазнає невдачі в першій, а редагування тієї ж конфігурації на proto tcp не створює другого слухача. Директива вибирає один транспорт для одного процесу. Усе інше випливає з цього обмеження.
Або ви запускаєте більше одного процесу, або запускаєте версію, яка вміє прив'язувати кілька сокетів одночасно.
Один процес до 2.7 прив'язує один транспорт
OpenVPN зі спільноти прив'язує сокет, який описує proto, і ця директива вибирає один транспорт для екземпляра. TCP і UDP — різні стеки, тому той самий номер порту можуть займати обидва одночасно, але не один процес. Тому гілка 2.6 дає один транспорт на демон. OpenVPN 2.7 зняв це обмеження для серверів, які можуть прив'язувати кілька сокетів через кілька інструкцій --local в одному процесі.
Перевірте версію, перш ніж проєктувати під будь-яку з відповідей, бо схема 2.7 — це інша операційна модель із власним синтаксисом конфігурації. Посібник, написаний для 2.6, описує два процеси, навіть коли не каже про це.
Три способи запустити два екземпляри
З інтерфейсами TAP запустіть по одному екземпляру на транспорт і з'єднайте два пристрої tap мостом на хості. Обидві групи клієнтів опиняються в одному домені широкомовлення, що дає змогу одному пулу адрес їх покрити й зберігає роботу протоколів, залежних від широкомовлення. З TUN міст недоступний, тому найпростіший поділ дає кожному екземпляру власну підмережу, а маршрутизація тримає дві групи клієнтів окремо. Третій варіант зберігає один пул, змушуючи кожен екземпляр викликати скрипт learn-address, який встановлює маршрут /32 для клієнта через пристрій цього екземпляра.
Саме цю третю схему люди й просять, і саме вона потребує найбільшої обережності, бо скрипт стає частиною шляху даних і мусить правильно обробляти події додавання, оновлення та видалення.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Тримайте два екземпляри окремо
Кожному екземпляру також потрібен окремий порт або адреса, окремий файл стану й окреме місце для журналу. Два демони, що пишуть в один файл стану, дають вивід, який неможливо прочитати під час інциденту, а потрібен він саме тоді. Якщо другий екземпляр прив'язує конкретну адресу, ця адреса має існувати на хості на момент запуску процесу; інакше він завершується з помилкою прив'язки, не сказавши нічого про ключі.
Називайте юніти й профілі так, щоб транспорт було видно з назви файлу. Наступний оператор не повинен відкривати конфігурацію, щоб дізнатися, котрий із них TCP.
Зіставте профіль зі слухачем
Сервер, що запускає proto tcp, очікує клієнтський профіль із proto tcp-client, а профіль, який досі містить proto udp, проти цього слухача завершується за тайм-аутом без помилки, з якою користувач міг би щось зробити. Тримайте два профілі, якщо розгортання пропонує обидва транспорти, і позначайте їх так, щоб підтримка знала, який пробували. Саме лише число порту не описує транспорт.
Правила брандмауера підкоряються тому ж поділу: правило для UDP 1194 нічого не каже про TCP 1194, а правило для однієї адреси не покриває інший слухач.
Спершу прочитайте картину сервера
Почніть із ss -lntup на сервері й переконайтеся, що видно і TCP-, і UDP-слухач. Потім підключіть по одному клієнту кожного типу й перевірте вивід стану щодо двох записів із різними адресами. Якщо сокети існують, а клієнт не приходить, шлях або брандмауер відхиляють пакети раніше, ніж їх побачить демон.
Сокет, який так і не з'явився, — це проблема конфігурації або прив'язки, а сокет, який з'явився, але жодного разу не зафіксував з'єднання, — проблема фільтрації. З боку клієнта обидва виглядають однаково, тому картина самого сервера йде першою. Зважте, що TCP несе блокування початку черги, тож пропонувати його — це захід доступності, а не покращення для клієнтів із чистим шляхом UDP.