Tuščias LAN žaidimų sąrašas per OpenVPN? Patikrinkite aptikimo kelią

Pinginti kito žaidėjo tunelio adresą ir matyti jo priglobtą žaidimą yra du skirtingi pasiekimai. Lobby sąrašas paprastai priklauso nuo aptikimo pasikeitimo, parašyto vienam vietiniam tinklui, o žaidimo sesija yra įprastas ryšys su adresu ir prievadu. Tuščią sąrašą laikant maršrutizavimo klaida nukreipiama link tilto, kurio galbūt nereikia, todėl atskirkite du klausimus prieš ką nors keisdami.

Atskirkite prisijungimą prie sesijos nuo jos radimo

Nepavykęs prisijungimas rodo maršrutus, ugniasienės taisykles ir klausančią paslaugą. Sėkmingas prisijungimas su tuščiu sąrašu rodo aptikimą arba adresą, kurį neša skelbimas. Šie du rezultatai veda prie visiškai skirtingo darbo, ir juos atskirti galite tik sąmoningai išbandę pirmąjį.

Užrašykite rezultatą prieš liesdami VPN konfigūraciją. Tai pigiausias viso tyrimo bandymas ir jis pašalina pusę projektavimo erdvės. Užsirašykite ir naudotą adresą, nes jis taps atskaitos tašku kiekvienam vėlesniam bandymui. Be šios eilutės užrašuose kitas palyginimas bus spėjimas.

Išbandykite tiesioginį prisijungimą prieš liesdami tunelį

Jei žaidimas siūlo tiesioginio ryšio parinktį, naudokite prieglobos serverio tunelio adresą ir dokumentuotą žaidimo prievadą, o paties žaidimo autentifikavimą ir prieglobos serverio ugniasienės taisykles palikite nepakeistus. Sėkmingas prisijungimas susiaurina problemą iki aptikimo. Nepavykęs prisijungimas vis tiek reikalauja savo tyrimo, ir jokia relė jo nepataisys.

Nemanikite, kad aptikimo prievadas ir sesijos prievadas yra tas pats skaičius. Žaidimai paprastai skelbia vienu UDP prievadu ir priima žaidėjus kitu, o rele, pastatyta netinkamam, pateikia sąrašą, kuris vis tiek lieka tuščias.

Patikrinkite ir tai, kokį adapterį pasirinko prieglobos procesas. Prie namų LAN adreso pririštas procesas skelbs tą adresą, o nuotolinis žaidėjas negali į jį maršrutizuoti net tada, kai skelbimas ateina. Sąrašas gali prisipildyti, o prisijungimas vis tiek gali nepavykti vien dėl to.

Supraskite, kur sustoja transliacija

Maršrutizuotas TUN tunelis perduoda IP paketus tarp partnerių ir neatkuria vietinės transliacijos kiekvieno partnerio tinkle. Ribotos transliacijos adresas 255.255.255.255 lieka tos sąsajos, kuri jį išsiunčia, viduje, o į potinklį nukreipta transliacija yra atskiras atvejis, o ne bendra licencija maršrutizatoriams užtvindyti skelbimais.

Tai dizaino savybė, o ne defektas, kurį reikia lopyti parinktimi. OpenVPN ir jo client-to-client nustatymas valdo partnerių srautą tunelio viduje ir nėra aptikimo relė, nors daugelyje gijų jis siūlomas būtent šiam tikslui. Relė yra atskiras komponentas su sava konfigūracija ir savais gedimų režimais. Prielaida, kad esama parinktis tai jau apima, yra dažniausia priežastis, kodėl šis tyrimas įstringa.

Multicast aptikimas turi tą pačią problemą su kita adresų klase, ir jam reikia multicast maršrutizavimo arba relės, o ne transliacijos išimties.

Kai relė pateisinama, laikykite ją siaurą

Jei automatinis aptikimas yra reikalavimas, pirmiausia nustatykite faktinį pasikeitimą: transliacija ar multicast, paskirties adresas, UDP prievadas, jį siunčianti sąsaja ir adresas atsakymo viduje. Protokolui tinkama relė, apribota šiais penkiais faktais, yra daug siauresnė nei ištiso Ethernet segmento išplėtimas.

Paketo persiuntimas nepakeisto gali vis tiek būti nepakankamas. Jei naudingoji apkrova liepia gavėjui jungtis prie adreso, kurio jis negali pasiekti, relė pateikia nenaudingą atsakymą, todėl prieš atsirandant bet kokiai relei reikia išbandyti pačios žaidimo sąsają arba skelbiamo adreso nustatymą.

Apribokite relę tomis sąsajomis ir partneriais, kuriems jos reikia, ir apibrėžkite, kaip atsakymai randa prašytoją. Nesusijusių transliacijų kartojimas atskleidžia kitas vietines paslaugas ir sukuria kilpas, kurias vėliau sunku derinti.

Tiltas tik tada, kai dizainui reikia Ethernet

Ethernet kadrai keliauja TAP viduje, todėl TAP tunelis gali priklausyti tyčia tiltu sujungtam transliacijos domenui. Tiesiog dev tun pakeitimas į dev tap nestato to tilto, nepadaro serverio konfigūracijos suderinamos ir nepriverčia programos pasirinkti naujos sąsajos. OpenVPN tiltų vadovas aprašo platesnį išdėstymą, o ne vieno tuščio lobby gydymą.

Tiltas taip pat išlygina adresų planą, todėl sprendimas nusipelno priežasties, didesnės už nekantrumą. Du tinklai, kurie buvo atskiri, tampa vienu, ir kiekviena paslauga abiejose pusėse pradeda matyti kitos pusės transliacijas. Ta pasekmė priklauso pakeitimų žurnalui, kol kas nors ją įjungia. Nėra taisyklės, kad žaidimų klientai turi būti 192.168 diapazone; pasirinkite nepersidengiantį planą ir patikrinkite konkretaus žaidimo apribojimus, o ne pernumeruokite tunelį todėl, kad forumo įrašas taip padarė.

Pabaigoje laikykite du rezultatus atskirai: ar galima prisijungti prie prieglobos serverio, ir ar aptikimo atsakymas skelbia paskirties vietą, kurią kitas žaidėjas iš tikrųjų gali naudoti. Antrojo taisymas nepatvirtinus pirmojo yra būdas, kuriuo žmonės galiausiai prižiūri tiltą problemai, kuri niekada nebuvo apie transliaciją.