Tühi LAN-mängude nimekiri OpenVPN-i kaudu? Kontrolli avastusteekonda

Teise mängija tunneliaadressile pingi saatmine ja tema hostitud mängu nägemine on kaks erinevat saavutust. Lobby nimekiri sõltub tavaliselt avastusvahetusest, mis on kirjutatud ühe kohaliku võrgu jaoks, samas kui mängusessioon on tavaline ühendus aadressi ja pordiga. Tühja nimekirja käsitlemine marsruutimistõrkena suunab sind silla juurde, mida sul võib-olla pole vaja, seega eralda kaks küsimust enne, kui midagi muudada.

Eralda sessiooniga liitumine selle leidmisest

Ebaõnnestunud liitumine viitab marsruutidele, tulemüürireeglitele ja kuulavale teenusele. Õnnestunud liitumine tühja nimekirjaga viitab avastusele või aadressile, mida teade kannab. Need kaks tulemust viivad täiesti erineva tööni ja neid saab eristada ainult esimest teadlikult proovides.

Kirjuta tulemus üles enne, kui puudutad VPN-i konfiguratsiooni. See on kogu uurimise odavaim test ja kõrvaldab poole disainiruumist. Märgi üles ka kasutatud aadress, sest see saab hilisemate testide võrdluspunktiks. Ilma selle reata märkmetes on järgmine võrdlus vaid oletus.

Proovi otsest liitumist enne, kui puudutad tunnelit

Kui mäng pakub otsese ühenduse valikut, kasuta hosti tunneliaadressi ja dokumenteeritud mänguporti ning jäta mängu enda autentimine ja hosti tulemüürireeglid puutumata. Õnnestunud liitumine kitsendab probleemi avastusele. Ebaõnnestunud liitumine vajab endiselt oma uurimist ja ükski relee ei paranda seda.

Ära eelda, et avastusport ja sessiooniport on sama number. Mängud teatavad tavaliselt ühel UDP-pordil ja võtavad mängijaid vastu teisel, ning vale pordi jaoks ehitatud relee annab nimekirja, mis jääb ikkagi tühjaks.

Kontrolli ka, millise adapteri hostimisprotsess valis. Kodu-LAN-i aadressiga seotud protsess teatab selle aadressi ja kaugmängija ei saa sinna marsruutida ka siis, kui teade kohale jõuab. Nimekiri võib täituda ja liitumine võib ikkagi ainult selle tõttu ebaõnnestuda.

Mõista, kus broadcast lõpeb

Marsruuditud TUN-tunnel kannab IP-pakette võrdsete vahel ega taasta kohalikku broadcasti iga võrdse võrgus. Piiratud broadcast-aadress 255.255.255.255 jääb selle väljastava liidese sisse ja alamvõrgu poole suunatud broadcast on eraldi juhtum, mitte üldine litsents ruuteritele teateid üle ujutada.

See on disaini omadus, mitte defekt, mida valikuga lappida. OpenVPN ja selle client-to-client säte reguleerib võrdsete liiklust tunneli sees ega ole avastusrelee, kuigi seda pakutakse paljudes lõimedes just selleks otstarbeks. Relee on eraldi komponent oma konfiguratsiooni ja oma tõrkerežiimidega. Eeldus, et olemasolev valik katab selle juba, on kõige tavalisem põhjus, miks see uurimine takerdub.

Multicast-avastusel on sama probleem teise aadressiklassiga ja see vajab multicast-marsruutimist või releed, mitte broadcast-erandit.

Kui relee on õigustatud, hoia see kitsas

Kui automaatne avastus on nõue, tuvasta esmalt tegelik vahetus: broadcast või multicast, sihtaadress, UDP-port, selle saatja liides ja vastuse sees olev aadress. Nende viie faktiga piiratud protokollile sobiv relee on palju kitsam kui terve Ethernet-segmendi laiendamine.

Paketi muutmata edasisaatmine ei pruugi siiski piisata. Kui kasulik koormus ütleb vastuvõtjale ühenduda aadressiga, kuhu ta ei ulatu, edastab relee kasutu vastuse, seepärast tuleks enne mis tahes relee olemasolu proovida mängu enda liidest või teatatud aadressi sätet.

Piira relee nende liideste ja võrdsetega, kes seda vajavad, ja määratle, kuidas vastused leiavad küsija. Asjassepuutumatute broadcastide kordamine paljastab teisi kohalikke teenuseid ja loob silmuseid, mida on hiljem tülikas siluda.

Sild ainult siis, kui disain vajab Etherneti

Etherneti kaadrid liiguvad TAP-i sees, seega TAP-tunnel võib kuuluda teadlikult sillatud broadcast-domeeni. Lihtsalt dev tun asendamine dev tap -ga ei ehita seda silda, ei muuda serveri konfiguratsiooni ühilduvaks ega pane rakendust uut liidest valima. OpenVPN-i silla juhend kirjeldab laiemat lahendust, mitte ühe tühja lobby ravimit.

Sillutamine tasandab ka aadressiplaani, mistõttu otsus väärib põhjust enamat kui kannatamatus. Kaks võrku, mis olid eraldi, saavad üheks ja iga teenus mõlemal poolel hakkab nägema teise poole broadcast-e. See tagajärg kuulub muudatuste logisse enne, kui keegi selle sisse lülitab. Pole reeglit, et mängukliendid peavad olema 192.168 vahemikus; vali kattumatu plaan ja kontrolli konkreetse mängu piiranguid, selle asemel et tunnel ümber nummerdada, sest foorumipostitus tegi nii.

Lõpuks hoia kaks tulemust lahus: kas hostiga saab liituda ja kas avastusvastus teatab sihtkoha, mida teine mängija saab tõesti kasutada. Teise parandamine ilma esimest kinnitamata on see, kuidas inimesed lõpuks hooldavad silda probleemi jaoks, mis kunagi broadcasti ei puudutanud.