Nagpadala ang OpenVPN ng DNS server, pero hindi ito pinapansin ng Linux

Nasa log ang ipinadalang DNS server, nakaangat ang tunel, at nabibigo pa rin ang mga panloob na pangalan. Walang sira sa pagpapadala mismo; dumating ang setting at doon ito tumigil. Ang ipinadalang opsyon sa DNS ay mensahe sa kliyente, hindi utos sa resolver ng operating system, at ang paglilipat sa pagitan nila ang lugar kung saan nagtatapos ang karamihan sa mga kasong ito. Limang pagsusuri, sa pagkakasunod-sunod, ang nakakahanap ng paglilipat na hindi nangyari.

Pagsusuri isa: paano nagsisimula ang koneksyon

Ang may-ari ng koneksyon ang nagtatakda kung sino ang makakagamit ng mga setting ng resolver. Ang direktang openvpn command mula sa shell ay walang pag-aari maliban sa sarili nitong proseso, samantalang ang systemd unit, NetworkManager o kliyente ng vendor ay may kanya-kanyang paraan ng paglathala ng DNS. Basahin ang listahan ng proseso at ang pangalan ng unit bago magpalagay ng alinman sa mga ito.

Ang proseso mula sa command line ay hindi awtomatikong koneksyon ng NetworkManager, at ang koneksyon ng NetworkManager ay hindi awtomatikong ang bagay na nagsulat ng resolv.conf. Ang dalawang palagay na iyon ang nagpapaliwanag sa karamihan ng nasayang na oras sa pagsisiyasat na ito. Itanong kung aling bahagi ang maglalathala ng DNS para sa interface na aktwal mong nakikita.

Isulat ang may-ari bago magpatuloy. Nakasalalay rito ang bawat susunod na pagsusuri.

Pagsusuri dalawa: ano ang aktwal na hawak ng link ng resolver

Sa host na may systemd-resolved, inililista ng resolvectl status ang bawat link kasama ang mga DNS server at domain nito. Hanapin ang link ng tunel at basahin ang mga entry nito, at huwag ipagpalagay na ang interface ay tinatawag na tun0, dahil sinusundan ng pagnunumero ang pagkakasunod-sunod ng paggawa. Kung wala sa link ang ipinadalang address, ang paglilipat ang nabigo, hindi ang query.

Kung naroon ang address, ang susunod na tanong ay aling mga domain ang inaangkin ng link na iyon. Ang link na walang listahan ng domain ay sumasagot lamang sa mga pangalang direktang tinatanong dito, at bihirang ito ang gusto ng isang deployment na split-DNS. Ang address lamang ay kailangan ngunit hindi sapat.

Ihambing ang pangalan ng link sa output ng resolver sa pangalan ng interface sa log ng VPN bago magbuo ng anumang konklusyon. Ang pagkakaiba doon ay karaniwang nangangahulugang ang linya sa log ay galing sa ibang proseso.

Pagsusuri tatlo: pinipili ba ng namespace ang link na iyon

Maaaring taglayin ng resolver ang tamang server at hindi pa rin ito konsultahin. Ang domain sa bawat link ang nagtatakda kung aling query ang pupunta sa aling link, at kung walang routing domain ay bumabalik ang pribadong namespace sa sinasabi ng default na link. Ito ang dahilan kung bakit ang resolvectl query para sa panloob na pangalan ay maaaring magtagumpay habang nabibigo pa rin ang aplikasyon. Maaaring gumagamit ang aplikasyon ng ganap na ibang landas ng resolver.

Suriin ang pagtatalaga ng domain, hindi lamang ang address ng server. Ang domain na nakasulat bilang ~corp.example ay routing domain, at binabago ng tilde ang paraan ng pagtutugma ng pangalan.

Kung may sariling resolver ang aplikasyon, subukan gamit ang parehong mekanismong ginagamit nito sa halip na ang tool ng system. Ang tool sa pagtatanong na lumalampas sa resolver ng system ay magtatagumpay anuman ang kalagayan ng link.

Pagsusuri apat: isang may-ari, hindi dalawa

Kung pinamamahalaan na ng NetworkManager ang VPN at ang kalagayan ng resolver, ang pagdaragdag ng hindi kaugnay na hook script ay lumilikha ng magkakatunggaling manunulat. Ang hook na ibinibigay ng package para sa systemd-resolved ay sinusuportahang integrasyon, at umaasa ito sa partikular na lifecycle: script-security 2, isang landas na up, up-restart, isang landas na down at down-pre. Ginagawa ng mga opsyong iyon na mangyari ang pagpaparehistro at pag-alis sa tamang sandali at hindi lamang sa unang koneksyon.

Gamitin ang naka-install na landas mula sa package, hindi ang isang halimbawang kinopya mula sa gabay. Mahalaga rin ang mga pahintulot, dahil tumatakbo ang hook pagkatapos bumaba ang mga pribilehiyo.

Ang pag-edit ng resolver script ng isang distribusyon upang baguhin ang target ng output nito ay nagtatala ng solusyon ng isang host. Hindi ito pangkalahatang pagkukumpuni.

Pagsusuri lima: parehong resulta pagkatapos kumonekta muli

Kumonekta muli at basahin muli ang link. Ang pagpaparehistrong lumilitaw nang isang beses at nawawala sa susunod na paglipat ang sira kung bakit umiiral ang buong checklist na ito. Subukan pagkatapos ng suspend, pagkatapos ng sapilitang muling pagkonekta at pagkatapos ng restart ng serbisyo ng resolver. Sinusubukan ng bawat paglipat ang ibang palagay tungkol sa pagkakasunod-sunod.

Kapag pumasa ang lahat ng limang pagsusuri sa isang muling pagkonekta, saka mo lamang masasabing ginagamit ang ipinadalang mga setting. Ang anumang mas maaga ay larawan ng isang mapalad na sandali.