Tom LAN-spelliste over OpenVPN? Sjekk oppdagingsvegen

Å pinge tunneladressa til ein annan spelar og å sjå det hosta spelet hans er to ulike prestasjonar. Lobbylista heng vanlegvis saman med ein oppdagingsutveksling skriven for eitt enkelt lokalt nettverk, medan speløkta er ei vanleg tilkopling til ei adresse og ein port. Å handsame ei tom liste som ein rutefeil sender deg mot ei bru du kanskje ikkje treng, så skil dei to spørsmåla før du endrar noko.

Skil det å bli med i ei økt frå det å finne henne

Ei mislukka tilkopling peikar på ruter, brannmurreglar og ein lyttande teneste. Ei vellukka tilkopling med tom liste peikar på oppdaging, eller på adressa kunngjeringa ber. Desse to utfalla fører til heilt ulikt arbeid, og du kan berre skilje dei ved å med vilje prøve det første.

Skriv ned resultatet før du rører VPN-konfigurasjonen. Det er den billegaste testen i heile granskinga, og han fjernar halve designrommet. Noter også adressa du brukte, for ho blir referansepunktet for kvar seinare test. Utan den lina i notata er den neste samanlikninga gjetting.

Test ei direkte tilkopling før du rører tunnelen

Viss spelet tilbyr direkte tilkopling, bruk tunneladressa til verten og den dokumenterte spelporten, og lat spelet si eiga autentisering og brannmurreglane til verten vere intakte. Ei vellukka tilkopling snevrar problemet inn til oppdaging. Ei mislukka tilkopling treng framleis si eiga gransking, og ingen relay rettar henne.

Ikkje gå ut frå at oppdagingsporten og sesjonsporten er same nummer. Spel kunngjer vanlegvis på ein UDP-port og tek imot spelarar på ein annan, og ein relay bygd for den gale gjev ei liste som framleis er tom.

Sjekk også kva adapter hostprosessen valde. Ein prosess bunden til heime-LAN-adressa kunngjer den adressa, og den eksterne spelaren kan ikkje rute dit sjølv når kunngjeringa kjem fram. Lista kan fyllast, og tilkoplinga kan framleis mislukkast berre på grunn av det.

Forstå kvar broadcast stoppar

Ein ruta TUN-tunnel ber IP-pakkar mellom peerar og attskapar ikkje lokal broadcast på nettet til kvar peer. Den avgrensa broadcastadressa 255.255.255.255 held seg inne i grensesnittet som sender henne, og ein subnettretta broadcast er eit eige tilfelle og ikkje ein generell lisens for ruterar til å oversvømme kunngjeringar.

Det er ein eigenskap ved designet, ikkje ein feil som blir lappa med eit val. OpenVPN og client-to-client innstillinga styrer peer-trafikk inne i tunnelen og er ikkje ein oppdagingsrelay, sjølv om ho blir føreslått nettopp til dette føremålet i mange trådar. Ein relay er ein separat komponent med si eiga konfigurasjon og sine eigne feilmodusar. Å gå ut frå at eit eksisterande val alt dekkjer det, er den vanlegaste grunnen til at denne granskinga stoggar.

Multicast-oppdaging har same problem med ein annan adresseklasse, og ho treng multicast-ruting eller ein relay i staden for eit broadcast-unntak.

Når ein relay er grunngjeven, hald han smal

Viss automatisk oppdaging er eit krav, identifiser først den faktiske utvekslinga: broadcast eller multicast, måladdresse, UDP-port, grensesnittet som sender henne, og adressa inne i svaret. Ein protokollpassande relay avgrensa til desse fem fakta er langt smalare enn å utvide eit heilt Ethernet-segment.

Vidaresending av pakken uendra kan framleis vere utilstrekkeleg. Viss nyttelasta fortel mottakaren å kople til ei adresse han ikkje kan nå, leverer relayen eit ubrukeleg svar, og difor bør grensesnittet til spelet sjølv eller innstillinga for kunngjort adresse prøvast før nokon relay finst.

Avgrens relayen til grensesnitta og peerane som treng han, og definer korleis svar finn den som spør. Å gjenta uvedkommande broadcastar eksponerer andre lokale tenester og lagar løkker som er vonde å feilsøkje seinare.

Bru berre når designet treng Ethernet

Ethernet-rammer reiser inne i TAP, så ein TAP-tunnel kan høyre til eit med vilje brua broadcast-domene. Berre det å byte dev tun til dev tap byggjer ikkje den brua, gjer ikkje serverkonfigurasjonen kompatibel og får ikkje applikasjonen til å velje det nye grensesnittet. OpenVPN si bruveiledning skildrar den breiare ordninga, ikkje ein kur mot ein tom lobby.

Bruing flatar også ut adresseplanen, og difor fortener avgjerda ein grunn utover utolmod. To nettverk som var skilde blir eitt, og kvar teneste på kvar side byrjar å sjå broadcastane til den andre sida. Den konsekvensen høyrer heime i endringsloggen før nokon aktiverer han. Det finst inga regel om at spelklientar må liggje i eit 192.168-område; vel ein plan utan overlapp og sjekk avgrensingane til det einskilde spelet i staden for å omnummerere tunnelen fordi eit foruminnlegg gjorde det.

Hald dei to resultata skilde til slutt: om verten kan nåast, og om oppdagingssvaret kunngjer ein destinasjon som den andre spelaren faktisk kan bruke. Å rette det andre utan å stadfeste det første er måten folk endar med å vedlikehalde ei bru for eit problem som aldri handla om broadcast.