Tukšs LAN spēļu saraksts ar OpenVPN? Pārbaudiet atklāšanas ceļu
Atrast mitinātu spēli un tai pievienoties ir divi atšķirīgi ceļi. Pārbaudiet sesijas adresi, izlasiet, ko sludina vestibils, un tad izsveriet releju pret tiltu.
Pingot cita spēlētāja tuneļa adresi un redzēt viņa mitināto spēli ir divi dažādi sasniegumi. Vestibila saraksts parasti ir atkarīgs no atklāšanas apmaiņas, kas rakstīta vienam vietējam tīklam, bet spēles sesija ir parasts savienojums ar adresi un portu. Tukšu sarakstu uzskatīt par maršrutēšanas kļūdu nozīmē doties uz tiltu, kas var nebūt vajadzīgs, tāpēc atdaliet abus jautājumus pirms kaut ko mainīt.
Atdaliet pievienošanos sesijai no tās atrašanas
Neveiksmīga pievienošanās norāda uz maršrutiem, ugunsmūra noteikumiem un klausošos pakalpojumu. Veiksmīga pievienošanās ar tukšu sarakstu norāda uz atklāšanu vai adresi, ko nes sludinājums. Šie divi iznākumi ved uz pilnīgi atšķirīgu darbu, un tos var atšķirt tikai tad, ja apzināti izmēģināt pirmo.
Pierakstiet rezultātu pirms VPN konfigurācijas aizskaršanas. Tas ir lētākais tests visā izmeklēšanā, un tas novērš pusi no projektēšanas telpas. Pierakstiet arī izmantoto adresi, jo tā kļūst par atskaites punktu katram vēlākajam testam. Bez šīs rindas piezīmēs nākamais salīdzinājums ir minējums.
Pārbaudiet tiešu pievienošanos pirms tuneļa aizskaršanas
Ja spēle piedāvā tiešas savienojuma iespēju, izmantojiet resursdatora tuneļa adresi un dokumentēto spēles portu, un atstājiet pašas spēles autentifikāciju un resursdatora ugunsmūra noteikumus neskartus. Veiksmīga pievienošanās sašaurina problēmu līdz atklāšanai. Neveiksmīga pievienošanās joprojām prasa savu izmeklēšanu, un neviens relejs to neizlabos.
Neuzskatiet, ka atklāšanas ports un sesijas ports ir viens un tas pats skaitlis. Spēles parasti sludina vienā UDP portā un pieņem spēlētājus citā, un relejs, kas būvēts nepareizajam, dod sarakstu, kas joprojām paliek tukšs.
Pārbaudiet arī, kuru adapteri izvēlējās mitināšanas process. Process, kas piesaistīts mājas LAN adresei, sludinās šo adresi, un attālinātais spēlētājs nevar uz to maršrutēt pat tad, kad sludinājums pienāk. Saraksts var piepildīties, un pievienošanās joprojām var neizdoties tikai šī iemesla dēļ.
Saprotiet, kur apstājas apraide
Maršrutēts TUN tunelis pārvieto IP paketes starp vienaudžiem un neatveido vietējo apraidi katra vienaudža tīklā. Ierobežotā apraides adrese 255.255.255.255 paliek tās saskarnes iekšpusē, kas to izstaro, un uz apakštīklu vērsta apraide ir atsevišķs gadījums, nevis vispārēja licence maršrutētājiem pārpludināt sludinājumus.
Tā ir dizaina īpašība, nevis defekts, ko lāpīt ar opciju. OpenVPN un tā client-to-client iestatījums pārvalda vienaudžu datplūsmu tuneļa iekšienē un nav atklāšanas relejs, lai gan daudzās diskusijās tas tiek ieteikts tieši šim nolūkam. Relejs ir atsevišķa komponente ar savu konfigurāciju un saviem kļūmes režīmiem. Pieņēmums, ka esošā opcija to jau sedz, ir visbiežākais iemesls, kāpēc šī izmeklēšana iestrēgst.
Multicast atklāšanai ir tā pati problēma ar citu adrešu klasi, un tai vajag multicast maršrutēšanu vai releju, nevis apraides izņēmumu.
Kad relejs ir attaisnots, turiet to šauru
Ja automātiskā atklāšana ir prasība, vispirms identificējiet faktisko apmaiņu: apraide vai multicast, galamērķa adrese, UDP ports, saskarne, kas to sūta, un adrese atbildes iekšienē. Protokolam atbilstošs relejs, kas ierobežots ar šiem pieciem faktiem, ir daudz šaurāks nekā visa Ethernet segmenta paplašināšana.
Paketes pārsūtīšana bez izmaiņām joprojām var būt nepietiekama. Ja lietderīgā slodze liek uztvērējam savienoties ar adresi, kuru tas nevar sasniegt, relejs piegādā bezjēdzīgu atbildi, tāpēc pašas spēles saskarne vai sludinātās adreses iestatījums jāizmēģina pirms jebkāda releja pastāvēšanas.
Ierobežojiet releju ar tām saskarnēm un vienaudžiem, kuriem tas vajadzīgs, un definējiet, kā atbildes atrod pieprasītāju. Nesaistītu apraižu atkārtošana atklāj citus vietējos pakalpojumus un rada cilpas, kuras vēlāk ir grūti atkļūdot.
Tilts tikai tad, ja dizainam vajag Ethernet
Ethernet kadri ceļo TAP iekšienē, tāpēc TAP tunelis var piederēt apzināti pārtilpotam apraides domēnam. Vienkārši dev tun nomaiņa uz dev tap neveido šo tiltu, nepadara servera konfigurāciju saderīgu un neliek lietojumprogrammai izvēlēties jauno saskarni. OpenVPN tiltu rokasgrāmata apraksta plašāku izkārtojumu, nevis vienas tukšas vestibila zāles ārstēšanu.
Tiltošana arī izlīdzina adrešu plānu, tāpēc lēmums pelna iemeslu, kas pārsniedz nepacietību. Divi tīkli, kas bija atsevišķi, kļūst par vienu, un katrs pakalpojums abās pusēs sāk redzēt otras puses apraides. Šīs sekas pieder izmaiņu žurnālam pirms kāds to ieslēdz. Nav noteikuma, ka spēļu klienti jāizvieto 192.168 diapazonā; izvēlieties nepārklājošu plānu un pārbaudiet konkrētās spēles ierobežojumus, nevis pārnumurējiet tuneli tāpēc, ka kāds foruma ieraksts tā izdarīja.
Beigās turiet abus rezultātus atsevišķi: vai resursdatoram var pievienoties, un vai atklāšanas atbilde sludina galamērķi, ko otrs spēlētājs tiešām var izmantot. Otrā labošana, neapstiprinot pirmo, ir veids, kā cilvēki beigās uztur tiltu problēmai, kas nekad nav bijusi par apraidi.