Listë bosh e lojërave LAN përmes OpenVPN? Kontrolloni rrugën e zbulimit

Të pingosh adresën e tunelit të një lojtari tjetër dhe të shohësh lojën e tij të strehuar janë dy arritje të ndryshme. Lista në lobi zakonisht varet nga një shkëmbim zbulimi i shkruar për një rrjet të vetëm lokal, ndërsa sesioni i lojës është një lidhje e zakonshme me një adresë dhe një portë. Ta trajtosh një listë bosh si dështim rrugëtimi të çon drejt një ure që mund të mos të duhet, prandaj ndaj dy pyetjet përpara se të ndryshosh çdo gjë.

Ndaj bashkimin në një sesion nga gjetja e tij

Një bashkim i dështuar tregon rrugë, rregulla muri të zjarrit dhe një shërbim që dëgjon. Një bashkim i suksesshëm me listë bosh tregon zbulimin, ose adresën që mbart njoftimi. Këto dy rezultate çojnë në punë krejt të ndryshme, dhe mund t'i dallosh vetëm duke provuar me qëllim të parin.

Shkruaje rezultatin përpara se të prekësh konfigurimin e VPN-së. Është testi më i lirë në të gjithë hetimin dhe eliminon gjysmën e hapësirës së projektimit. Shëno edhe adresën që përdore, sepse bëhet pika e referencës për çdo test të mëvonshëm. Pa atë rresht në shënimet e tua, krahasimi tjetër është vetëm hamendje.

Provo një bashkim të drejtpërdrejtë përpara se të prekësh tunelin

Nëse loja ofron opsionin e lidhjes së drejtpërdrejtë, përdor adresën e tunelit të strehuesit dhe portën e dokumentuar të lojës, dhe lëri të paprekura vërtetimin e vetë lojës dhe rregullat e murit të zjarrit të strehuesit. Një bashkim i suksesshëm e ngushton problemin në zbulim. Një bashkim i dështuar ende kërkon hetimin e vet, dhe asnjë rele nuk e rregullon atë.

Mos supozo që porta e zbulimit dhe porta e sesionit janë i njëjti numër. Lojërat zakonisht shpallin në një portë UDP dhe pranojnë lojtarë në një tjetër, dhe një rele i ndërtuar për të gabuarën jep një listë që mbetet bosh.

Kontrollo edhe cilin përshtatës zgjodhi procesi i strehimit. Një proces i lidhur me adresën e LAN-it të shtëpisë do të shpallë atë adresë, dhe lojtari i largët nuk mund të rrugëtojë drejt saj edhe kur njoftimi arrin. Lista mund të mbushet dhe bashkimi mund të dështojë vetëm për këtë arsye.

Kupto ku ndalon transmetimi

Një tunel TUN i rrugëtuar mbart paketa IP midis kolegëve dhe nuk riprodhon transmetimin lokal në rrjetin e secilit koleg. Adresa e kufizuar e transmetimit 255.255.255.255 mbetet brenda ndërfaqes që e nxjerr, dhe transmetimi i drejtuar drejt një nënrrjete është rast më vete, jo një licencë e përgjithshme që ruterat të përmbytin njoftimet.

Kjo është veti e projektimit, jo defekt që mbyllet me një opsion. OpenVPN dhe client-to-client cilësimi i tij drejton trafikun midis kolegëve brenda tunelit dhe nuk është rele zbulimi, ndonëse propozohet pikërisht për këtë qëllim në shumë tema. Releja është komponent i veçantë me konfigurimin e vet dhe mënyrat e veta të dështimit. Supozimi se një opsion ekzistues tashmë e mbulon këtë është shkaku më i zakonshëm që ky hetim ngec.

Zbulimi multicast ka të njëjtin problem me një klasë tjetër adresash, dhe kërkon rrugëtim multicast ose një rele, jo një përjashtim transmetimi.

Kur një rele justifikohet, mbaje të ngushtë

Nëse zbulimi automatik është kërkesë, së pari identifiko shkëmbimin e vërtetë: transmetim apo multicast, adresa e destinacionit, porta UDP, ndërfaqja që e dërgon, dhe adresa brenda përgjigjes. Një rele i përshtatshëm për protokollin dhe i kufizuar në këto pesë fakte është shumë më i ngushtë sesa zgjerimi i një segmenti të tërë Ethernet.

Përcjellja e paketës pa ndryshime mund të mos mjaftojë. Nëse ngarkesa i thotë marrësit të lidhet me një adresë që nuk e arrin, releja jep një përgjigje të pavlefshme, prandaj ndërfaqja e vetë lojës ose konfigurimi i adresës së shpallur duhet të provohen përpara se të ekzistojë ndonjë rele.

Kufizo relejen në ndërfaqet dhe kolegët që kanë nevojë për të, dhe përcakto si përgjigjet e gjejnë kërkuesin. Përsëritja e transmetimeve të palidhura ekspozon shërbime të tjera lokale dhe krijon unaza që më vonë janë të dhimbshme për t'u korrigjuar.

Urë vetëm kur projektimi kërkon Ethernet

Kornizat Ethernet udhëtojnë brenda TAP, kështu që një tunel TAP mund t'i përkasë një domeni transmetimi të lidhur qëllimisht me urë. Thjesht dev tun në dev tap nuk e ndërton atë urë, nuk e bën konfigurimin e serverit të pajtueshëm dhe nuk e detyron aplikacionin të zgjedhë ndërfaqen e re. Udhëzuesi i urave i OpenVPN përshkruan rregullimin më të gjerë, jo një kurë për një lobi bosh.

Uratëzimi rrafshon edhe planin e adresave, prandaj vendimi meriton një arsye përtej padurimit. Dy rrjete që ishin të ndarë bëhen një, dhe çdo shërbim në secilën anë fillon të shohë transmetimet e anës tjetër. Ajo pasojë i takon regjistrit të ndryshimeve përpara se dikush ta aktivizojë. Nuk ka rregull që klientët e lojërave duhet të jenë në intervalin 192.168; zgjidh një plan pa mbivendosje dhe kontrollo kufizimet e lojës konkrete në vend që të rinumërosh tunelin sepse një postim forumi e bëri këtë.

Në fund mbaj dy rezultatet të ndara: nëse mund t'i bashkohesh strehuesit, dhe nëse përgjigja e zbulimit shpall një destinacion që lojtari tjetër vërtet mund ta përdorë. Rregullimi i të dytit pa konfirmuar të parin është mënyra se si njerëzit përfundojnë duke mirëmbajtur një urë për një problem që nuk kishte të bënte kurrë me transmetimin.