Bakit nabigo ang paghahanap ng pangalan sa rutadong OpenVPN tunnel

Sinasagot ng host ang ping sa pamamagitan ng address at nabigo sa bawat paghahanap sa pangalan. Nakataas ang tunnel at may ruta, kaya ang likas na kongklusyon ay mali ang pagkakaayos ng VPN. Mas kapaki-pakinabang na kongklusyon ay kailanman hindi nairuta ang paghahanap: ang rutadong tunnel ay nagdadala ng unicast IP, samantalang ang tanong ay isang broadcast na naghahanap ng segment na wala sa kabilang dulo. Kapag nakita na ang diperensya ng mga layer, ang mga pagwawasto ay kusang nag-aayos ayon sa gastos.

Mito: sira ang tunnel dahil nabigo ang mga pangalan

Nakakumbinsi ang sintomas dahil gumagana ang lahat sa itaas ng layer ng pangalan. Nairuruta ang mga address, nakataas ang interface, at sinasagot ng kapares ang ping. Ang nabigo ay mekanismo ng pagtuklas na kailanman walang daan sa isang point-to-point na link, at ibang pahayag iyon kaysa sa sirang tunnel. Ang paghihiwalay ng dalawang pahayag na iyon ang malaking bahagi ng diagnosis.

Ang ituring itong sira ng tunnel ay humahantong sa mga pagbabago sa profile na hindi makakatulong. Ang pagdagdag ng opsyon, pagpalit ng encryption o muling pag-install ng kliyente ay iniiwan ang broadcast sa dating kinaroroonan.

Pangalanan ang mekanismong nabigo bago pangalanan ang pagwawasto. Ang paghahanap na gumagamit ng broadcast ay nangangailangan ng segment, samantalang ang paghahanap na gumagamit ng resolver ay nangangailangan ng address na tatanungin.

Ano ang dinadala ng TUN at ano ang hindi

Ang TUN device ay isang IP interface, at iyon ang dahilan kung bakit ito nairuruta. Binibigyan ng OpenVPN ang kliyente ng address at set ng ruta, at mula noon ay nagpapadala ang kliyente ng datagram sa kapares. Walang anuman sa modelong iyon ang lumilikha ng pinagsasaluhang link kung saan naririnig ng bawat host ang bawat frame.

Ang trapik ng pagtuklas ay hindi umaangkop sa modelong iyon. Ang lumang tanong sa pangalan ng Windows, mga anunsyo ng SSDP at mga hiling ng mDNS ay ipinapadala sa lahat sa isang segment kaysa sa isang destinasyon. Ang rutadong link ay walang «lahat» na padadalhan. Ang bawat isa sa mga mekanismong iyon ay ipinapalagay ang pinagsasaluhang midyum.

Kaya maaaring malusog ang tunnel habang ganap na nabigo ang pagtuklas. Iyon ang pangungusap na dapat hawakan kapag may nag-ulat na bumagsak ang VPN.

Gumagana ang tulay sa pag-alis ng hangganan

Ang TAP device ay nagdadala ng frame, at ikinakabit ito ng tulay sa tunay na LAN segment. Nagkakaroon noon ang kliyente ng address sa segment na iyon at naririnig ang trapik ng broadcast nito. Iyon ang dahilan kung bakit parang nagpapagaling ang tulay sa problema ng pangalan. Ginagawa rin nitong umaasa ang kliyente sa segment na iyon para sa pag-address.

Ang lunas ay pag-alis ng hangganan ng ruta, hindi bagong kakayahan sa pagbibigay ng pangalan sa loob ng tunnel. Lahat ng ibinobroadcast ng segment ay tumatawid na rin ngayon sa link.

Para sa maliit na laboratoryo ito ay patas na palitan. Sa kumalat na manggagawa, bihira.

Ang pagtulak ng DNS at WINS ang mas makitid na pagwawasto

Bigyan ang kliyente ng tiyak na lugar na tatanungin. Ang dhcp-option DNS at dhcp-option DOMAIN ay nagtuturo ng panloob na pangalan sa server na nakakaalam ng zone, at ang kliyenteng Windows na umaasa pa rin sa NetBIOS ay makakatanggap ng WINS server sa parehong paraan. Nananatiling rutado ang tunnel at nananatili ang segment sa dapat nitong kalagyan.

Dalawang kondisyon ang nagpapasya kung ito ay gagana. Ang tinukoy na server ay dapat sumagot para sa zone, at ang tanong ay dapat payagan sa tunnel.

Subukan ang resolver mula sa kliyente at hindi mula sa shell ng server mismo. Ang resolver na gumagana lokal ay walang sinasabi tungkol sa dinadala ng tunnel.

Alamin kung aling layer ang nabigo

Ping muna ang address, pagkatapos lutasin ang pangalan at basahin kung aling server ang sumagot. Ang negatibong sagot mula sa server na hindi nagho-host ng zone ay iba ang itsura kaysa sa tanong na kailanman hindi lumabas sa makina. Ang pangalang nalulutas pero tumatanggi sa koneksyon ay ikatlong problema nang ganap.

Ang multicast ay nasa likod ng parehong pader. Ang grupong tulad ng 224.0.0.251 ay hindi ipinapasa sa rutadong tunnel bilang default, at ang ruta para sa grupo ay hindi sapat kung walang daang nakakaunawa ng multicast o reflector sa LAN.