Dajte svojej domácej VPN vlastné DNS záznamy pre nas.home.arpa

Keď je tunel hore, posledným krokom je zvyčajne meno, ktoré funguje, namiesto adresy, ktorú vkladáte do záložky. Záznam hostiteľa v dnsmasq plus adresa resolvera, na ktorú sa klient dostane, to zvládnu s dvoma súbormi a bez multicast. Rozhodnutie, ktoré naozaj stojí za premýšľanie, je užšie: posiela klient všetok DNS cez domáci resolver, alebo len mená pod home.arpa? Všetko nižšie predpokladá schválené zapojenie WireGuardu s linuxovým klientom a laboratórnym resolverom, ktorý domáci správca už spravuje.

Tri spôsoby, ako klientovi odovzdať resolver

Pre notebook, ktorý do tunela občas vstúpi, je split-DNS lepšou predvolenou voľbou: udrží bežné internetové mená na resolveri, ktorému stroj už dôveruje. Pre stroj, ktorý existuje kvôli dosiahnutiu domácich služieb, je doručenie resolvera jednoduchšie a cena rozsahu nehrá rolu.

Zverejnite záznam na resolveri, ktorý vlastní zónu

Pred písaním konfigurácie držte roly oddelené: adresa klienta VPN, resolver a služba sú traja rôzni hostitelia s tromi rôznymi úlohami. V tomto laboratóriu to je 10.77.0.2 pre klienta, 192.168.50.53 pre dnsmasq a 192.168.50.20 pre NAS, pričom tunel smeruje domácu 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

Riadok host-record dodá adresu a riadok local= udrží neznáme otázky na home.arpa vnútri tohto resolvera, namiesto toho aby ich preposlal vyššie. Najprv si prečítajte existujúcu konfiguráciu a zosúlaďte všetko, čo už definuje server, rozhranie alebo tú istú lokálnu doménu; navŕšenie fragmentu na konfliktný dáva resolver, ktorý sa veselo načíta a odpovedá zle. Manuál dnsmasq definuje obe direktívy aj ovládanie počúvania.

Potom overte bežiacu službu, nie súbor. Test konfigurácie plus reštart je minimum a skutočná odpoveď je to, čo dotaz vráti.

Šmerujte resolver, nie len webovú stránku

AllowedIPs WireGuardu určuje, ktoré ciele vstúpia do tunela. Ak adresa resolvera leží mimo, dotaz odíde bežnou cestou a k dnsmasq sa nikdy nedostane, aj keď je samotný NAS dostupný. Zahrňte adresu resolvera alebo prefix LAN, ktorý ju obsahuje, a overte politiku preposielania brány na druhej strane.

Povoľte UDP aj TCP na portu 53 z autorizovaného rozsahu tunela, so spätnou cestou k adrese tunela klienta. Nepreposielajte port 53 z WAN, aby ste si uľahčili testovanie: otvorený rekurzívny resolver na domácom pripojení sa nájde v priebehu hodín. Viazanie na rozhranie samo o sebe nie je prístupová politika.

Overte odpoveď skôr než aplikáciu

Najprv sa spýtajte resolvera priamo, potom systému, potom aplikácie. Každý krok izoluje jeden článok reťaze a rozdiel medzi nimi je diagnóza.

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'

TCP dotaz stojí za spustenie, pretože skrátená UDP odpoveď vynúti opakovanie a politika, ktorá zahadzuje TCP 53, vytvára poruchy, ktoré vyzerajú občasné. Krok getent ukáže, čo konfigurácia resolvera na stroji skutočne robí, čo nie vždy je to, čo ste poslali.

Rozhodnite, čo sa stane, keď tunel spadne

Ak všeobecný DNS klienta mieri na 192.168.50.53, všetko prekladanie mien prestane fungovať, keď tunel nie je hore. To je prijateľné na stroji, ktorý je užitočný len s tunelom, a neprijateľné na notebooku, ktorý používa aj Wi-Fi v kaviarni. Split-DNS otázku úplne obíde, pretože na domácom resolveri závisia len dopyty na home.arpa.

Pamätajte, čo to meno je: home.arpa je vyhradené pre rezidenčné siete a nie je globálne jedinečné, takže iná sieť môže rovnaké meno legitímne použiť. Je to miestne pohodlie, nie dôveryhodný identifikátor. Udržujte záznam aktuálny, keď sa služba presunie, a pri vyradení laboratória politiku resolvera odstráňte, namiesto toho aby ste nechali notebook ukazovať na adresu, na ktorú sa dostane len tunelom, ktorý už neexistuje.