Malplena LAN-luda listo tra OpenVPN? Kontrolu la malkovran vojon

Pingi la tunelan adreson de alia ludanto kaj vidi lian gastigatan ludon estas du malsamaj atingoj. La listo en la antaŭĉambro kutime dependas de malkovra interŝanĝo verkita por ununura loka reto, dum la luda sesio estas ordinara konekto al adreso kaj pordo. Trakti malplenan liston kiel enkursigan fiaskon sendas vin al ponto, kiun vi eble ne bezonas, do apartigu la du demandojn antaŭ ol ŝanĝi ion.

Apartigu aliĝon al sesio de ĝia trovado

Malsukcesa aliĝo montras al enkursigoj, fajroŝirmilaj reguloj kaj aŭskultanta servo. Sukcesa aliĝo kun malplena listo montras al malkovro, aŭ al la adreso, kiun portas la anonco. Tiuj du rezultoj kondukas al tute malsama laboro, kaj vi povas distingi ilin nur per intenca provo de la unua.

Notu la rezulton antaŭ ol tuŝi la VPN-agordon. Ĝi estas la plej malmultekosta testo en la tuta esploro kaj forigas duonon de la dezajnospaco. Notu ankaŭ la uzitan adreson, ĉar ĝi fariĝas la referenca punkto por ĉiu posta testo. Sen tiu linio en viaj notoj, la sekva komparo estas konjekto.

Provu rektan aliĝon antaŭ ol tuŝi la tunelon

Se la ludo ofertas rektan konekton, uzu la tunelan adreson de la gastiganto kaj la dokumentitan ludan pordon, kaj lasu la propran aŭtentikigon de la ludo kaj la fajroŝirmilajn regulojn de la gastiganto netuŝitaj. Sukcesa aliĝo mallarĝigas la problemon al malkovro. Malsukcesa aliĝo ankoraŭ bezonas propran esploron, kaj neniu relajso riparos ĝin.

Ne supozu, ke la malkovra pordo kaj la sesia pordo estas la sama nombro. Ludoj kutime anoncas sur unu UDP-pordo kaj akceptas ludantojn sur alia, kaj relajso konstruita por la malĝusta donas liston, kiu restas malplena.

Kontrolu ankaŭ, kiun adaptilon elektis la gastiga procezo. Procezo ligita al la hejma LAN-adreso anoncos tiun adreson, kaj la fora ludanto ne povas enkursigi al ĝi eĉ kiam la anonco alvenas. La listo povas pleniĝi kaj la aliĝo povas malsukcesi nur pro tio.

Komprenu, kie dissendo haltas

Enkursigita TUN-tunelo portas IP-paketojn inter samtavolanoj kaj ne reproduktas lokan dissendon en la reto de ĉiu samtavolano. La limigita dissenda adreso 255.255.255.255 restas ene de la interfaco, kiu elsendas ĝin, kaj subret-direktita dissendo estas aparta kazo, ne ĝenerala permeso por enkursigiloj inundi anoncojn.

Tio estas eco de la dezajno, ne difekto flikenda per opcio. OpenVPN kaj ĝia client-to-client agordo regas samtavolan trafikon ene de la tunelo kaj ne estas malkovra relajso, kvankam ĝi estas proponata ĝuste por tiu celo en multaj fadenoj. Relajso estas aparta komponanto kun propra agordo kaj propraj fiaskaj reĝimoj. Supozi, ke ekzistanta opcio jam kovras ĝin, estas la plej ofta kialo, ke ĉi tiu esploro haltas.

Multicast-malkovro havas la saman problemon kun alia adresklaso, kaj ĝi bezonas multicast-enkursigon aŭ relajson, ne dissendan escepton.

Kiam relajso estas pravigita, tenu ĝin mallarĝa

Se aŭtomata malkovro estas postulo, unue identigu la efektivan interŝanĝon: dissendo aŭ multicast, celadreso, UDP-pordo, la interfaco, kiu sendas ĝin, kaj la adreso ene de la respondo. Protokole taŭga relajso limigita al tiuj kvin faktoj estas multe pli mallarĝa ol etendi tutan Ethernet-segmenton.

Plusendi la paketon senŝanĝe ankoraŭ povas esti nesufiĉe. Se la utilaĵo diras al la ricevanto konekti al adreso, kiun ĝi ne povas atingi, la relajso liveras senutilan respondon, do la propra interfaco de la ludo aŭ la agordo de anoncita adreso devus esti provitaj antaŭ ol ekzistas iu relajso.

Limigu la relajson al la interfacoj kaj samtavolanoj, kiuj bezonas ĝin, kaj difinu, kiel respondoj trovas la petanton. Ripetado de nerilataj dissendoj elmetas aliajn lokajn servojn kaj kreas buklojn, kiujn malfacilas sencimigi poste.

Ponto nur kiam la dezajno bezonas Ethernet

Ethernet-kadroj vojaĝas ene de TAP, do TAP-tunelo povas aparteni al intence pontita dissenda domajno. Nur ŝalti de dev tun al dev tap ne konstruas tiun ponton, ne igas la servilan agordon kongrua kaj ne igas la aplikaĵon elekti la novan interfacon. La OpenVPN-pontiga gvidilo priskribas la pli vastan aranĝon, ne kuracilon por unu malplena antaŭĉambro.

Pontigado ankaŭ platigas la adresplanon, tial la decido meritulas kialon preter senpacienco. Du retoj, kiuj estis apartaj, fariĝas unu, kaj ĉiu servo ambaŭflanke komencas vidi la dissendojn de la alia flanko. Tiu sekvo apartenas al la ŝanĝprotokolo antaŭ ol iu ajn ŝaltas ĝin. Ne ekzistas regulo, ke ludklientoj devas sidi en 192.168-gamo; elektu planon sen interkovro kaj kontrolu la limigojn de la koncerna ludo anstataŭ renumeri la tunelon ĉar forumafiŝo tion faris.

Fine tenu la du rezultojn apartaj: ĉu oni povas aliĝi al la gastiganto, kaj ĉu la malkovra respondo anoncas celon, kiun la alia ludanto efektive povas uzi. Ripari la duan sen konfirmi la unuan estas kiel homoj finas prizorgante ponton por problemo, kiu neniam temis pri dissendo.