Пустой список игр LAN через OpenVPN? Проверьте путь обнаружения

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

Отделите подключение к сеансу от его поиска

Неудачное подключение указывает на маршруты, правила брандмауэра и службу, которая слушает. Успешное подключение с пустым списком указывает на обнаружение или на адрес, который несёт объявление. Эти два результата ведут к совершенно разной работе, и различить их можно, только сознательно попробовав первое.

Запишите результат, прежде чем трогать конфигурацию VPN. Это самый дешёвый тест во всём расследовании, и он отсекает половину пространства решений. Запишите и адрес, который использовали, потому что он станет точкой отсчёта для каждого следующего теста. Без этой строки в заметках следующее сравнение — догадка.

Проверьте прямое подключение, прежде чем трогать туннель

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

Не предполагайте, что порт обнаружения и порт сеанса — одно и то же число. Игры обычно объявляют на одном порту UDP и принимают игроков на другом, а релей, построенный для неправильного, даёт список, который всё равно остаётся пустым.

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

Поймите, где заканчивается широковещание

Маршрутизированный туннель TUN переносит IP-пакеты между узлами и не воспроизводит локальное широковещание в сети каждого узла. Ограниченный широковещательный адрес 255.255.255.255 остаётся внутри интерфейса, который его выпускает, а широковещание, направленное на подсеть, — отдельный случай, а не общая лицензия для маршрутизаторов заливать объявления.

Это свойство проекта, а не дефект, который латают опцией. OpenVPN и его client-to-client настройка управляет трафиком между узлами внутри туннеля и не является релеем обнаружения, хотя во многих обсуждениях её предлагают именно для этого. Релей — отдельный компонент со своей конфигурацией и своими режимами отказа. Предположение, что существующая опция уже это покрывает, — самая частая причина, по которой расследование застревает.

Обнаружение через multicast имеет ту же проблему с другим классом адресов, и ему нужна маршрутизация multicast или релей, а не исключение для широковещания.

Когда релей оправдан, держите его узким

Если автоматическое обнаружение — требование, сначала определите фактический обмен: широковещание или multicast, адрес назначения, порт UDP, интерфейс, который его отправляет, и адрес внутри ответа. Релей, соответствующий протоколу и ограниченный этими пятью фактами, гораздо уже, чем расширение целого сегмента Ethernet.

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

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

Мост только тогда, когда проект требует Ethernet

Кадры Ethernet идут внутри TAP, поэтому туннель TAP может принадлежать намеренно смостованному широковещательному домену. Простая замена dev tun на dev tap не строит этот мост, не делает конфигурацию сервера совместимой и не заставляет приложение выбрать новый интерфейс. Руководство OpenVPN по мостам описывает более широкую схему, а не лекарство для одного пустого лобби.

Мостование также выравнивает план адресов, поэтому решение заслуживает причины больше, чем нетерпение. Две сети, которые были раздельными, становятся одной, и каждая служба с обеих сторон начинает видеть широковещательные пакеты другой стороны. Это следствие должно попасть в журнал изменений, прежде чем кто-то это включит. Нет правила, что клиенты игр обязаны находиться в диапазоне 192.168; выберите план без пересечений и проверьте ограничения конкретной игры, вместо того чтобы перенумеровывать туннель, потому что так сделал пост на форуме.

В конце держите два результата раздельно: можно ли подключиться к хосту и объявляет ли ответ обнаружения адрес, который другой игрок действительно может использовать. Исправление второго без подтверждения первого — это путь, которым люди в итоге поддерживают мост для проблемы, которая никогда не была про широковещание.