Listă de jocuri LAN goală prin OpenVPN? Verificați calea de descoperire

A face ping la adresa de tunel a altui jucător și a-i vedea jocul găzduit sunt două realizări diferite. Lista din lobby depinde de obicei de un schimb de descoperire scris pentru o singură rețea locală, în timp ce sesiunea de joc este o conexiune obișnuită la o adresă și un port. A trata o listă goală ca eșec de rutare te îndreaptă spre un pod de care poate nu ai nevoie, așa că separă cele două întrebări înainte de a schimba ceva.

Separă alăturarea la o sesiune de găsirea ei

O alăturare eșuată indică rute, reguli de firewall și un serviciu care ascultă. O alăturare reușită cu listă goală indică descoperirea sau adresa pe care o poartă anunțul. Aceste două rezultate duc la muncă complet diferită, și le poți distinge doar încercând deliberat primul.

Notează rezultatul înainte de a atinge configurația VPN. Este cel mai ieftin test din întreaga investigație și elimină jumătate din spațiul de proiectare. Notează și adresa folosită, pentru că devine punctul de referință pentru fiecare test ulterior. Fără acea linie în notițe, următoarea comparație este o presupunere.

Testează o alăturare directă înainte de a atinge tunelul

Dacă jocul oferă o opțiune de conexiune directă, folosește adresa de tunel a gazdei și portul documentat al jocului, și lasă neatinse autentificarea proprie a jocului și regulile de firewall ale gazdei. O alăturare reușită restrânge problema la descoperire. O alăturare eșuată are în continuare nevoie de propria investigație, iar niciun releu nu o va repara.

Nu presupune că portul de descoperire și portul sesiunii sunt același număr. Jocurile anunță de obicei pe un port UDP și acceptă jucători pe altul, iar un releu construit pentru cel greșit produce o listă care rămâne goală.

Verifică și ce adaptor a ales procesul de găzduire. Un proces legat de adresa LAN-ului de acasă va anunța acea adresă, iar jucătorul îndepărtat nu poate ruta spre ea chiar dacă anunțul ajunge. Lista se poate umple și alăturarea poate eșua doar din acest motiv.

Înțelege unde se oprește difuzarea

Un tunel TUN rutat transportă pachete IP între parteneri și nu reproduce difuzarea locală în rețeaua fiecărui partener. Adresa de difuzare limitată 255.255.255.255 rămâne în interiorul interfeței care o emite, iar o difuzare direcționată către subrețea este un caz separat, nu o licență generală pentru routere să inunde anunțurile.

Aceasta este o proprietate a proiectării, nu un defect de petecat cu o opțiune. OpenVPN și client-to-client setarea lui guvernează traficul dintre parteneri din interiorul tunelului și nu este un releu de descoperire, deși este propusă exact în acest scop în multe fire. Un releu este o componentă separată cu propria configurație și propriile moduri de eșec. Prezumția că o opțiune existentă acoperă deja asta este cel mai frecvent motiv pentru care această investigație se blochează.

Descoperirea multicast are aceeași problemă cu o altă clasă de adrese și necesită rutare multicast sau un releu, nu o excepție de difuzare.

Când un releu este justificat, ține-l îngust

Dacă descoperirea automată este o cerință, identifică mai întâi schimbul real: difuzare sau multicast, adresa de destinație, portul UDP, interfața care îl trimite și adresa din interiorul răspunsului. Un releu potrivit protocolului și limitat la aceste cinci fapte este mult mai îngust decât extinderea unui segment Ethernet întreg.

Trimiterea pachetului neschimbat poate fi totuși insuficientă. Dacă încărcătura îi spune receptorului să se conecteze la o adresă pe care nu o poate atinge, releul livrează un răspuns inutil, de aceea interfața jocului însuși sau setarea adresei anunțate ar trebui încercate înainte de a exista vreun releu.

Limitează releul la interfețele și partenerii care au nevoie de el și definește cum răspunsurile îl găsesc pe solicitant. Repetarea difuzărilor nelegate expune alte servicii locale și creează bucle greu de depanat mai târziu.

Pod doar când proiectarea are nevoie de Ethernet

Cadrele Ethernet călătoresc în interiorul TAP, așa că un tunel TAP poate aparține unui domeniu de difuzare legat prin pod în mod deliberat. Simpla dev tun în dev tap nu construiește acel pod, nu face configurația serverului compatibilă și nu face aplicația să aleagă noua interfață. Ghidul OpenVPN de punți descrie aranjamentul mai larg, nu un remediu pentru un lobby gol.

Puntea aplatizează și planul de adrese, de aceea decizia merită un motiv dincolo de nerăbdare. Două rețele care erau separate devin una, iar fiecare serviciu de fiecare parte începe să vadă difuzările celeilalte părți. Acea consecință aparține registrului de modificări înainte ca cineva să o activeze. Nu există o regulă că clienții de joc trebuie să stea într-un interval 192.168; alege un plan fără suprapunere și verifică restricțiile jocului respectiv în loc să renumerotezi tunelul pentru că un post de forum a făcut asta.

La final ține cele două rezultate separate: dacă se poate intra pe gazdă și dacă răspunsul de descoperire anunță o destinație pe care celălalt jucător chiar o poate folosi. Repararea celui de-al doilea fără confirmarea primului este felul în care oamenii ajung să întrețină un pod pentru o problemă care nu a fost niciodată despre difuzare.