Minecraft через VPN: какой адрес писать в списке серверов?

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

Два адреса, две задачи

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

С портом по умолчанию игрок вводит 10.60.0.20:25565 и больше ничего. Страница загрузки Java-сервера Mojang указывает 25565 как порт по умолчанию, и оператору, который сменил порт, нужно верить, а не сомневаться в нём по старому руководству.

Сделайте этот адрес настоящим сервисом

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

Убедитесь в слушателе, прежде чем трогать межсетевой экран:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Первая строка показывает, к чему процесс действительно привязан, а вторая — может ли узел завершить рукопожатие TCP. Когда привязка — 127.0.0.1, никакой объём настройки VPN не меняет результат, и именно эта деталь объясняет удивительно много сообщений «VPN сломан».

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

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

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

Когда сервер стоит за шлюзом

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

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

Обнаружение, учётные записи и что не менять

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

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