FFXIV Proxy: Warum unterscheiden sich Launcher und Spiel-Client?

FFXIV wirkt wie ein einzelnes Programm, besteht aber aus zwei getrennten Komponenten. Die erste ist der Launcher, der den Anmeldebildschirm und die Ankündigungsseite anzeigt; diese Komponente betreibt intern eine eingebettete Webansicht und liest in vielen Setups die Proxy-Einstellung des Betriebssystems. Die zweite ist der Spiel-Client, der sich mit der Welt verbindet; er öffnet eigene Sockets und weiß nichts von den Einstellungen auf Web-Seite.

Dieser Unterschied ist die Ursache der widersprüchlichen Berichte, die man in Foren häufig sieht. Auf derselben Maschine und mit derselben Einstellung sagt der eine „es funktioniert“, der andere „nichts hat sich geändert“; beide haben recht, weil beide auf unterschiedliche Komponenten schauen. Jeder Kommentar ohne Messung des Geltungsbereichs bleibt unvollständig.

Im Folgenden wird zuerst das Netzwerkverhalten dieser beiden Komponenten getrennt, danach werden die UDP-Seite, die Peer-to-Peer-Debatte, die Rechenzentrumswahl und die Volumenplanung behandelt. Für den allgemeinen Rahmen dieses Genres liefert der Beitrag Proxy-Nutzung in MMORPG-Spielen den Hintergrund.

Wie unterscheiden sich Launcher und Spiel-Client im Netzwerk?

Der Ankündigungsbereich und das Anmeldeformular, die Sie beim Öffnen des Launchers sehen, sind Webseiten; die Komponente rendert sie mit einer eingebetteten Browser-Engine. Da diese Engine die Proxy-Konfiguration des Systems auslesen kann, wirkt sich Ihre Einstellung hier sofort aus. Daraus zu schließen, „der Proxy funktioniert“, weil sich die Seite öffnet, ist daher irreführend: Was Sie sehen, ist lediglich, dass die Web-Ebene umgeleitet wird.

Der Patch-Download ist ein separater Vorgang. Versionsdateien werden per HTTP von Verteilungsservern geladen und liegen volumenmäßig um ein Vielfaches über der Spiel-Session. Danach kommt der Spiel-Client ins Spiel: Zuerst baut er eine TCP-Session mit der Lobby- und Authentifizierungsseite auf, dann mit dem Server der gewählten Welt. Der Client öffnet diese Sessions über rohe Sockets; er stellt keine Web-Anfrage und beachtet keine Browsereinstellungen.

Wenn Sie die Umleitung also auch auf Client-Seite wollen, müssen Sie die Lösung außerhalb der Web-Ebene suchen: entweder eine Umleitung auf Betriebssystemebene oder eine Hilfsschicht, die den Spielprozess über einen SOCKS5-Ausgang führt. Andernfalls geht der Launcher den einen und das Spiel den anderen Weg – und das geschieht stillschweigend; Sie erhalten keinerlei Warnung.

Welche Ports werden verwendet?

In der Herstellerdokumentation werden für die Spielverbindung hohe TCP-Bereiche wie 54992–54994 und 55006–55007 sowie 80 und 443 für Patches und Webinhalte genannt. In Netzwerken, in denen nur die Standard-Webports offen sind, öffnet sich der Launcher, das Spiel kann sich aber nicht verbinden. Dieses Problem ist nicht mit einem Proxy, sondern über die Netzwerkrichtlinie zu lösen.

Was bietet die UDP-Seite von SOCKS5, und was bedeutet sie hier?

SOCKS5 ist ein Protokoll, das neben TCP auch UDP transportieren kann. Es tut dies mit dem Befehl UDP ASSOCIATE : Der Client öffnet eine Steuerverbindung zum Proxy, der Proxy weist einen temporären UDP-Endpoint zu, und die Datagramme laufen über diesen Endpoint hin und zurück. Dieser auf dem Papier saubere Mechanismus hat in der Praxis drei Grenzen (ausführliche Darstellung).

Die erste Grenze liegt beim Anbieter: Viele kommerzielle Ausgänge öffnen nur TCP und unterstützen UDP ASSOCIATE nicht. Die zweite liegt beim Client; dass eine Anwendung SOCKS5 unterstützt, bedeutet nicht automatisch, dass sie UDP unterstützt – die meisten Clients implementieren nur den TCP-Teil. Die dritte liegt beim Netzwerk: dazwischenliegende NATs und Firewalls können den temporären UDP-Endpoint blockieren. Unterschied zwischen SOCKS4 und SOCKS5 zeigt, woher diese Fähigkeit stammt.

Für FFXIV gibt es eine gute Nachricht: Der Gameplay-Traffic des Spiels läuft über TCP, und das Spiel selbst enthält keinen Voice-Chat. Die Unterstützung von UDP ASSOCIATE ist für dieses Spiel also keine Voraussetzung. Ein UDP-Bedarf entsteht durch externe Voice-Chat-Anwendungen, die Sie nebenher betreiben, und diese nutzen meist ihre eigenen Netzwerk-Stacks.

Das vereinfacht die Einrichtung: Ein schlichter SOCKS5-Ausgang, der TCP transportiert, deckt den Bedarf des Spiels ab. Den Voice-Chat außerhalb des Geltungsbereichs zu lassen, statt ihn in denselben Tunnel zu zwingen, erzeugt weniger Störungen und beeinträchtigt die Sprachqualität nicht.

Passt die Debatte um Peer-to-Peer und NAT-Typ hierher?

Aus Gewohnheit von Konsolenspielen prüfen viele Spieler zuerst den NAT-Typ. Dieses Kriterium ist für Peer-to-Peer-Architekturen (P2P) sinnvoll, in denen sich Spieler direkt miteinander verbinden: Befinden sich beide Seiten hinter NAT, ist für den Verbindungsaufbau Hole Punching nötig, und das gelingt nicht immer. Die Zusammenfassung des Mechanismus Unterschied zwischen Proxy und NAT .

FFXIV gehört nicht in diese Kategorie. Das Spiel arbeitet vollständig nach der Client-Server-Architektur: Ihr Client verbindet sich nur mit den Servern des Herstellers und baut keine direkte Session zum Rechner eines anderen Spielers auf. Daher sind NAT-Typ, offene Ports oder Portweiterleitungen im Router nicht die Ursache von Verbindungsproblemen bei diesem Spiel.

Die praktische Konsequenz für den Proxy-Einsatz ist wertvoll. In Peer-to-Peer-Spielen kann ein Proxy den Weg unterbrechen, über den die Gegenseite Sie erreichen muss, und damit die Verbindung stören; in einer Client-Server-Architektur besteht dieses Risiko nicht, weil immer Sie die Verbindung initiieren und immer nur ein Ziel ansteuern. Die Aufgabe des Proxys beschränkt sich in diesem Spiel darauf, den Ausgangspunkt der ausgehenden Verbindung zu verändern.

Ein Hinweis ist dennoch nötig: Bei einem Heimanschluss hinter CGNAT laufen ausgehende Verbindungen auch ohne Proxy über ein Carrier-NAT. Diese Ebene verhindert den Betrieb des Spiels nicht, kann aber bei der Fehlersuche die Frage verwirren, welche Adresse wo erscheint (Was ist CGNAT).

Wer verbindet sich mit welchem Endpoint?

Der einfachste Weg, ein Setup richtig zu konfigurieren, ist, die Komponenten und die Endpoints, mit denen sie sprechen, einmal aufzuschreiben. Der Launcher lädt Ankündigungs- und Anmeldeseiten von Webservern. Der Update-Schritt lädt Dateien von Verteilungsservern. Der Spiel-Client spricht zuerst mit der Lobby und wechselt von dort zum Server der gewählten Welt. Wenn Sie einen externen Voice-Chat nutzen, geht auch dieser zu seinen eigenen Servern.

Sie müssen diese vier bis fünf Endpoints nicht alle über denselben Ausgang führen; in den meisten Setups ist das ohnehin nicht gewünscht. Den Patch-Traffic über einen günstigen Ausgang und die Spiel-Session über einen festen, stabilen Ausgang zu führen liefert sowohl bei den Kosten als auch bei der Stabilität bessere Ergebnisse. Den Voice-Chat vollständig außerhalb des Geltungsbereichs zu lassen ist ebenfalls eine legitime Entscheidung.

Auch der Ort der Namensauflösung gehört zu dieser Karte. Bei SOCKS5 hängt das Verhalten vom Client ab: Manche Clients lösen das Ziel im eigenen Netzwerk auf und geben dem Proxy nur die IP, andere überlassen den Domainnamen dem Proxy. Findet die Auflösung in Ihrem Netzwerk statt, sind die Ziel-Domains für Ihren lokalen DNS-Server sichtbar (Wo wird DNS bei SOCKS5 aufgeloest) und dies DNS-Leak-Test pruefen.

Nach dem Erstellen der Karte verkürzt sich die Überprüfung des Setups: Für jede Komponente gibt es genau eine Antwort auf die Frage „über welchen Ausgang geht das?“, und bei einer Störung wissen Sie, in welches Kästchen Sie schauen müssen.