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

Хтось запускає перевірку порту, бачить слово відкрито і вважає сервер вирішеним. Що насправді означає цей результат — вузько: з місця перевірки, у той момент, TCP-з'єднання до цієї адреси й порту було прийнято. Він нічого не каже про рукостискання протоколу Minecraft, автентифікацію облікового запису чи про те, чи пустив сервер гравця у світ.

Це чотири різні шари, і збій на будь-якому з них дає від гравця ту саму фразу: не спрацювало.

Перевірка тестує лише те, що бачить

TCP-з'єднання завершується, коли обидві сторони закінчують тристороннє рукостискання, яке лежить нижче всього, що знає гра. Перевірка повідомляє, що слухач існував і відповів зі своєї мережевої позиції. Вона не може сказати, що слухач — це гра, бо будь-який процес може зайняти порт і приймати з'єднання.

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

Час теж важливий. Результат перевірки описує момент, коли вона виконувалася, а домашнє підключення з динамічною адресою або зміненим правилом переадресації може зсунути справжню відповідь на кілька хвилин пізніше. Запишіть публічну адресу, порт, родину адрес і час разом із вердиктом, інакше спостереження не можна відтворити. Повторіть перевірку з дійсно іншої мережі, а не з телефона на тому самому підключенні.

Чотири шари між сокетом і гравцем

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

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

Імена додають ще один крок над портом. Якщо гравець вводить ім'я хоста, розв'язання має повернути опубліковану адресу, а на машині всередині мережі воно може повернути натомість приватну. Це не збій брандмауера, і жодна кількість переадресації портів цього не змінить.

Чому гравець зсередини йде іншим шляхом

Гравець у тій самій локальній мережі або у VPN, що досягає цієї мережі, намагається досягти публічної адреси зсередини. Запит іде на зовнішню адресу маршрутизатора, і маршрутизатор має перекласти його назад усередину — це схема, яку зазвичай називають hairpinning або відображенням NAT. Щоб це працювало, мають збігтися і прямий переклад, і зворотний шлях, а багато домашніх маршрутизаторів цього взагалі не реалізують.

Тому гість ззовні підключається, а людина, що сидить поруч із сервером, не може. Зовнішній шлях справді гаразд; збій дає внутрішній об'їзд, і він виглядає з екрана гравця як проблема сервера. Власний журнал сервера вирішує, що саме сталося, бо з'єднання, яке ніколи не перекладалося, до нього не доходить.

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

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

Збирайте докази з кожного погляду

Для кожної перевірки запишіть, хто її запускав, звідки, о котрій годині, проти якої адреси й порту, і що зафіксував сервер. Відмова гри з ясною причиною в консолі сервера — це інший висновок, ніж з'єднання, яке так і не надійшло, і ці два ведуть у протилежні боки.

Якщо дозволені віддалені гравці підключаються, а один локальний гравець не може, залишкове питання — локальний шлях, і він заслуговує окремого розслідування: яку адресу використав клієнт, що маршрутизатор зробив із перекладом і чи зафіксував сервер хоч якусь спробу з'єднання. Передайте ці три факти власникові мережі, замість того щоб навмання відкривати порти.