Bigyan ang iyong home VPN ng sarili nitong DNS record para sa nas.home.arpa
I-publish ang isang pangalan mula sa dnsmasq, i-route ang resolver sa WireGuard, pagkatapos pumili sa pagitan ng pagtulak ng DNS sa buong client at split-DNS para lamang sa home.arpa.
Kapag nakaangat na ang tunnel, ang huling hakbang ay karaniwang isang pangalang gumagana sa halip na isang address na ipinapasok mo sa bookmark. Ang host record ng dnsmasq at isang address ng resolver na naaabot ng client ay gumagawa niyon gamit ang dalawang file at walang multicast. Ang desisyong talagang nangangailangan ng pag-iisip ay mas makitid: ipinapadala ba ng client ang lahat ng DNS sa resolver ng bahay, o ang mga pangalan lamang sa ilalim ng home.arpa? Ipinapalagay ng lahat ng nasa ibaba ang isang aprubadong setup ng WireGuard na may client na Linux at resolver sa lab na pinamamahalaan na ng administrador ng bahay.
Tatlong paraan upang bigyan ang client ng resolver
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
Para sa isang laptop na paminsan-minsang sumasali sa tunnel, ang split-DNS ang mas mabuting default: pinapanatili nito ang mga ordinaryong pangalan sa internet sa resolver na pinagkakatiwalaan na ng makina. Para sa isang makinang umiiral upang maabot ang mga serbisyo sa bahay, mas simple ang pagtulak ng resolver at walang halaga ang saklaw.
I-publish ang record sa resolver na nagmamay-ari ng zone
Paghiwalayin ang mga tungkulin bago magsulat ng configuration: ang address ng client ng VPN, ang resolver at ang serbisyo ay tatlong magkaibang host na may tatlong magkaibang gawain. Sa lab na ito sila ay 10.77.0.2 para sa client, 192.168.50.53 para sa dnsmasq at 192.168.50.20 para sa NAS, habang ang tunnel ay nagru-route sa LAN ng bahay.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20
Ang linyang host-record ay nagbibigay ng address at ang linyang local= ay nagtatago ng mga hindi kilalang tanong sa home.arpa sa loob ng resolver na ito sa halip na ipasa ang mga ito pataas. Basahin muna ang iyong umiiral na configuration at itugma ang anumang tumutukoy na ng server, interface o parehong lokal na domain; ang pagpatong ng fragment sa isang sumasalungat ay gumagawa ng resolver na masayang naglo-load at mali ang sagot. Ang manwal ng dnsmasq ay tumutukoy sa dalawang direktiba at sa mga kontrol sa pakikinig.
Pagkatapos i-verify ang serbisyong tumatakbo, hindi ang file. Ang pagsubok sa configuration at isang restart ang pinakamababa, at ang epektibong sagot ay ang ibinabalik ng isang query.
I-route ang resolver, hindi lamang ang web page
Ang AllowedIPs ng WireGuard ang nagpapasya kung aling mga destinasyon ang pumapasok sa tunnel. Kung ang address ng resolver ay nahuhulog sa labas nito, lumalabas ang query sa normal na ruta at hindi kailanman umabot sa dnsmasq, kahit na ang NAS mismo ay naaabot. Isama ang address ng resolver, o ang prefix ng LAN na naglalaman nito, at suriin ang patakaran sa pagpapasa ng gateway sa kabilang panig.
Payagan ang UDP at TCP sa port 53 mula sa awtorisadong saklaw ng tunnel, na may daan pabalik sa address ng tunnel ng client. Huwag ipasa ang port 53 mula sa WAN upang gawing mas madali ang pagsubok: ang bukas na recursive resolver sa koneksyon sa bahay ay natatagpuan sa loob ng mga oras. Ang pagbigkis sa isang interface ay hindi patakaran sa pag-access sa sarili nito.
Suriin ang sagot bago ang application
Tanungin muna ang resolver nang direkta, pagkatapos ang system, pagkatapos ang application. Ang bawat hakbang ay naghihiwalay ng isang kawing sa kadena, at ang pagkakaiba sa pagitan nila ang diagnosis.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'
Sulit na patakbuhin ang query na TCP dahil ang pinutol na sagot ng UDP ay pumipilit ng muling pagsubok, at ang patakarang nagtatapon ng TCP 53 ay gumagawa ng mga pagkabigo na parang pana-panahon. Ang hakbang na getent ay nagpapakita kung ano talaga ang ginagawa ng configuration ng resolver ng makina, na hindi laging ang ipinadala mo.
Magpasya kung ano ang nangyayari kapag nakababa ang tunnel
Kung ang pangkalahatang DNS ng client ay tumuturo sa 192.168.50.53, titigil sa paggana ang lahat ng resolusyon ng pangalan kapag hindi nakaangat ang tunnel. Katanggap-tanggap iyon sa makinang kapaki-pakinabang lamang kasama ng tunnel, at hindi katanggap-tanggap sa laptop na gumagamit din ng Wi-Fi sa kapehan. Iniiwasan ng split-DNS ang tanong nang lubusan, dahil ang mga paghahanap sa home.arpa lamang ang umaasa sa resolver ng bahay.
Tandaan kung ano ang pangalan: ang home.arpa ay nakalaan para sa mga tirahan na network at hindi natatangi sa buong mundo, kaya ang ibang network ay maaaring legal na gumamit ng parehong pangalan. Ito ay lokal na kaginhawahan, hindi isang mapagkakatiwalaang identifier. Panatilihing napapanahon ang record kapag lumipat ang serbisyo, at alisin ang patakaran ng resolver kapag retirado na ang lab sa halip na mag-iwan ng laptop na tumuturo sa isang address na maaabot lamang nito sa pamamagitan ng tunnel na wala na.