Leere LAN-Spielliste über OpenVPN? Prüfen Sie den Discovery-Pfad

Die Tunneladresse eines anderen Spielers anzupingen und sein gehostetes Spiel zu sehen, sind zwei verschiedene Errungenschaften. Die Lobby-Liste hängt meist von einem Discovery-Austausch ab, der für ein einzelnes lokales Netzwerk geschrieben wurde, während die Spielsitzung eine gewöhnliche Verbindung zu einer Adresse und einem Port ist. Eine leere Liste als Routingfehler zu deuten, schickt Sie zu einer Bridge, die Sie vielleicht gar nicht brauchen – trennen Sie die beiden Fragen, bevor Sie etwas ändern.

Trennen Sie das Beitreten zu einer Sitzung vom Finden derselben

Ein fehlgeschlagener Beitritt deutet auf Routen, Firewall-Regeln und einen lauschenden Dienst hin. Ein erfolgreicher Beitritt mit leerer Liste deutet auf Discovery hin oder auf die Adresse, die die Ankündigung trägt. Diese beiden Ergebnisse führen zu völlig unterschiedlicher Arbeit, und unterscheiden lassen sie sich nur, indem Sie das erste gezielt ausprobieren.

Schreiben Sie das Ergebnis auf, bevor Sie die VPN-Konfiguration anfassen. Es ist der billigste Test der ganzen Untersuchung und halbiert den Designraum. Notieren Sie auch die verwendete Adresse, denn sie wird zum Bezugspunkt für jeden späteren Test. Ohne diese Zeile in Ihren Notizen ist der nächste Vergleich nur eine Vermutung.

Testen Sie einen direkten Beitritt, bevor Sie den Tunnel anfassen

Bietet das Spiel eine Direktverbindung an, nutzen Sie die Tunneladresse des Hosts und den dokumentierten Spielport, und lassen Sie die eigene Authentifizierung des Spiels sowie die Firewall-Regeln des Hosts unangetastet. Ein erfolgreicher Beitritt verengt das Problem auf Discovery. Ein fehlgeschlagener Beitritt braucht weiterhin eine eigene Untersuchung, und kein Relay behebt ihn.

Gehen Sie nicht davon aus, dass Discovery-Port und Sitzungsport dieselbe Nummer sind. Spiele kündigen üblicherweise auf einem UDP-Port an und nehmen Spieler auf einem anderen an, und ein Relay für den falschen Port liefert eine Liste, die trotzdem leer bleibt.

Prüfen Sie auch, welchen Adapter der Hosting-Prozess gewählt hat. Ein an die Heim-LAN-Adresse gebundener Prozess kündigt diese Adresse an, und der entfernte Spieler kann sie nicht erreichen, selbst wenn die Ankündigung ankommt. Die Liste kann sich füllen, und der Beitritt kann allein deshalb scheitern.

Verstehen Sie, wo Broadcast endet

Ein gerouteter TUN-Tunnel überträgt IP-Pakete zwischen Peers und bildet lokalen Broadcast nicht im Netz jedes Peers nach. Die begrenzte Broadcast-Adresse 255.255.255.255 bleibt innerhalb der Schnittstelle, die sie aussendet, und ein subnetzgerichteter Broadcast ist ein eigener Fall und keine allgemeine Lizenz für Router, Ankündigungen zu fluten.

Das ist eine Eigenschaft des Designs, kein Defekt, der sich mit einer Option zupflastern lässt. OpenVPN und seine client-to-client Einstellung regelt den Peer-Verkehr innerhalb des Tunnels und ist kein Discovery-Relay, auch wenn sie in vielen Threads genau dafür vorgeschlagen wird. Ein Relay ist eine eigene Komponente mit eigener Konfiguration und eigenen Fehlerarten. Die Annahme, eine bestehende Option decke das bereits ab, ist der häufigste Grund, warum diese Untersuchung stecken bleibt.

Multicast-Discovery hat dasselbe Problem mit einer anderen Adressklasse und braucht Multicast-Routing oder ein Relay statt einer Broadcast-Ausnahme.

Wenn ein Relay gerechtfertigt ist, halten Sie es schmal

Ist automatische Discovery eine Anforderung, identifizieren Sie zuerst den tatsächlichen Austausch: Broadcast oder Multicast, Zieladresse, UDP-Port, die Schnittstelle, die ihn sendet, und die Adresse in der Antwort. Ein protokollgerechtes Relay, das auf diese fünf Fakten begrenzt ist, ist weit schmaler als ein ganzes Ethernet-Segment auszudehnen.

Das Paket unverändert weiterzuleiten, kann trotzdem unzureichend sein. Sagt die Nutzlast dem Empfänger, er solle sich mit einer Adresse verbinden, die er nicht erreicht, liefert das Relay eine nutzlose Antwort – deshalb sollte die spieleigene Schnittstelle oder die Einstellung für die angekündigte Adresse geprüft werden, bevor es irgendein Relay gibt.

Begrenzen Sie das Relay auf die Schnittstellen und Peers, die es brauchen, und legen Sie fest, wie Antworten den Anfragenden finden. Das Wiederholen unzusammenhängender Broadcasts legt andere lokale Dienste offen und erzeugt Schleifen, die sich später nur mühsam debuggen lassen.

Bridge nur, wenn das Design Ethernet braucht

Ethernet-Frames reisen in TAP, also kann ein TAP-Tunnel zu einer bewusst überbrückten Broadcast-Domäne gehören. Bloßes Umschalten von dev tun auf dev tap baut diese Bridge nicht, macht die Serverkonfiguration nicht kompatibel und bringt die Anwendung nicht dazu, die neue Schnittstelle zu wählen. OpenVPNs Bridging-Leitfaden beschreibt die größere Anordnung statt ein Heilmittel für eine leere Lobby.

Bridging einebnet außerdem den Adressplan, weshalb die Entscheidung einen Grund jenseits von Ungeduld verdient. Zwei Netze, die getrennt waren, werden eins, und jeder Dienst auf beiden Seiten beginnt, die Broadcasts der anderen Seite zu sehen. Diese Folge gehört in das Änderungsprotokoll, bevor sie jemand einschaltet. Es gibt keine Regel, dass Spielclients in einem 192.168-Bereich liegen müssen; wählen Sie einen überschneidungsfreien Plan und prüfen Sie die Einschränkungen des jeweiligen Spiels, statt den Tunnel neu zu nummerieren, weil ein Forumsbeitrag es getan hat.

Halten Sie am Ende die beiden Ergebnisse getrennt: ob dem Host beigetreten werden kann und ob die Discovery-Antwort ein Ziel ankündigt, das der andere Spieler tatsächlich nutzen kann. Das zweite zu reparieren, ohne das erste zu bestätigen, ist der Weg, auf dem Leute am Ende eine Bridge für ein Problem pflegen, bei dem es nie um Broadcast ging.