Дајте свом кућном VPN-у сопствене DNS записе за nas.home.arpa

Када је тунел подигнут, последњи корак је обично име које ради уместо адресе коју налепите у обележивач. dnsmasq запис хоста плус адреса resolver-а до које клијент може да стигне раде то са две датотеке и без multicast-а. Одлука која заиста тражи размишљање је ужа: да ли клијент шаље сав DNS кроз кућни resolver, или само имена под home.arpa? Све испод претпоставља одобрено подешавање WireGuard-а са Linux клијентом и лабораторијским resolver-ом којим кућни администратор већ управља.

Три начина да клијенту дате resolver

За преносни рачунар који повремено улази у тунел, split-DNS је бољи подразумевани избор: задржава обична интернет имена на resolver-у ком машина већ верује. За машину која постоји да би достигла кућне услуге, потискивање resolver-а је једноставније и цена обима није важна.

Објавите запис на resolver-у који поседује зону

Држите улоге одвојене пре писања конфигурације: адреса VPN клијента, resolver и услуга су три различита хоста са три различита задатка. У овој лабораторији то су 10.77.0.2 за клијента, 192.168.50.53 за dnsmasq и 192.168.50.20 за NAS, а тунел усмерава кућни 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

Ред host-record даје адресу, а ред local= задржава непозната питања о home.arpa унутар овог resolver-а уместо да их проследи даље. Прво прочитајте постојећу конфигурацију и ускладите све што већ дефинише сервер, интерфејс или исти локални домен; слагање фрагмента на противречан даје resolver који се весело учитава и одговара погрешно. Приручник dnsmasq дефинише обе директиве и контроле слушања.

Затим проверите услугу која ради, а не датотеку. Тест конфигурације плус поновно покретање је минимум, а стварни одговор је оно што упит враћа.

Усмерите resolver, не само веб страницу

AllowedIPs у WireGuard-у одлучује која одредишта улазе у тунел. Ако адреса resolver-а падне изван тога, упит излази уобичајеном рутом и никада не стигне до dnsmasq, иако је сам NAS доступан. Укључите адресу resolver-а, или LAN префикс који је садржи, и проверите политику прослеђивања мрежног пролаза на другој страни.

Дозволите UDP и TCP на порту 53 из овлашћеног опсега тунела, са повратним путем до адресе тунела клијента. Не прослеђујте порт 53 са WAN-а да бисте олакшали тестирање: отворен рекурзивни resolver на кућној вези пронађе се у року од сати. Везивање за интерфејс само по себи није политика приступа.

Проверите одговор пре апликације

Прво питајте resolver директно, затим систем, затим апликацију. Сваки корак изолује једну карику у ланцу, а разлика међу њима је дијагноза.

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 упит јер скраћен UDP одговор присиљава на поновни покушај, а политика која одбацује TCP 53 ствара отказе који изгледају повремено. Корак getent показује шта конфигурација resolver-а на машини заправо ради, а то није увек оно што сте послали.

Одлучите шта се дешава када је тунел доле

Ако општи DNS клијента показује на 192.168.50.53, свако разрешавање имена престаје да ради када тунел није подигнут. То је прихватљиво на машини која је корисна само са тунелом, а неприхватљиво на преносном рачунару који користи и Wi-Fi у кафићу. Split-DNS потпуно заобилази то питање, јер само претраге home.arpa зависе од кућног resolver-а.

Запамтите шта је име: home.arpa је резервисано за стамбене мреже и није глобално јединствено, па друга мрежа може легитимно да користи исто име. То је локална погодност, а не поуздан идентификатор. Одржавајте запис ажурним када се услуга пресели, и уклоните политику resolver-а када се лабораторија повуче, уместо да оставите преносни рачунар који показује на адресу до које може да стигне само кроз тунел који више не постоји.