Обслуживание 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.