Если по локальной сети игроки подключаются, а извне — нет, сначала выясните, кому принадлежит внешний IPv4 и кто управляет границей сети. Правило на домашнем роутере само по себе не создаёт проброс на NAT провайдера. Переустановка игрового сервера эту границу тоже не меняет.
Речь ниже о выделенном сервере, к которому игроки обращаются напрямую. У игр со своим ретранслятором или сервисом подбора матчей маршрут может отличаться. Понадобятся доступ к статусу роутера, фактические игровые порты и игрок на другом интернет-подключении. Команда для проверки адресов приведена для Linux; на Windows сравнение WAN и внешнего адреса выполняется по той же схеме через сетевые настройки и интерфейс роутера.
Сначала проверьте рабочее подключение по LAN#
Запустите сервер, дождитесь сообщения о готовности и зайдите на его локальный адрес с другого устройства совместимым клиентом. Запишите адрес, порт и протокол. Игровой трафик, запросы браузера серверов и администрирование проверяйте отдельно: получение названия сервера ещё не доказывает возможность войти в мир.
На Linux адреса самого сервера покажет команда:
ip -4 address show
Она не показывает WAN отдельного домашнего роутера. Адрес 192.168.1.50 у сервера вполне совместим с доступом извне через правильно настроенный проброс. Закрепите этот адрес DHCP-резервированием, иначе после переподключения роутер может отправлять пакеты другому устройству.
Если не работает уже локальный вход, сначала разберите готовность игры, адрес привязки, firewall сервера и совместимость клиента. CGNAT относится к внешнему маршруту и не объясняет отказ между двумя устройствами одной доступной локальной сети. Не меняйте сразу несколько сетевых настроек: иначе не будет понятно, какое изменение повлияло на результат.
Сравните WAN роутера с внешним IPv4#
Откройте статус интернет-подключения роутера и запишите именно WAN IPv4. Затем с того же домашнего подключения узнайте исходящий публичный IPv4 через сервис проверки адреса, которому доверяете. Для сравнения отключите VPN и прокси, явно выберите IPv4 и снимите оба значения примерно одновременно.
Не сравнивайте локальный адрес сервера с адресом на сайте: они обычно различаются. В историческом обсуждении HomeNetworking участник даже исправляет свой ответ, перепутав WAN и внешний адрес. Поэтому сначала подпишите, откуда взято каждое значение, и только потом делайте вывод.
RFC 6598 выделяет для общих сетей диапазон 100.64.0.0/10: от 100.64.0.0 до 100.127.255.255. Частные диапазоны по RFC 1918 — 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Такой адрес на фактическом внешнем WAN указывает на дополнительную сетевую границу; дальше нужно определить её владельца.
Разные WAN и наблюдаемый внешний IPv4 дают основание искать трансляцию выше роутера, но сами по себе ещё не устанавливают CGNAT провайдера. Первую трансляцию может выполнять ваш модем-роутер. Совпадение адресов тоже не доказывает доступность: фильтры провайдера и локальный firewall проверяются отдельно.
Найдите, кто управляет вторым NAT#
Нарисуйте реальную цепочку: сервер, личный роутер, модем-роутер провайдера, сеть провайдера. Посмотрите WAN самого внешнего устройства, которым можете управлять. Если оба домашних устройства маршрутизируют трафик, это может быть обычный двойной NAT. Настройте проброс через обе границы либо используйте поддерживаемый режим моста или точки доступа, чтобы убрать лишний слой. Сначала проверьте инструкции оборудования: смена режима способна прервать интернет или дополнительные услуги провайдера.
Если границей управляет провайдер, спросите поддержку, используется ли CGNAT и можно ли получить доступный извне публичный IPv4 либо отдельное входящее сопоставление портов. Не рассчитывайте, что DMZ или UPnP на домашнем роутере автоматически настроит сеть оператора. Dynamic DNS меняет соответствие имени и адреса, но не прокладывает входящий маршрут через NAT.
Выберите способ доступа под конкретную игру#
Публичный IPv4 от провайдера часто даёт самую простую схему. Статический адрес необязателен: динамический тоже подходит, если игроки получают актуальное значение или корректно обновляемое DNS-имя. Уточните возможность входящего трафика и сохраните нужный игре протокол во всех правилах.
IPv6 подходит, только если его поддерживают сервер, клиент, механизм подключения игры и обе сети. Глобальному IPv6 всё равно нужны разрешения firewall. Link-local адрес не является интернет-адресом; наличие IPv6 у роутера само по себе не делает доступной игру, работающую только через IPv4.
Закрытая оверлейная сеть подходит группе, где каждый игрок может установить и использовать её клиент. Учтите ограничения консолей и поиск серверов внутри игры. Такой доступ не означает автоматического появления в публичном браузере серверов.
Для ретранслятора или удалённого сервера проверьте поддержку входящего UDP, если он нужен игре, все игровые и query-порты, регион, задержку и совместимость клиентов. Туннель только для TCP не заменяет UDP игрового сервера. Другой вариант — ваш собственный доступный извне Linux-сервер: Nexardo помогает управлять своей инфраструктурой, а её сетевая доступность по-прежнему зависит от узла и провайдера.
Повторите внешний вход и сохраните результаты#
После изменения попросите игрока вне домашней сети подключиться к тому адресу и порту, которые собираетесь сообщать остальным. Проверка своего публичного адреса из собственной LAN зависит от поддержки loopback на роутере и не заменяет внешний тест.
Сохраните время готовности сервера, сравнение WAN, ответ провайдера, необходимые UDP/TCP-сопоставления и результат входа. Если проблема осталась, переходите к диагностике UDP, а не открывайте случайные порты. Завершённая проверка — это игрок на нужном сервере через выбранный маршрут. Получение публичного адреса остаётся промежуточным шагом.
