DNS ng OpenVPN sa gateway: dnsmasq at saklaw ng firewall

Patakbuhin ang dnsmasq sa address ng tunnel, payagan ang DNS mula sa pool ng kliyente lamang, itulak ang resolver, pagkatapos subukan ang direktang query at ang sariling paghahanap ng app.

Naabot ng mga kliyente sa tunnel ang gateway, at naabot ng gateway ang panloob na resolver, kaya dapat gumana ang DNS. Hindi ito gumagana, dahil dalawang magkaibang pahintulot ang mga iyon at ang gumaganang serbisyo ng DNS ay ikatlong bagay. Dapat may listener sa address na naaabot ng mga kliyente, dapat payagan ng firewall ang mga query sa address na iyon, at dapat sabihan ang kliyente na gamitin ito. Ang pagbukas ng tunnel sa dalawang direksyon ay aksidenteng nag-aayos sa unang dalawa at iniiwan ang ikatlo na hindi tapos.

Ang listener ay lokal na serbisyo na may dalawang direksyon

Papasok, nagpapadala ang kliyente ng query sa address ng tunnel ng gateway sa port 53. Papalabas, ipinapasa ng daemon ang query na iyon sa naka-configure nitong upstream. Kailangang gumana ang dalawang kalahati, at nabigo sila sa magkaibang paraan.

Ang timeout na iniuulat ng kliyente at ang timeout na nakikita sa gateway ay hindi iisang sira.

Ibigkis ang address ng tunnel, hindi bawat address

Ang nakalaang instance ng dnsmasq para sa gawaing ito ay nangangailangan ng tahasang listen address, bind mode na tumatanggap sa paglitaw ng tunnel pagkatapos ng pagsisimula, at isang malinaw na upstream. Ito ang pinakamaliit na bersyon na ginagamit ko:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic ibinibigkis ang mga indibidwal na address at hinaharap ang pagdating ng tun0 mamaya, na mahalaga sa host kung saan nagre-restart ang serbisyo ng VPN. Ang paglilista ng loopback ay nagpapanatili sa mga lokal na tool na gumagana nang hindi nagdaragdag ng pampublikong listener. no-resolv pinipigilan ang daemon na magmana ng upstream mula sa resolver configuration ng host, at no-hosts pinipigilan ang instance na ito na ilathala ang hosts file ng gateway. Wala sa mga pagpipiliang iyon ang nagbibigay ng pahintulot sa sinuman na i-query ang serbisyo.

Tingnan kung may umiiral nang listener sa port 53 bago magsimula ng pangalawang daemon, at gamitin ang may-ari ng configuration ng distribution sa halip na ligaw na file sa maling direktoryo.

Payagan ang input ng DNS, hindi ang transit ng tunnel

Ang mga tuntunin ng firewall na nagpapagana nito ay mga lokal na tuntunin sa input na limitado sa interface ng tunnel, pool ng kliyente, address ng gateway at port 53. Sapat na ang dalawang tuntunin, isa sa bawat protocol:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

Tumataas ang DNS sa TCP gayundin sa UDP, kaya ang tuntunin para sa UDP lamang ay nag-iiwan sa malalaking sagot na nabigo sa paraang mukhang paminsan-minsan. Ang mga ito ay hindi ufw route pahintulot, at hindi dapat maging malawak na pahintulot sa tun0. Ang pagkakasunod-sunod ay kasinghalaga ng nilalaman: ang naunang tuntunin na nagtatapon ng lahat ng input mula sa tun0 ay nananalo pa rin, at ang pagdaragdag ng pahintulot sa ilalim ng huling pagtatapon ay walang nililikha.

Kung ang DNS ng gateway ay bahagi na ng disenyo, sadyang repasuhin ang dating patakarang iyon at itala kung bakit.

Ang kalahati ng upstream ay hiwalay na landas

Umaalis ang mga query sa gateway mula sa sarili nitong address patungo sa resolver ng upstream, kaya ang ruta ng gateway at ang patakaran sa labasan patungo sa resolver na iyon ay dapat payagan ang palitan. Ito ay ibang tuntunin kaysa sa nagpapahintulot sa mga kliyente na maabot ang listener, at nabigo ito nang may ibang sintomas.

Huwag magdagdag ng walang limitasyong labasan ng tunnel upang gumana ang mga sagot; hindi ito kailangan ng sinusubaybayan na mga sagot.

Itulak ang opsyon, pagkatapos tingnan ang paghahatid

Maaaring ipahayag ng server ang resolver sa mga kliyente gamit ang itinulak na opsyon. Iyon ay opsyon, hindi utos na dapat sundin ng operating system:

push "dhcp-option DNS 10.90.0.1"

Maaaring kailanganin ng Linux command-line client ang integrasyon ng resolver ng connection manager nito, at maaaring kailanganin ng pinamamahalaang device ang na-update na management profile. Pagkatapos kumonekta, kumpirmahin ang aktibong resolver sa kliyente sa halip na ipagpalagay na inilapat ang pagtulak. Kapag dalawang mekanismo ang sabay na nagtatangkang magtakda ng DNS, nakakakuha ka ng karera na lumalabas na kumikislap na resolusyon.

Ang layunin ay isang may-ari ng configuration ng resolver ng kliyente, at ang pagtulak ay karaniwang ang may-ari na iyon lamang kapag pumayag ang platform ng kliyente.

Subukan ang aktwal na itinayo mo

I-query ang isang pribadong ganap na kwalipikadong pangalan at isang pinapayagang panlabas na pangalan nang direkta laban sa address ng tunnel, sa UDP at TCP. Pagkatapos ay ulitin sa karaniwang landas ng paghahanap ng application.

Kung gumagana ang direktang query at nabigo pa rin ang application, ang sira ay sa paghahatid at hindi sa server:

  • Hindi kailanman inilapat ng kliyente ang itinulak na opsyon.
  • May ibang resolver na itinakda mamaya at nanalo sa karera.
  • Ginagamit ng application ang sarili nitong library ng resolver o naka-cache na sagot.

Tapusin sa pagkumpirma na ang pinagmulan sa labas ng aprubadong landas ng VPN ay hindi maaaring gumamit ng listener. Ang matagumpay na resolusyon ay hindi nagbibigay ng awtorisasyon sa address na ibinalik nito, kaya panatilihing hiwalay ang dalawang tanong na iyon.

Kaugnay na mga artikulo