Проверка порта говорит «открыт»? Почему игроки Minecraft всё равно не могут подключиться

Кто-то запускает проверку порта, видит слово открыт и считает сервер решённым. Что на самом деле означает этот результат — узко: с места проверки, в тот момент, TCP-соединение к этому адресу и порту было принято. Он ничего не говорит о рукопожатии протокола Minecraft, аутентификации аккаунта или о том, пустил ли сервер игрока в мир.

Это четыре разных слоя, и сбой на любом из них даёт от игрока одну и ту же фразу: не сработало.

Проверка тестирует только то, что видит

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

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

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

Четыре слоя между сокетом и игроком

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

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

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

Почему игрок изнутри идёт другим путём

Игрок в той же локальной сети или в VPN, который достигает этой сети, пытается достичь публичного адреса изнутри. Запрос идёт на внешний адрес маршрутизатора, и маршрутизатор должен перевести его обратно внутрь — это схема, обычно называемая hairpinning или отражением NAT. Чтобы это работало, должны совпасть и прямой перевод, и обратный путь, а многие домашние маршрутизаторы вовсе этого не реализуют.

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

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

Документация Netgate об отражении NAT подробнее описывает разницу между внешним и внутренним и альтернативу split-DNS. Читайте её как описание механизма, а не как обещание, что какой-либо конкретный провайдер VPN или маршрутизатор поддерживает каждый вариант loopback.

Собирайте доказательства с каждой точки зрения

Для каждой проверки запишите, кто её запускал, откуда, в какое время, против какого адреса и порта и что зарегистрировал сервер. Отказ игры с ясной причиной в консоли сервера — это иной вывод, чем соединение, которое так и не пришло, и эти два ведут в противоположные стороны.

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