Dajte svoji domači VPN lastne zapise DNS za nas.home.arpa

Ko je tunel postavljen, je zadnji korak običajno ime, ki deluje, namesto naslova, ki ga prilepite v zaznamek. Zapis gostitelja v dnsmasq in naslov resolverja, ki ga odjemalec doseže, to naredita z dvema datotekama in brez multicast. Odločitev, ki res zahteva razmislek, je ožja: ali odjemalec pošlje ves DNS skozi domači resolver, ali samo imena pod home.arpa? Vse spodaj predpostavlja odobreno nastavitev WireGuard z odjemalcem Linux in laboratorijskim resolverjem, ki ga domači skrbnik že upravlja.

Trije načini, kako odjemalcu dati resolver

Za prenosnik, ki se tunelu pridruži občasno, je split-DNS boljša privzeta izbira: običajna internetna imena ohrani na resolverju, ki mu stroj že zaupa. Za stroj, ki obstaja zato, da doseže domače storitve, je potiskanje resolverja preprostejše in strošek obsega ni pomemben.

Zapis objavite pri resolverju, ki ima cono

Pred pisanjem konfiguracije ločite vloge: naslov odjemalca VPN, resolver in storitev so trije različni gostitelji s tremi različnimi nalogami. V tem laboratoriju so to 10.77.0.2 za odjemalca, 192.168.50.53 za dnsmasq in 192.168.50.20 za NAS, tunel pa usmerja domači LAN.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

Vrstica host-record zagotovi naslov, vrstica local= pa neznana vprašanja o home.arpa zadrži znotraj tega resolverja, namesto da bi jih poslala naprej. Najprej preberite obstoječo konfiguracijo in uskladite vse, kar že opredeljuje strežnik, vmesnik ali isto lokalno domeno; nalaganje drobca na nasprotujočega ustvari resolver, ki se veselo naloži in odgovarja napačno. Priročnik dnsmasq opredeljuje obe direktivi in nadzor poslušanja.

Nato preverite delujočo storitev, ne datoteke. Preizkus konfiguracije in ponovni zagon sta najmanj, dejanski odgovor pa je tisto, kar vrne poizvedba.

Usmerite resolver, ne samo spletne strani

AllowedIPs v WireGuardu odloča, katere cilje vstopijo v tunel. Če naslov resolverja pade zunaj njega, poizvedba odide po običajni poti in nikoli ne doseže dnsmasq, čeprav je sam NAS dosegljiv. Vključite naslov resolverja ali predpono LAN, ki ga vsebuje, in preverite politiko posredovanja prehoda na drugi strani.

Dovolite UDP in TCP na vratih 53 iz pooblaščenega obsega tunela, s povratno potjo do naslova tunela odjemalca. Vrat 53 ne posredujte iz WAN, da bi olajšali testiranje: odprt rekurzivni resolver na domači povezavi je najden v nekaj urah. Vezava na vmesnik sama po sebi ni politika dostopa.

Preverite odgovor pred aplikacijo

Najprej vprašajte resolver neposredno, nato sistem, nato aplikacijo. Vsak korak izolira en člen v verigi, razlika med njimi pa je diagnoza.

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'

Poizvedbo TCP se splača zagnati, ker okrnjen odgovor UDP prisili ponovni poskus, politika, ki zavrže TCP 53, pa ustvari napake, ki se zdijo občasne. Korak getent pokaže, kaj konfiguracija resolverja na stroju v resnici počne, kar ni vedno tisto, kar ste poslali.

Odločite, kaj se zgodi, ko je tunel spuščen

Če splošni DNS odjemalca kaže na 192.168.50.53, vsako razreševanje imen preneha delovati, ko tunel ni postavljen. To je sprejemljivo na stroju, ki je uporaben samo s tunelom, in nesprejemljivo na prenosniku, ki uporablja tudi Wi-Fi v kavarni. Split-DNS se vprašanju povsem izogne, ker so od domačega resolverja odvisna le iskanja home.arpa.

Zapomnite si, kaj je ime: home.arpa je rezervirano za stanovanjska omrežja in ni globalno edinstveno, zato lahko drugo omrežje zakonito uporabi isto ime. To je lokalna priročnost, ne zanesljiv identifikator. Vzdržujte zapis ažuren, ko se storitev preseli, in ko laboratorij upokojite, odstranite politiko resolverja, namesto da pustite prenosnik, ki kaže na naslov, do katerega lahko pride le skozi tunel, ki ne obstaja več.