Sprawdzanie portów mówi otwarty? Dlaczego gracze Minecrafta nadal nie mogą dołączyć

Ktoś uruchamia sprawdzenie portu, widzi słowo otwarty i uznaje serwer za rozwiązany. To, co ten wynik naprawdę oznacza, jest wąskie: z miejsca sprawdzającego, w tej chwili, połączenie TCP na ten adres i ten port zostało przyjęte. Nie mówi nic o uzgadnianiu protokołu Minecraft, uwierzytelnianiu konta ani o tym, czy serwer wpuścił gracza do świata.

To cztery różne warstwy i awaria w którejkolwiek z nich daje graczowi to samo zdanie: nie zadziałało.

Sonda sprawdza tylko to, co widzi

Połączenie TCP kończy się, gdy obie strony zakończą trójstopniowe uzgadnianie, które leży poniżej wszystkiego, co zna gra. Sonda zgłasza, że istniał nasłuchujący i odpowiedział ze swojej lokalizacji sieciowej. Nie może powiedzieć, że nasłuchującym jest gra, bo dowolny proces może zająć port i przyjmować połączenia.

Lokalizacja ma takie samo znaczenie jak wynik. Sprawdzanie w publicznym internecie testuje jedną ścieżkę z jednej sieci. Sprawdzanie uruchamiane przez operatora od wewnątrz tej samej sieci testuje zupełnie inną ścieżkę, a pozytywny wynik tam prawie nic nie mówi o tym, czego doświadcza zdalny gracz. Dwa różne sprawdzenia u dwóch różnych dostawców mogą nawet się nie zgadzać z powodów, które nie mają nic wspólnego z twoim serwerem.

Znaczenie ma też czas. Wynik sondy opisuje moment, w którym została uruchomiona, a połączenie domowe z dynamicznym adresem lub zmienioną regułą przekierowania może przesunąć prawdziwą odpowiedź kilka minut później. Zapisz publiczny adres, port, rodzinę adresów i czas razem z werdyktem, inaczej obserwacji nie można powtórzyć. Powtórz sprawdzenie z naprawdę innej sieci, a nie z telefonu na tym samym łączu.

Cztery warstwy między socketem a graczem

Wyobraź sobie sekwencję, którą faktycznie wykonuje dołączający klient. Najpierw rozwiązuje adres, potem otwiera połączenie TCP do opublikowanego portu, potem mówi własnym protokołem gry, aby wynegocjować i uwierzytelnić, a na końcu serwer decyduje, czy ta tożsamość może wejść do świata. Każda warstwa ma własny podpis awarii, a tylko pierwsza jest widoczna dla sprawdzania portów.

Domyślny port Java Edition to 25565, ale operator może opublikować inny port zewnętrzny i przekierować go do środka, więc numer wpisany przez gracza nie musi być numerem, który widzi serwer. Sprawdzanie skierowane na zły port zewnętrzny zgłasza zamknięty, choć serwer jest całkowicie zdrowy, i to najczęstszy fałszywy alarm w całej tej dziedzinie.

Nazwy dodają jeszcze jeden krok nad portem. Jeśli gracz wpisze nazwę hosta, rozwiązywanie musi zwrócić opublikowany adres, a na maszynie wewnątrz sieci może zwrócić prywatny. To nie jest awaria firewalla i żadna ilość przekierowania portów tego nie zmieni.

Dlaczego gracz wewnątrz idzie inną ścieżką

Gracz w tej samej sieci LAN lub w VPN, który dociera do tej sieci, próbuje osiągnąć publiczny adres od środka. Żądanie idzie na zewnętrzny adres routera, a router musi przetłumaczyć je z powrotem do środka, co zwykle nazywa się hairpinningiem lub odbiciem NAT. Aby to działało, zarówno tłumaczenie w przód, jak i ścieżka powrotna muszą się zgadzać, a wiele routerów domowych w ogóle tego nie implementuje.

Dlatego gość z zewnątrz dołącza, a osoba siedząca obok serwera nie może. Ścieżka zewnętrzna jest naprawdę w porządku; zawodzi wewnętrzne obejście i zawodzi tak, że z ekranu gracza wygląda to na problem serwera. Sam log serwera rozstrzyga, co się stało, bo połączenie, które nigdy nie zostało przetłumaczone, nigdy do niego nie dociera.

Są dwa uczciwe rozwiązania i jeden zły nawyk. Dobre opcje to pozwolić wewnętrznym graczom używać adresu prywatnego lub nazwy split-DNS, która wewnętrznie rozwiązuje się na adres prywatny, albo włączyć odbicie na routerze, jeśli funkcja istnieje i działa poprawnie. Zły nawyk to otwieranie kolejnych portów lub wyłączanie firewalla hosta, co nie może wpłynąć na tłumaczenie, którego router nigdy nie wykonał.

Dokumentacja Netgate o odbiciu NAT szczegółowiej opisuje różnicę między zewnętrzem a wnętrzem oraz alternatywę split-DNS. Czytaj ją jako opis mechanizmu, a nie obietnicę, że konkretny dostawca VPN lub router obsługuje każdy wariant loopback.

Zbieraj dowody z każdego punktu widzenia

Przy każdym teście zapisz, kto go uruchomił, skąd, o której godzinie, przeciw jakiemu adresowi i portowi oraz co zalogował serwer. Odrzucenie przez grę z jasnym powodem w konsoli serwera to inne ustalenie niż połączenie, które nigdy nie dotarło, i oba prowadzą w przeciwnych kierunkach.

Jeśli dozwoleni zdalni gracze dołączają, a jeden lokalny gracz nie może, pozostałym pytaniem jest ścieżka lokalna i zasługuje ona na własne dochodzenie: jakiego adresu użył klient, co router zrobił z tłumaczeniem i czy serwer w ogóle zarejestrował jakąkolwiek próbę połączenia. Przekaż te trzy fakty właścicielowi sieci, zamiast otwierać porty na chybił trafił.