Tom LAN-spilleliste over OpenVPN? Tjek opdagelsesvejen

At pinge en anden spillers tunneladresse og at se deres hostede spil er to forskellige bedrifter. Lobbyens liste afhænger normalt af en opdagelsesudveksling, der er skrevet til et enkelt lokalt netværk, mens spilsessionen er en almindelig forbindelse til en adresse og port. Hvis du behandler en tom liste som en routingfejl, sendes du mod en bro, du måske ikke har brug for, så skil de to spørgsmål ad, før du ændrer noget.

Skil det at tilslutte sig en session fra at finde den

En mislykket tilslutning peger på ruter, firewallregler og en lyttende tjeneste. En vellykket tilslutning med en tom liste peger på opdagelse eller på den adresse, meddelelsen bærer. De to udfald fører til helt forskelligt arbejde, og du kan kun skelne dem ved bevidst at prøve det første.

Skriv resultatet ned, før du rører VPN-konfigurationen. Det er den billigste test i hele undersøgelsen, og den fjerner halvdelen af designrummet. Notér også den adresse, du brugte, for den bliver referencepunktet for hver senere test. Uden den linje i noterne er den næste sammenligning gætværk.

Test en direkte tilslutning, før du rører tunnelen

Hvis spillet tilbyder direkte forbindelse, så brug værtens tunneladresse og spillets dokumenterede port, og lad spillets egen godkendelse og værtens firewallregler være intakte. En vellykket tilslutning indsnævrer problemet til opdagelse. En mislykket tilslutning kræver stadig sin egen undersøgelse, og ingen relay retter den.

Antag ikke, at opdagelsesporten og sessionsporten er samme nummer. Spil annoncerer normalt på én UDP-port og accepterer spillere på en anden, og en relay bygget til den forkerte giver en liste, der stadig er tom.

Kontrollér også, hvilken adapter hostprocessen valgte. En proces bundet til hjemme-LAN-adressen annoncerer den adresse, og den fjerne spiller kan ikke route til den, selv når meddelelsen ankommer. Listen kan blive fyldt, og tilslutningen kan stadig mislykkes alene af den grund.

Forstå, hvor broadcast stopper

En routet TUN-tunnel bærer IP-pakker mellem peers og genskaber ikke lokal broadcast på hver peers netværk. Den begrænsede broadcastadresse 255.255.255.255 bliver inde i det interface, der udsender den, og en subnetrettet broadcast er et særskilt tilfælde snarere end en generel licens for routere til at oversvømme med meddelelser.

Det er en egenskab ved designet, ikke en fejl, der lappes med en indstilling. OpenVPN og dens client-to-client indstilling styrer peer-trafik inde i tunnelen og er ikke en opdagelsesrelay, selv om den foreslås til netop dette formål i mange tråde. En relay er en separat komponent med sin egen konfiguration og sine egne fejltilstande. At antage, at en eksisterende indstilling allerede dækker det, er den mest almindelige grund til, at denne undersøgelse går i stå.

Multicast-opdagelse har samme problem med en anden adresseklasse, og den kræver multicast-routing eller en relay frem for en broadcast-undtagelse.

Når en relay er berettiget, så hold den snæver

Hvis automatisk opdagelse er et krav, så identificér først den faktiske udveksling: broadcast eller multicast, destinationsadresse, UDP-port, det interface der sender den, og adressen inde i svaret. En protokolpassende relay afgrænset til de fem fakta er langt snævrere end at udvide et helt Ethernet-segment.

Videresendelse af pakken uændret kan stadig være utilstrækkelig. Hvis nyttelasten fortæller modtageren at forbinde til en adresse, den ikke kan nå, leverer relayen et ubrugeligt svar, og derfor bør spillets eget interface eller indstillingen for annonceret adresse prøves, før nogen relay findes.

Afgræns relayen til de interfaces og peers, der har brug for den, og definér, hvordan svar finder den, der spurgte. Gentagne uvedkommende broadcasts blotlægger andre lokale tjenester og skaber løkker, der er svære at fejlfinde senere.

Bro kun når designet kræver Ethernet

Ethernet-rammer rejser inde i TAP, så en TAP-tunnel kan høre til et bevidst broet broadcast-domæne. Blot at skifte dev tun til dev tap bygger ikke den bro, gør ikke serverkonfigurationen kompatibel og får ikke programmet til at vælge det nye interface. OpenVPN's broguide beskriver den bredere ordning snarere end en kur mod én tom lobby.

Broing flader også adresseplanen ud, og derfor fortjener beslutningen en begrundelse ud over utålmodighed. To netværk, der var adskilte, bliver ét, og hver tjeneste på hver side begynder at se den anden sides broadcasts. Den konsekvens hører i ændringsloggen, før nogen aktiverer den. Der er ingen regel om, at spillklienter skal ligge i et 192.168-interval; vælg en plan uden overlap og tjek det enkelte spils begrænsninger i stedet for at omnummerere tunnelen, fordi et forumindlæg gjorde det.

Hold de to resultater adskilt til sidst: om værten kan tilsluttes, og om opdagelsessvaret annoncerer en destination, som den anden spiller faktisk kan bruge. At rette det andet uden at bekræfte det første er måden, hvorpå folk ender med at vedligeholde en bro til et problem, der aldrig handlede om broadcast.