Tom LAN-spillliste over OpenVPN? Sjekk oppdagelsesveien

Å pinge en annen spillers tunneladresse og å se det hostede spillet deres er to forskjellige prestasjoner. Lobbylisten avhenger vanligvis av en oppdagelsesutveksling skrevet for ett enkelt lokalt nettverk, mens spillsesjonen er en vanlig forbindelse til en adresse og port. Å behandle en tom liste som en rutingsfeil sender deg mot en bro du kanskje ikke trenger, så skill de to spørsmålene før du endrer noe.

Skill det å bli med i en sesjon fra det å finne den

En mislykket tilkobling peker på ruter, brannmurregler og en lyttende tjeneste. En vellykket tilkobling med tom liste peker på oppdagelse, eller på adressen kunngjøringen bærer. De to utfallene fører til helt forskjellig arbeid, og du kan bare skille dem ved å bevisst prøve det første.

Skriv ned resultatet før du rører VPN-konfigurasjonen. Det er den billigste testen i hele undersøkelsen, og den fjerner halve designrommet. Noter også adressen du brukte, for den blir referansepunktet for hver senere test. Uten den linjen i notatene er den neste sammenligningen gjetning.

Test en direkte tilkobling før du rører tunnelen

Hvis spillet tilbyr direkte tilkobling, bruk vertens tunneladresse og spillets dokumenterte port, og la spillets egen autentisering og vertens brannmurregler være intakte. En vellykket tilkobling snevrer problemet inn til oppdagelse. En mislykket tilkobling trenger fortsatt sin egen undersøkelse, og ingen relay retter den.

Ikke anta at oppdagelsesporten og sesjonsporten er samme nummer. Spill kunngjør vanligvis på én UDP-port og tar imot spillere på en annen, og en relay bygget for feil port gir en liste som fortsatt er tom.

Sjekk også hvilken adapter hostprosessen valgte. En prosess bundet til hjemme-LAN-adressen kunngjør den adressen, og den eksterne spilleren kan ikke rute til den selv når kunngjøringen kommer frem. Listen kan fylles, og tilkoblingen kan fortsatt mislykkes bare på grunn av det.

Forstå hvor broadcast stopper

En rutet TUN-tunnel bærer IP-pakker mellom peers og gjenskaper ikke lokal broadcast på hver peers nettverk. Den begrensede broadcastadressen 255.255.255.255 holder seg inne i grensesnittet som sender den, og en subnettrettet broadcast er et eget tilfelle og ikke en generell lisens for rutere til å oversvømme kunngjøringer.

Det er en egenskap ved designet, ikke en feil som lappes med et alternativ. OpenVPN og client-to-client innstillingen styrer peer-trafikk inne i tunnelen og er ikke en oppdagelsesrelay, selv om den foreslås til nettopp dette formålet i mange tråder. En relay er en separat komponent med sin egen konfigurasjon og sine egne feilmoduser. Å anta at et eksisterende alternativ allerede dekker det, er den vanligste grunnen til at denne undersøkelsen stopper opp.

Multicast-oppdagelse har samme problem med en annen adresseklasse, og den trenger multicast-ruting eller en relay i stedet for et broadcast-unntak.

Når en relay er berettiget, hold den smal

Hvis automatisk oppdagelse er et krav, identifiser først den faktiske utvekslingen: broadcast eller multicast, destinasjonsadresse, UDP-port, grensesnittet som sender den, og adressen inne i svaret. En protokollpassende relay begrenset til disse fem fakta er langt smalere enn å utvide et helt Ethernet-segment.

Videresending av pakken uendret kan fortsatt være utilstrekkelig. Hvis nyttelasten forteller mottakeren å koble til en adresse den ikke kan nå, leverer relayen et ubrukelig svar, og derfor bør spillets eget grensesnitt eller innstillingen for annonsert adresse prøves før noen relay finnes.

Begrens relayen til grensesnittene og peerne som trenger den, og definer hvordan svar finner den som spør. Å gjenta uvedkommende broadcasts eksponerer andre lokale tjenester og lager løkker som er vonde å feilsøke senere.

Bro bare når designet trenger Ethernet

Ethernet-rammer reiser inne i TAP, så en TAP-tunnel kan tilhøre et bevisst broet broadcast-domene. Bare det å bytte dev tun til dev tap bygger ikke den broen, gjør ikke serverkonfigurasjonen kompatibel og får ikke applikasjonen til å velge det nye grensesnittet. OpenVPNs broveiledning beskriver den bredere ordningen, ikke en kur mot én tom lobby.

Broing flater også ut adresseplanen, og derfor fortjener beslutningen en grunn utover utålmodighet. To nettverk som var adskilte blir ett, og hver tjeneste på hver side begynner å se den andre sidens broadcasts. Den konsekvensen hører hjemme i endringsloggen før noen aktiverer den. Det finnes ingen regel om at spillklienter må ligge i et 192.168-område; velg en plan uten overlapp og sjekk begrensningene til det enkelte spillet i stedet for å omnummerere tunnelen fordi et foruminnlegg gjorde det.

Hold de to resultatene adskilt til slutt: om verten kan nås, og om oppdagelsessvaret annonserer en destinasjon som den andre spilleren faktisk kan bruke. Å rette det andre uten å bekrefte det første er måten folk ender opp med å vedlikeholde en bro for et problem som aldri handlet om broadcast.