Donu al via hejma VPN proprajn DNS-rikordojn por nas.home.arpa

Publikigu unu nomon el dnsmasq, direktu la solvilon tra WireGuard, poste elektu inter puŝi DNS al la tuta kliento kaj split-DNS nur por home.arpa.

Post kiam la tunelo estas supre, la lasta paŝo kutime estas nomo, kiu funkcias anstataŭ adreso, kiun vi algluas en legosignon. dnsmasq-gastiga rikordo plus solvila adreso, kiun la kliento povas atingi, faras tion per du dosieroj kaj sen multicast. La decido, kiu vere postulas pripensadon, estas pli mallarĝa: ĉu la kliento sendas la tutan DNS tra la hejma solvilo, aŭ nur la nomojn sub home.arpa? Ĉio sube supozas aprobitan WireGuard-agordon kun Linux-kliento kaj laboratoria solvilo, kiun la hejma administranto jam administras.

Tri manieroj doni solvilon al la kliento

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

Por tekokomputilo, kiu foje aliĝas al la tunelo, split-DNS estas la pli bona defaŭlto: ĝi tenas ordinarajn interretajn nomojn ĉe la solvilo, kiun la maŝino jam fidas. Por maŝino, kiu ekzistas por atingi hejmajn servojn, puŝi la solvilon estas pli simpla kaj la kosto de amplekso ne gravas.

Publikigu la rikordon ĉe la solvilo, kiu posedas la zonon

Tenu la rolojn apartaj antaŭ ol skribi agordon: la adreso de la VPN-kliento, la solvilo kaj la servo estas tri malsamaj gastigantoj kun tri malsamaj taskoj. En ĉi tiu laboratorio ili estas 10.77.0.2 por la kliento, 192.168.50.53 por dnsmasq kaj 192.168.50.20 por la NAS, dum la tunelo enkursigas la hejman 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

La linio host-record liveras la adreson, kaj la linio local= tenas nekonatajn home.arpa-demandojn ene de ĉi tiu solvilo anstataŭ plusendi ilin supren. Legu unue vian ekzistantan agordon kaj akordigu ĉion, kio jam difinas servilon, interfacon aŭ la saman lokan domajnon; stakigi fragmenton sur kontraŭdira produktas solvilon, kiu ĝoje ŝarĝiĝas kaj malĝuste respondas. La dnsmasq-manlibro difinas ambaŭ direktivojn kaj la aŭskultajn regilojn.

Poste kontrolu la kurantan servon, ne la dosieron. Agorda testo plus restarto estas la minimumo, kaj la efektiva respondo estas tio, kion redonas demando.

Enkursigu la solvilon, ne nur la retpaĝon

La AllowedIPs de WireGuard decidas, kiuj celoj eniras la tunelon. Se la solvila adreso falas ekster ĝi, la demando eliras tra la normala vojo kaj neniam atingas dnsmasq, kvankam la NAS mem estas atingebla. Inkluzivu la adreson de la solvilo, aŭ la LAN-prefikson, kiu enhavas ĝin, kaj kontrolu la plusendan politikon de la enirejo ĉe la alia flanko.

Permesu UDP kaj TCP ĉe pordo 53 el la rajtigita tunela gamo, kun revena vojo al la tunela adreso de la kliento. Ne plusendu pordon 53 el la WAN por faciligi testadon: malferma rekursia solvilo ĉe hejma konekto estas trovata ene de horoj. Ligi al interfaco per si mem ne estas alirpolitiko.

Kontrolu la respondon antaŭ la aplikaĵo

Demandu unue la solvilon rekte, poste la sistemon, poste la aplikaĵon. Ĉiu paŝo izolas unu ligilon en la ĉeno, kaj la diferenco inter ili estas la diagnozo.

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'

Valoras ruli la TCP-demandan, ĉar tranĉita UDP-respondo devigas reprovon, kaj politiko, kiu forĵetas TCP 53, kreas malsukcesojn, kiuj aspektas intermitaj. La paŝo getent montras, kion la solvila agordo de la maŝino fakte faras, kio ne ĉiam estas tio, kion vi puŝis.

Decidu, kio okazas kiam la tunelo estas malsupre

Se la ĝenerala DNS de la kliento montras al 192.168.50.53, ĉiu nomsolvado ĉesas funkcii kiam la tunelo ne estas supre. Tio estas akceptebla sur maŝino, kiu utilas nur kun la tunelo, kaj neakceptebla sur tekokomputilo, kiu ankaŭ uzas kafejan Wi-Fi. Split-DNS tute evitas la demandon, ĉar nur home.arpa-serĉoj dependas de la hejma solvilo.

Memoru, kio estas la nomo: home.arpa estas rezervita por loĝejaj retoj kaj ne estas tutmonde unika, do alia reto povas laŭleĝe uzi la saman nomon. Ĝi estas loka oportuneco, ne fidinda identigilo. Tenu la rikordon aktuala kiam la servo translokiĝas, kaj forigu la solvilan politikon kiam la laboratorio estas emeritiĝita, anstataŭ lasi tekokomputilon montranta al adreso, kiun ĝi povas atingi nur tra tunelo, kiu ne plu ekzistas.

Rilataj artikoloj