Squad Proxy: Serverseite, Router-Geltungsbereich und Grenzen

Squad ist ein Shooter, bei dem grosse Teams gleichzeitig auf weitläufigen Karten agieren, und erzeugt netzwerkseitig zwei verschiedene Rollen: den Client, der einem Server beitritt, und die Seite, die den Server hostet. Die Proxy-Diskussion verläuft in diesen beiden Rollen völlig unterschiedlich. Auf Client-Seite lautet die Frage "Läuft mein Traffic durch den Tunnel?", auf Host-Seite dagegen "Bin ich von aussen erreichbar?".

Die zweite Unterscheidung betrifft den Ort, an dem die Konfiguration eingetragen wird. Eine auf einem Gerät definierte Regel umfasst nur dieses Gerät, eine auf dem Router definierte Regel alles im Haushalt. Beide lösen unterschiedliche Probleme und bergen unterschiedliche Risiken.

Nachfolgend behandeln wir zuerst die Servertopologie, dann die Entscheidung über den Geltungsbereich und schliesslich die Diagnosereihenfolge in eingeschränkten Netzen.

Auf welchem Server spielen Sie, und wer betreibt ihn?

Im Squad-Ökosystem wird ein erheblicher Teil der Server von der Community betrieben. Clans, Communities und Hosting-Anbieter betreiben eigene Instanzen; der Spieler wählt eine davon aus einer Liste. Diese Struktur ergibt ein anderes Bild als bei Spielen, die an ein einziges Rechenzentrum des Publishers gebunden sind: Land, Regeln und Konfiguration des Servers hängen vom Betreiber ab.

Das hat auf der Proxy-Seite zwei Konsequenzen. Erstens ist die entscheidende Variable für die Verbindungsqualität der physische Weg zwischen Ihnen und dem Server. Einen Ausgang dazwischenzuschalten verkürzt diesen Weg nicht; es fügt eine Zwischenstation hinzu. Zweitens verhalten sich Serverlistenabfrage und Match-Sitzung unterschiedlich: Die Liste ist ein Anfrage-Antwort-Vorgang, das Match dagegen ein kontinuierlicher Stream.

Eine dritte Ebene sind Mods. Ein Teil der Community-Server läuft mit Zusatzinhalten, und diese kommen nicht aus dem Spiel selbst, sondern aus der Workshop-Infrastruktur der Vertriebsplattform. Diese Downloads sind Web-Traffic; erfasst Ihre Proxy-Regel den Plattform-Client, läuft auch dieser Stream durch den Tunnel und geht von Ihrem Kontingent ab.

Wenn Sie überlegen, einen eigenen Server zu betreiben, kehrt sich die Gleichung um: Nun müssen Sie eingehende Verbindungen annehmen. Ein Forward-Proxy leistet das nicht; den Unterschied beider Konzepte Forward und Reverse Proxy ausfuehrlich erlaeutert.

Einen Server zu hosten ist netzwerktechnisch nicht dasselbe wie einem Server beizutreten

Für die beitretende Seite wird die Verbindung von innen nach aussen aufgebaut. Der Heimrouter trägt diese Anfrage in die NAT-Tabelle ein, ordnet die zurückkommenden Antworten zu, und damit ist es getan; in den meisten Haushalten ist keine zusätzliche Einstellung nötig. Für die hostende Seite ist die Richtung umgekehrt: Die Verbindung kommt von aussen, und der Router muss wissen, an welches interne Gerät er diese Anfrage weiterreicht.

Hier werden zwei Konzepte häufig verwechselt. NAT ist eine Adressübersetzung und leitet die Verbindung weiter; ein Proxy dagegen ist ein Vermittler und baut die Anfrage in Ihrem Namen selbst auf. Den Unterschied Vergleich von Proxy und NAT erläutert dieser Beitrag. Liegt Ihr Heimanschluss hinter einer auf Anbieterebene geteilten Adresse, ist der Zugriff von aussen unter Umständen ohnehin nicht möglich; Details dazu CGNAT .

In der Praxis läuft der überwiegende Teil der Community-Server nicht auf einem Heimanschluss, sondern bei einem Hosting-Anbieter. Der Grund ist einfach: Ein gut besuchter Server benötigt dauerhafte und symmetrische Bandbreite, und die Upload-Kapazität von Heimanschlüssen reicht dafür meist nicht aus. Zudem schlägt die Stabilität des Servers unmittelbar auf das Spielerlebnis durch; ein einziger Abbruch wirft alle gerade Verbundenen gleichzeitig heraus.

Auf der Hosting-Seite liegt der Nutzen eines Proxys nicht im Spiel-Traffic, sondern in den umgebenden Verwaltungsaufgaben. Die Oberflächen zum Auslesen der Server-Logs, zum Aktualisieren von Konfigurationsdateien und zum Verwalten von Spielerlisten sind gewöhnliche Webanwendungen und laufen problemlos durch den Tunnel. Statt zu versuchen, den Stream des Spiels selbst zu transportieren, ist die Regelung des Zugriffs auf diese Oberflächen der realistischste Beitrag eines Proxys in diesem Szenario.

Regel auf dem Gerät oder auf dem Router eintragen?

Ein auf Geräteebene eingetragener Proxy umfasst nur dieses Gerät und häufig nur bestimmte Anwendungen darauf. Der Vorteil ist die Kontrolle: Geht etwas schief, sind die übrigen Geräte im Haushalt nicht betroffen, und das Zurücksetzen dauert Sekunden. Der Nachteil ist, dass Sie dieselbe Einstellung auf jedem Gerät wiederholen müssen.

Auf Router-Ebene ist es genau umgekehrt. Die Einstellung erfolgt an einer Stelle, umfasst jedes Gerät im Netz und schliesst auch Geräte ohne eigenen Einstellungsbildschirm ein. Der Preis: Eine falsche Regel betrifft den gesamten Haushalt, die Diagnose wird schwieriger, und ein Teil der Heimrouter bietet eine solche Konfiguration in der Standardoberfläche gar nicht an. Wenn Sie die Optionen vergleichen möchten, Proxy-Nutzung ueber den Router zeigt dieser Beitrag die Schritte.

Speziell bei Squad kann das Ergebnis dieser Entscheidung überraschen. Selbst eine auf dem Router eingetragene Regel leitet den UDP-Stream des Spiels nicht von selbst in den Tunnel; eine HTTP-Proxy-Einstellung, die alle Geräte im Heimnetz umfasst, kann einen Stream mit anderem Transportmodell nicht transportieren. Ein grösserer Geltungsbereich hebt die Grenze des Protokolls nicht auf.

Für die meisten Privatnutzer ist daher der richtige Weg, beim engen Geltungsbereich zu bleiben und den Proxy nur für Web- und Plattformaufgaben zu nutzen. Ein weiter Geltungsbereich ergibt nur Sinn, wenn ein konkreter Bedarf besteht - etwa wenn Sie zu Hause mit mehreren Geräten dieselbe regionale Darstellung testen wollen.

Das Profil beider Protokolle bei dieser Aufgabe

Ein HTTP-Proxy arbeitet auf der Anwendungsschicht; er interpretiert einfache HTTP-Anfragen, öffnet für HTTPS mit CONNECT einen Tunnel und transportiert ausschliesslich TCP. SOCKS5 arbeitet auf der Transportschicht, interpretiert das transportierte Protokoll nicht und bietet mit UDP ASSOCIATE die Möglichkeit zum UDP-Transport. Auf dem Papier wirkt Letzteres für Spiele geeigneter.

In der Praxis ist das Bild enger. Damit die UDP-Transportkette funktioniert, müssen drei Bedingungen erfüllt sein: Der Server muss die Methode freigeben, der Client muss das Senden von UDP über SOCKS5 unterstützen, und das dazwischenliegende Netz muss diesen Traffic zulassen. Bei den meisten Spiele-Clients ist die zweite Bedingung nicht erfüllt; deshalb ist der theoretische Vorteil von SOCKS5 im Feld nur selten nutzbar.

Die Entscheidung wird dadurch einfach: Für Web-, Plattform- und Verwaltungsoberflächen eignen sich beide Protokolle, die Wahl richtet sich danach, welches Ihr Client unterstützt. Wenn Sie die Unterscheidung vertiefen möchten, Unterschied zwischen HTTP und SOCKS5 enthält dieser Beitrag eine Vergleichstabelle; die Auswahlgründe Leitfaden zur Protokollwahl fasst er zusammen.

Es gibt noch eine dritte Variable: die Anzahl gleichzeitiger Verbindungen. Wenn Sie Inhalte von einem Server mit Mods herunterladen und gleichzeitig Community-Seiten im Browser geöffnet haben, steigt die Zahl paralleler Anfragen schnell. Wenn Sie die Obergrenze Ihres Pakets nicht kennen, Limit gleichzeitiger Verbindungen erklärt dieser Beitrag, wie sich diese Obergrenze ablesen lässt.