Tom LAN-spellista via OpenVPN? Kontrollera upptäcktsvägen

Att pinga en annan spelares tunneladress och att se dennes hostade spel är två olika bedrifter. Lobbyns lista beror oftast på ett upptäcktsutbyte skrivet för ett enda lokalt nätverk, medan spelsessionen är en vanlig anslutning till en adress och port. Att behandla en tom lista som ett routingfel skickar dig mot en bro du kanske inte behöver, så skilj de två frågorna åt innan du ändrar något.

Skilj anslutningen till en session från att hitta den

En misslyckad anslutning pekar på rutter, brandväggsregler och en lyssnande tjänst. En lyckad anslutning med tom lista pekar på upptäckt, eller på adressen som annonsen bär. Dessa två utfall leder till helt olika arbete, och du kan bara skilja dem åt genom att medvetet prova det första.

Skriv ner resultatet innan du rör VPN-konfigurationen. Det är det billigaste testet i hela undersökningen och det eliminerar halva designutrymmet. Notera också adressen du använde, för den blir referenspunkten för varje senare test. Utan den raden i anteckningarna är nästa jämförelse en gissning.

Testa en direkt anslutning innan du rör tunneln

Om spelet erbjuder direktanslutning, använd värdens tunneladress och spelets dokumenterade port, och låt spelets egen autentisering och värdens brandväggsregler vara orörda. En lyckad anslutning begränsar problemet till upptäckt. En misslyckad anslutning behöver fortfarande sin egen undersökning, och ingen relay rättar den.

Anta inte att upptäcktsporten och sessionsporten är samma nummer. Spel annonserar vanligtvis på en UDP-port och tar emot spelare på en annan, och en relay byggd för fel port ger en lista som fortfarande är tom.

Kontrollera också vilket nätverkskort hostingprocessen valde. En process bunden till hemma-LAN-adressen annonserar den adressen, och den fjärranslutna spelaren kan inte routa dit även när annonsen kommer fram. Listan kan fyllas och anslutningen kan ändå misslyckas bara på grund av det.

Förstå var broadcast tar slut

En routad TUN-tunnel bär IP-paket mellan peers och återskapar inte lokal broadcast i varje peers nätverk. Den begränsade broadcastadressen 255.255.255.255 stannar inom det gränssnitt som sänder den, och en subnätriktad broadcast är ett eget fall och inte en allmän licens för routrar att översvämma annonser.

Det är en egenskap hos designen, inte en brist som lappas med ett alternativ. OpenVPN och dess client-to-client inställning styr peer-trafiken inne i tunneln och är ingen upptäcktsrelay, även om den föreslås just för detta syfte i många trådar. En relay är en separat komponent med egen konfiguration och egna fellägen. Antagandet att ett befintligt alternativ redan täcker det är den vanligaste orsaken till att den här undersökningen kör fast.

Multicast-upptäckt har samma problem med en annan adressklass, och den kräver multicast-routing eller en relay i stället för ett broadcast-undantag.

När en relay är berättigad, håll den smal

Om automatisk upptäckt är ett krav, identifiera först det faktiska utbytet: broadcast eller multicast, destinationsadress, UDP-port, gränssnittet som skickar den och adressen inne i svaret. En protokollanpassad relay begränsad till dessa fem fakta är mycket smalare än att utöka ett helt Ethernet-segment.

Vidarebefordran av paketet oförändrat kan fortfarande vara otillräcklig. Om nyttolasten säger åt mottagaren att ansluta till en adress den inte kan nå, levererar relayen ett oanvändbart svar, därför bör spelets eget gränssnitt eller inställningen för annonserad adress provas innan någon relay finns.

Begränsa relayen till de gränssnitt och peers som behöver den, och definiera hur svar hittar den som frågar. Att upprepa orelaterade broadcasts exponerar andra lokala tjänster och skapar loopar som är svåra att felsöka senare.

Bro bara när designen kräver Ethernet

Ethernet-ramar färdas inuti TAP, så en TAP-tunnel kan tillhöra en medvetet överbryggad broadcast-domän. Att bara byta dev tun till dev tap bygger inte den bron, gör inte serverkonfigurationen kompatibel och får inte programmet att välja det nya gränssnittet. OpenVPN:s bryggningsguide beskriver den bredare ordningen, inte ett botemedel mot en tom lobby.

Bryggning plattar också ut adressplanen, och därför förtjänar beslutet en anledning utöver otålighet. Två nätverk som var åtskilda blir ett, och varje tjänst på båda sidor börjar se den andra sidans broadcasts. Den konsekvensen hör hemma i ändringsloggen innan någon aktiverar den. Det finns ingen regel att spelklienter måste ligga i ett 192.168-intervall; välj en plan utan överlappning och kontrollera det enskilda spelets begränsningar i stället för att numrera om tunneln för att ett foruminlägg gjorde det.

Håll de två resultaten åtskilda i slutet: om värden går att ansluta till, och om upptäcktssvaret annonserar en destination som den andra spelaren faktiskt kan använda. Att rätta det andra utan att bekräfta det första är hur folk till slut underhåller en bro för ett problem som aldrig handlade om broadcast.