Portchecker sagt offen? Warum Minecraft-Spieler trotzdem nicht beitreten können

Jemand lässt einen Portcheck laufen, sieht das Wort offen und hält den Server für gelöst. Was dieses Ergebnis tatsächlich bedeutet, ist eng: Vom Standort des Prüfers aus wurde in diesem Moment eine TCP-Verbindung zu dieser Adresse und diesem Port angenommen. Es sagt nichts über den Handshake des Minecraft-Protokolls, die Kontobestätigung oder darüber aus, ob der Server den Spieler in eine Welt gelassen hat.

Das sind vier verschiedene Schichten, und ein Fehler in jeder von ihnen erzeugt beim Spieler denselben Satz: es hat nicht funktioniert.

Eine Sonde prüft nur, was sie sehen kann

Eine TCP-Verbindung kommt zustande, wenn beide Seiten den Drei-Wege-Handshake abschließen, der unter allem liegt, was das Spiel weiß. Die Sonde meldet, dass ein Listener existierte und von ihrem Netzwerkstandort aus geantwortet hat. Sie kann dir nicht sagen, dass der Listener das Spiel ist, weil jeder Prozess einen Port binden und Verbindungen annehmen kann.

Der Standort zählt genauso viel wie das Ergebnis. Ein Prüfer im öffentlichen Internet testet einen Weg aus einem Netz. Ein Prüfer, den der Betreiber von innerhalb desselben Netzes startet, testet einen völlig anderen Weg, und ein positives Ergebnis dort sagt fast nichts darüber aus, was ein entfernter Spieler erlebt. Zwei verschiedene Prüfer bei zwei verschiedenen Anbietern können sich sogar aus Gründen widersprechen, die nichts mit deinem Server zu tun haben.

Auch der Zeitpunkt zählt. Ein Sondenergebnis beschreibt den Moment, in dem es lief, und ein Heimanschluss mit dynamischer Adresse oder einer geänderten Weiterleitungsregel kann die echte Antwort ein paar Minuten später verschieben. Notiere die öffentliche Adresse, den Port, die Adressfamilie und die Uhrzeit zusammen mit dem Urteil, sonst ist die Beobachtung nicht reproduzierbar. Wiederhole die Prüfung aus einem wirklich anderen Netz statt von einem Telefon am selben Anschluss.

Vier Schichten zwischen einem Socket und einem Spieler

Stell dir die Reihenfolge vor, die ein beitretender Client tatsächlich ausführt. Zuerst löst er die Adresse auf, dann öffnet er eine TCP-Verbindung zum veröffentlichten Port, dann spricht er das eigene Protokoll des Spiels, um auszuhandeln und sich zu authentifizieren, und schließlich entscheidet der Server, ob diese Identität in die Welt darf. Jede Schicht hat ihre eigene Fehlersignatur, und nur die erste ist für einen Portchecker sichtbar.

Der Standardport der Java Edition ist 25565, aber der Betreiber kann einen anderen externen Port veröffentlichen und ihn nach innen weiterleiten, sodass die Zahl, die ein Spieler eintippt, nicht unbedingt die Zahl ist, die der Server sieht. Ein Prüfer, der auf den falschen externen Port zielt, meldet geschlossen, während der Server völlig gesund ist, und das ist der häufigste Fehlalarm in diesem ganzen Bereich.

Namen fügen einen weiteren Schritt über dem Port hinzu. Tippt ein Spieler einen Hostnamen ein, muss die Auflösung die veröffentlichte Adresse zurückgeben, und auf einem Rechner innerhalb des Netzes kann sie stattdessen eine private zurückgeben. Das ist kein Firewallfehler, und keine Menge an Portweiterleitung wird das ändern.

Warum der Spieler drinnen einen anderen Weg nimmt

Ein Spieler im selben LAN oder in einem VPN, das dieses LAN erreicht, versucht, die öffentliche Adresse von innen zu erreichen. Die Anfrage geht an die externe Adresse des Routers, und der Router muss sie zurück nach innen übersetzen, was gewöhnlich Hairpinning oder NAT-Reflexion genannt wird. Sowohl die Hinübersetzung als auch der Rückweg müssen zusammenpassen, damit das funktioniert, und viele Consumer-Router implementieren es überhaupt nicht.

Deshalb kommt der Gast von außen rein, während die Person neben dem Server es nicht kann. Der externe Weg ist wirklich in Ordnung; die interne Umleitung ist das, was scheitert, und sie scheitert so, dass es auf dem Bildschirm des Spielers wie ein Serverproblem aussieht. Das eigene Log des Servers entscheidet, was passiert ist, denn eine Verbindung, die nie übersetzt wurde, erreicht ihn nie.

Es gibt zwei ehrliche Korrekturen und eine schlechte Angewohnheit. Die guten Optionen sind, interne Spieler die private Adresse oder einen Split-DNS-Namen verwenden zu lassen, der intern auf die private Adresse auflöst, oder die Reflexion am Router zu aktivieren, wenn die Funktion existiert und sich richtig verhält. Die schlechte Angewohnheit ist, weitere Ports zu öffnen oder die Host-Firewall abzuschalten, was eine Übersetzung nicht beeinflussen kann, die der Router nie vorgenommen hat.

Die Netgate-Dokumentation zur NAT-Reflexion beschreibt den Unterschied zwischen außen und innen und die Split-DNS-Alternative ausführlicher. Lies sie als Beschreibung des Mechanismus und nicht als Versprechen, dass ein bestimmter VPN-Anbieter oder Router jede Loopback-Variante unterstützt.

Sammle Belege aus jeder Sicht

Notiere zu jedem Test, wer ihn ausgeführt hat, von wo, zu welcher Zeit, gegen welche Adresse und welchen Port, und was der Server protokolliert hat. Eine Spielablehnung mit klarem Grund in der Serverkonsole ist ein anderer Befund als eine Verbindung, die nie ankam, und die beiden weisen in entgegengesetzte Richtungen.

Wenn zugelassene entfernte Spieler beitreten und ein lokaler Spieler nicht, ist der lokale Weg die verbleibende Frage, und er verdient eine eigene Untersuchung: welche Adresse der Client verwendet hat, was der Router mit der Übersetzung gemacht hat und ob der Server überhaupt einen Verbindungsversuch verzeichnet hat. Gib diese drei Fakten an denjenigen weiter, dem das Netz gehört, statt Ports auf gut Glück erneut zu öffnen.