Der Spielprozess bindet keine UDP-Socket an die VPN-Schnittstelle
489
Roger Gee
Ich habe kürzlich ein VPN für LAN-Spiele mit Freunden eingerichtet. Ich habe einen Linux-Server pptpdund konnte unter Windows mithilfe des im Betriebssystem integrierten VPN-Clients eine Verbindung herstellen. Ich habe getestet, dass das VPN Informationen zwischen Clients (einschließlich Broadcast-Nachrichten) korrekt weiterleitet. Auf jedem Client wird ein virtueller Netzwerkadapter erstellt, dem im System die höchste Priorität zugewiesen wird. Dies bedeutet, dass alle Netzwerkverbindungen standardmäßig verwendet werden (z. B. ein Webbrowser) und bei Namensabfragen zuerst zurückgegeben werden (z. B. Ergebnisse, die von Socket-APIs wie getaddrinfo()und zurückgegeben werdengethostbyname()). Mein Problem ist, dass das bestimmte Spiel, das wir spielen möchten, seine UDP-Sockets nicht an die richtige Netzwerkschnittstelle bindet. Der Spielprozess bindet stattdessen explizit an die Schnittstelle der ursprünglichen Netzwerkverbindung (das Windows-Äquivalent von eth0oder wlan0). Ich möchte, dass es an den VPN-Adapter (das Windows-Äquivalent von ppp0) bindet .
Dieses spezielle Spiel wird von EA Games Battle For Middle-Earth genannt. Wenn sich das Spiel in der LAN-Multiplayer-Lobby befindet, bindet das Spiel einen Socket an den UDP-Port 8086. Er verwendet diesen Port zum Senden von Broadcast-Datagrammen, um andere Peers darauf hinzuweisen, dass es verfügbar ist, UND um Alerts von anderen Peers zu erhalten. Wenn 8086 nicht verfügbar ist, wird eine Verbindung zum nächsten sequenziellen Port hergestellt. Aus diesem Grund werden Kopien derselben Broadcast-Nachricht an einen Portbereich (z. B. 8086..8095) gesendet. Sobald ein Spiel gestartet wurde, senden die Peers gerichtete Datagramme im Gegensatz zu Broadcasts. So wie es jetzt aussieht, trifft keiner der Spieleverkehr das VPN. Hier ist eine netstatAusgabe, die das an das 10.0.1.0/24Netzwerk gebundene Spiel (von einem Heimrouter zugewiesen) und nicht das 192.168.0.0/24Netzwerk (vom VPN-Server zugewiesen) zeigt:
Es liegt auf der Hand, dass das Spiel eine Auswahl hinsichtlich der verwendeten Schnittstelle vorsieht. Dies ist sinnvoll, wenn man bedenkt, dass das LAN des Benutzers mit Ermittlungsnachrichten überflutet werden muss, um die Adressen der anderen Peers zu ermitteln. Aber sollte ein VPN nicht über eine Internetverbindung ein LAN bereitstellen? Warum wählt das Spiel die alte Schnittstelle und nicht die VPN-Schnittstelle mit höherer Priorität? Ich denke, es muss eine obskure Einstellung geben, mit der Windows das VPN-Netzwerk als LAN konfigurieren kann. Es fällt mir jedoch schwer, es zu finden.
Jede Hilfe in die richtige Richtung wird geschätzt!
Im Nachhinein: Ich weiß, dass das Spiel die NetBIOS-Funktion verwendet (ich habe seine Liste der Funktionsimporte abgelegt). Ich weiß auch (historisch), dass, wenn einer der Kollegen nicht Mitglieder derselben Arbeitsgruppe ist, er ignoriert wird. Könnte das Problem, mit dem ich konfrontiert bin, etwas mit der NetBIOS-Konfiguration des Netzwerks zu tun haben?
2 Antworten auf die Frage
0
Roger Gee
Ich konnte dieses Problem mit einer Konfigurationsoption lösen, die für das betreffende Spiel spezifisch ist (auf die ich zufällig ohne viel Glück gestoßen bin). Dadurch konnte ich direkt angeben, welche Schnittstelle das Spiel verwenden soll. Dazu fügen Sie der Options.iniDatei den folgenden Eintrag hinzu (in %USERPROFILE%\AppData\Roaming\My Battle For Middle-Earth Files\):
IPAddress = x.x.x.x
Wo x.x.x.xist die gepunktete Dezimalzahl der IPv4-Adresse der Schnittstelle, die der Spielprozess verwenden soll.
Ich habe nie herausgefunden, warum das Spiel die virtuelle Schnittstelle mit höherer Priorität ignoriert hat. Ich schließe daraus, dass dies ein Konstruktionsfehler in der Konstruktion des Spiels sein muss und nicht in Windows konfiguriert werden kann.
Es ist auch erwähnenswert, dass ich zur Verwendung von OpenVPN umgestiegen bin, pptpdda es eine bessere Unterstützung für die Verbindungsschicht bietet (dh ich könnte den virtuellen Adapter des Servers überbrücken, um Broadcast-Frames besser zu handhaben).
0
OvenCrate
Dies kann auch auf einigen Maschinen hilfreich sein. Ob dies funktioniert oder nicht, scheint völlig zufällig zu sein, aber die Installation eines Dienstes ist immer noch einfacher als das Bearbeiten einer Konfigurationsdatei bei jedem Netzwerkwechsel.
In der Art und Weise, wie BFME mit dem Networking umgeht, ist wirklich etwas schiefgelaufen. Leider existiert der Entwickler nicht mehr und es ist kein Open Source. Wir werden also nie erfahren ...
Willkommen bei Super User. Externe Links können brechen oder nicht verfügbar sein. In diesem Fall wäre Ihre Antwort nicht nützlich. Bitte geben Sie die wesentlichen Informationen in Ihre Antwort ein und verwenden Sie den Link für die Zuordnung und weitere Lektüre. Vielen Dank.
fixer1234 vor 7 Jahren
0