Lege LAN-gamelijst via OpenVPN? Controleer het detectiepad

Het tunneladres van een andere speler pingen en zijn gehoste spel zien zijn twee verschillende prestaties. De lijst in de lobby hangt meestal af van een detectie-uitwisseling die voor één lokaal netwerk is geschreven, terwijl de spelsessie een gewone verbinding naar een adres en poort is. Een lege lijst als routeringsfout behandelen stuurt je naar een bridge die je misschien niet nodig hebt, dus scheid de twee vragen voordat je iets verandert.

Scheid het deelnemen aan een sessie van het vinden ervan

Een mislukte deelname wijst op routes, firewallregels en een luisterende dienst. Een geslaagde deelname met een lege lijst wijst op detectie, of op het adres dat de aankondiging draagt. Die twee uitkomsten leiden tot heel verschillend werk, en je kunt ze alleen onderscheiden door de eerste bewust te proberen.

Schrijf het resultaat op voordat je de VPN-configuratie aanraakt. Het is de goedkoopste test in het hele onderzoek en het elimineert de helft van de ontwerpruimte. Noteer ook het adres dat je gebruikte, want dat wordt het referentiepunt voor elke latere test. Zonder die regel in je notities is de volgende vergelijking giswerk.

Test een directe deelname voordat je de tunnel aanraakt

Als het spel een directe verbinding biedt, gebruik dan het tunneladres van de host en de gedocumenteerde spelpoort, en laat de eigen authenticatie van het spel en de firewallregels van de host intact. Een geslaagde deelname beperkt het probleem tot detectie. Een mislukte deelname vereist nog steeds een eigen onderzoek, en geen enkele relay lost dat op.

Ga er niet van uit dat de detectiepoort en de sessiepoort hetzelfde nummer zijn. Spellen kondigen meestal aan op de ene UDP-poort en accepteren spelers op een andere, en een relay die voor de verkeerde is gebouwd levert een lijst die leeg blijft.

Controleer ook welke adapter het hostingproces heeft gekozen. Een proces dat aan het thuis-LAN-adres is gebonden, kondigt dat adres aan, en de externe speler kan er niet naartoe routeren, zelfs niet als de aankondiging aankomt. De lijst kan zich vullen en de deelname kan alleen daardoor mislukken.

Begrijp waar broadcast stopt

Een gerouteerde TUN-tunnel draagt IP-pakketten tussen peers en reproduceert geen lokale broadcast op het netwerk van elke peer. Het beperkte broadcastadres 255.255.255.255 blijft binnen de interface die het uitzendt, en een subnetgericht broadcast is een apart geval en geen algemene licentie voor routers om aankondigingen te overspoelen.

Dat is een eigenschap van het ontwerp, geen defect dat met een optie wordt dichtgeplakt. OpenVPN en zijn client-to-client instelling regelt peerverkeer binnen de tunnel en is geen detectierelay, ook al wordt het in veel threads juist hiervoor aangeraden. Een relay is een apart onderdeel met een eigen configuratie en eigen faalmodi. Aannemen dat een bestaande optie dit al dekt, is de meest voorkomende reden dat dit onderzoek vastloopt.

Multicast-detectie heeft hetzelfde probleem met een andere adresklasse, en het vereist multicast-routering of een relay in plaats van een broadcast-uitzondering.

Als een relay gerechtvaardigd is, houd hem dan smal

Als automatische detectie een vereiste is, identificeer dan eerst de werkelijke uitwisseling: broadcast of multicast, bestemmingsadres, UDP-poort, de interface die hem verstuurt, en het adres in het antwoord. Een protocolpassende relay die tot die vijf feiten beperkt is, is veel smaller dan een heel Ethernet-segment uitbreiden.

Het pakket ongewijzigd doorsturen kan nog steeds onvoldoende zijn. Als de payload de ontvanger vertelt verbinding te maken met een adres dat hij niet kan bereiken, levert de relay een nutteloos antwoord, en daarom moet de interface van het spel zelf of de instelling voor het aangekondigde adres worden geprobeerd voordat er een relay bestaat.

Beperk de relay tot de interfaces en peers die hem nodig hebben, en definieer hoe antwoorden de aanvrager vinden. Het herhalen van niet-gerelateerde broadcasts legt andere lokale diensten bloot en maakt lussen die later lastig te debuggen zijn.

Bridge alleen wanneer het ontwerp Ethernet nodig heeft

Ethernet-frames reizen in TAP, dus een TAP-tunnel kan bij een bewust overbrugd broadcast-domein horen. Alleen dev tun naar dev tap omzetten bouwt die bridge niet, maakt de serverconfiguratie niet compatibel en zorgt er niet voor dat de toepassing de nieuwe interface kiest. De OpenVPN-bridginghandleiding beschrijft de bredere opzet, geen remedie voor één lege lobby.

Bridging vlakt ook het adresplan af, en daarom verdient de beslissing een reden verder dan ongeduld. Twee netwerken die gescheiden waren worden er één, en elke dienst aan beide kanten begint de broadcasts van de andere kant te zien. Dat gevolg hoort in het wijzigingslog voordat iemand het inschakelt. Er is geen regel dat gameclients in een 192.168-bereik moeten zitten; kies een plan zonder overlap en controleer de beperkingen van het betreffende spel in plaats van de tunnel te hernummeren omdat een forumpost dat deed.

Houd de twee resultaten aan het eind gescheiden: of de host te joinen is, en of het detectieantwoord een bestemming aankondigt die de andere speler echt kan gebruiken. Het tweede repareren zonder het eerste te bevestigen is hoe mensen uiteindelijk een bridge onderhouden voor een probleem dat nooit over broadcast ging.