proto udp или tcp-client: какой из них слышит ваш сервер?

Профиль, который работал в прошлом месяце, теперь завершается по тайм-ауту, и кто-то предлагает заменить proto udp на proto tcp-client. Иногда это правильный шаг, а иногда получается клиент, подключающийся к порту, где ничего не слушает, потому что сервер никогда не настраивался на другой транспорт. Директива описывает, как говорит ваша сторона; она не может создать слушателя на другой стороне. Прочитайте профиль и сервер вместе, прежде чем менять что-либо из них.

Прочитайте транспорт, который использует выбранное соединение

Профиль может содержать несколько записей remote, и каждая может указывать собственный транспорт. Клиент перебирает их по порядку, поэтому строка, которую вы видите первой, не обязательно применяется.

Найдите запись, которая действительно пытается использоваться, затем прочитайте её транспорт. Порядок важен, потому что клиент не переходит к следующей молча. Некоторые сборки пробуют следующую запись только после тайм-аута, поэтому рабочая альтернатива внизу файла достигается на несколько секунд позже, чем вы ожидаете. Следите в журнале за тем, какая конечная точка пытается использоваться, а не предполагайте, что победила первая строка.

Если в файле есть одна строка proto ближе к началу и несколько записей remote ниже, эта строка является значением по умолчанию для любого remote, который её не переопределяет. Локальная правка значения по умолчанию ничего не делает для записи remote, которая указывает собственный транспорт.

grep -nE '^(remote|proto)\b' client.ovpn

UDP и TCP — не настройка скорости

UDP отправляет датаграммы, не строя упорядоченный поток, поэтому собственный трафик туннеля не заворачивается во второй надёжный транспорт. TCP даёт путь через сети, которые отбрасывают или блокируют UDP, ценой вложенной повторной передачи, которая может сделать соединение с потерями хуже на ощупь.

Это компромисс по достижимости, а не универсальный рейтинг. Правильный выбор — тот, который допускает сеть перед клиентом. Путь, отбрасывающий UDP на порту VPN, никогда не договорится, как бы хорошо ни был написан профиль. Проверьте путь, затем выберите транспорт.

Выбирать между ними только по замеру — ошибка, потому что ответ зависит от того, что допускает сеть перед вами. Отель или корпоративный прокси может разрешать только исходящий TCP на 443 и ничего больше, поэтому провайдеры предлагают такой вариант. Это по-прежнему соединение OpenVPN на этом порту, а не сеанс HTTPS, хотя номер порта знаком.

Что на самом деле означает tcp-client

Директива на стороне клиента называет инициирующий конец TCP-соединения. Серверная сторона использует свою форму прослушивания, и копирование слова клиента в конфигурацию сервера создаёт слушателя, который ожидает входящего вызова, а не тот, который принимает.

Совпадение означает, что обе стороны договариваются о транспорте, а не то, что они используют одну и ту же строку.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Спросите сервер, что он слушает, прежде чем считать профиль неверным. Слушатель UDP не появляется в списке TCP-сокетов, и обратное тоже верно, поэтому смотрите представление, специфичное для протокола, а не общее.

Когда профиль импортируется, но никогда не подключается

Импортированный профиль, который сразу завершается по тайм-ауту, обычно терпит неудачу ещё до любой аутентификации. Пакет уходит на порт без слушателя, или сеть молча его отбрасывает.

Проверьте путь самым простым способом: подключитесь к тому же хосту и порту с транспортом, который заявляет профиль, из той же сети, что и сбойный клиент.

Если проверка UDP ничего не получает, а проверка TCP подключается, сервер предлагает другой транспорт, и профиль просто устарел. Если не отвечает ни одна, проблема выше выбора транспорта, и никакая правка профиля её не исправит. Различение этих двух случаев занимает минуту и экономит час отладки сертификатов, который никогда не был уместен.

Запишите работающий транспорт

Как только комбинация заработает, запишите её вместе с сервером, портом и протоколом и отметьте, из какой сети она проверялась.

Иначе следующий человек, столкнувшийся с тайм-аутом, повторит тот же эксперимент в обратную сторону и, возможно, изменит сервер, который был в порядке.

Если провайдер публикует оба варианта, сохраните оба файла и обозначьте их по сети, для которой они подходят. Два явно названных профиля предотвращают случайное смешивание клиентского транспорта с серверным слушателем, который никогда для него не настраивался.