Walang laman ang Listahan ng LAN Games sa OpenVPN? Suriin ang Daan ng Pagtuklas

Ang pag-ping sa tunnel address ng ibang manlalaro at ang makita ang naka-host niyang laro ay dalawang magkaibang tagumpay. Ang listahan sa lobby ay karaniwang nakadepende sa palitan ng pagtuklas na isinulat para sa isang lokal na network, samantalang ang session ng laro ay ordinaryong koneksyon sa isang address at port. Ang ituring na kabiguan sa routing ang walang laman na listahan ay magdadala sa iyo sa tulay na maaaring hindi mo kailangan, kaya paghiwalayin ang dalawang tanong bago magbago ng anuman.

Paghiwalayin ang pagsali sa session sa paghahanap nito

Ang nabigong pagsali ay tumuturo sa mga ruta, patakaran ng firewall at serbisyong nakikinig. Ang matagumpay na pagsali na may walang laman na listahan ay tumuturo sa pagtuklas, o sa address na dala ng anunsyo. Ang dalawang resultang ito ay patungo sa lubos na magkaibang gawain, at maihihiwalay mo lamang sila sa pamamagitan ng sadyang pagsubok sa una.

Isulat ang resulta bago mo hawakan ang configuration ng VPN. Ito ang pinakamurang pagsubok sa buong pagsisiyasat at inaalis ang kalahati ng espasyo ng disenyo. Itala rin ang address na ginamit mo, dahil ito ang magiging batayan para sa bawat susunod na pagsubok. Kung wala ang linyang iyon sa iyong mga tala, ang susunod na paghahambing ay haka-haka lamang.

Subukan ang direktang pagsali bago hawakan ang tunnel

Kung nag-aalok ang laro ng direktang koneksyon, gamitin ang tunnel address ng host at ang dokumentadong port ng laro, at iwanang buo ang sariling authentication ng laro at ang mga patakaran ng firewall ng host. Ang matagumpay na pagsali ay nagpapaliit ng problema sa pagtuklas. Ang nabigong pagsali ay kailangan pa rin ng sariling pagsisiyasat, at walang relay ang makakaayos nito.

Huwag ipagpalagay na ang port ng pagtuklas at ang port ng session ay parehong numero. Ang mga laro ay karaniwang nag-anunsyo sa isang UDP port at tumatanggap ng manlalaro sa iba, at ang relay na ginawa para sa maling port ay nagbibigay ng listahang nananatiling walang laman.

Suriin din kung aling adapter ang pinili ng proseso ng pagho-host. Ang prosesong nakatali sa address ng LAN sa bahay ay mag-anunsyo ng address na iyon, at hindi ito marurutan ng malayong manlalaro kahit dumating ang anunsyo. Maaaring mapuno ang listahan at maaaring mabigo pa rin ang pagsali dahil lamang doon.

Unawain kung saan humihinto ang broadcast

Ang naka-route na TUN tunnel ay nagdadala ng IP packet sa pagitan ng mga peer at hindi nagre-reproduce ng lokal na broadcast sa network ng bawat peer. Ang limitadong broadcast address 255.255.255.255 ay nananatili sa loob ng interface na naglalabas nito, at ang broadcast na nakadirekta sa subnet ay hiwalay na kaso, hindi pangkalahatang lisensya para sa mga router na bumaha ng anunsyo.

Ito ay katangian ng disenyo, hindi depektong tatahiin ng isang opsyon. OpenVPN at ang client-to-client setting nito ay namamahala sa trapiko ng mga peer sa loob ng tunnel at hindi ito relay ng pagtuklas, kahit iminumungkahi ito para sa layuning ito sa maraming thread. Ang relay ay hiwalay na bahagi na may sariling configuration at sariling mga paraan ng pagkasira. Ang pag-aakalang sakop na ito ng umiiral na opsyon ay ang pinakakaraniwang dahilan kung bakit natitigil ang pagsisiyasat na ito.

Ang pagtuklas ng multicast ay may parehong problema sa ibang klase ng address, at kailangan nito ng multicast routing o relay sa halip na eksepsyon sa broadcast.

Kapag makatwiran ang relay, panatilihin itong makitid

Kung kinakailangan ang awtomatikong pagtuklas, tukuyin muna ang tunay na palitan: broadcast o multicast, patutunguhang address, UDP port, ang interface na nagpapadala nito, at ang address sa loob ng tugon. Ang relay na angkop sa protocol at limitado sa limang katotohanang iyon ay mas makitid kaysa sa pagpapalawak ng buong Ethernet segment.

Ang pagpapasa ng packet nang walang pagbabago ay maaaring hindi pa sapat. Kung sinasabi ng payload sa tatanggap na kumonekta sa isang address na hindi niya maabot, naghahatid ang relay ng walang silbing sagot, kaya dapat subukan ang sariling interface ng laro o ang setting ng inanunsyong address bago pa man magkaroon ng anumang relay.

Limitahan ang relay sa mga interface at peer na nangangailangan nito, at tukuyin kung paano hinahanap ng mga sagot ang humihiling. Ang pag-uulit ng walang kaugnayang broadcast ay naglalantad ng iba pang lokal na serbisyo at lumilikha ng mga loop na mahirap i-debug sa kalaunan.

Tulay lamang kapag kailangan ng disenyo ang Ethernet

Ang mga Ethernet frame ay naglalakbay sa loob ng TAP, kaya ang TAP tunnel ay maaaring kabilang sa sadyang nakatulay na broadcast domain. Ang basta dev tun sa dev tap ay hindi nagtatayo ng tulay na iyon, hindi ginagawang compatible ang configuration ng server at hindi pinipilit ang application na piliin ang bagong interface. Ang gabay sa tulay ng OpenVPN ay naglalarawan ng mas malawak na kaayusan, hindi lunas sa isang walang laman na lobby.

Pinapantay rin ng pagtulay ang plano ng address, kaya ang desisyon ay karapat-dapat sa dahilan bukod sa kawalan ng pasensya. Ang dalawang network na magkahiwalay ay nagiging isa, at bawat serbisyo sa magkabilang panig ay nagsisimulang makita ang broadcast ng kabila. Ang kahihinatnan ay dapat nasa talaan ng pagbabago bago pa ito buksan ng sinuman. Walang tuntuning kailangang nasa 192.168 range ang mga kliyente ng laro; pumili ng planong walang overlap at suriin ang mga paghihigpit ng partikular na laro sa halip na muling bilangin ang tunnel dahil ginawa iyon ng isang post sa forum.

Sa huli, panatilihing magkahiwalay ang dalawang resulta: kung masasalihan ang host, at kung ang sagot ng pagtuklas ay nag-anunsyo ng patutunguhang tunay na magagamit ng ibang manlalaro. Ang ayusin ang pangalawa nang hindi kumpirmado ang una ay ang paraan kung bakit nagtatapos ang mga tao sa pagpapanatili ng tulay para sa problemang hindi kailanman tungkol sa broadcast.