Տվեք ձեր տնային VPN-ին իր սեփական DNS գրառումները nas.home.arpa-ի համար
Հրապարակեք մեկ անուն dnsmasq-ից, ուղղորդեք resolver-ը WireGuard-ով, ապա ընտրեք ամբողջ հաճախորդին DNS ուղարկելու և միայն home.arpa-ի համար split-DNS-ի միջև։
Երբ թունելը բարձրացված է, վերջին քայլը սովորաբար անուն է, որն աշխատում է այն հասցեի փոխարեն, որը տեղադրում եք էջանիշում։ dnsmasq-ի հոսթի գրառումը և resolver-ի հասցեն, որին հաճախորդը կարող է հասնել, դա անում են երկու ֆայլով և առանց multicast-ի։ Որոշումը, որն իսկապես մտածել է պահանջում, ավելի նեղ է՝ արդյոք հաճախորդը բոլոր DNS-ը ուղարկում է տան resolver-ով, թե միայն home.arpa-ի տակ գտնվող անունները։ Ստորև ամեն ինչ ենթադրում է հաստատված WireGuard տեղադրում Linux հաճախորդով և լաբորատոր resolver-ով, որը տան ադմինիստրատորն արդեն կառավարում է։
Հաճախորդին 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 |
Նոթբուքի համար, որը երբեմն միանում է թունելին, 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.20host-record տողը տալիս է հասցեն, իսկ local= տողը անհայտ home.arpa հարցերը պահում է այս resolver-ի ներսում՝ դրանք վերև ուղարկելու փոխարեն։ Նախ կարդացեք ձեր գոյություն ունեցող կարգավորումը և համաձայնեցրեք այն ամենը, ինչ արդեն սահմանում է սերվեր, ինտերֆեյս կամ նույն տեղական դոմենը, քանի որ հակասողի վրա բեկոր դնելը ստեղծում է resolver, որը ուրախ բեռնվում է և սխալ պատասխանում։ dnsmasq ձեռնարկը սահմանում է երկու հրահանգներն էլ և լսելու կառավարումը։
Ապա ստուգեք աշխատող ծառայությունը, ոչ թե ֆայլը։ Կարգավորման թեստը և վերագործարկումը նվազագույնն են, իսկ իրական պատասխանն այն է, ինչ վերադարձնում է հարցումը։
Երթուղավորեք resolver-ը, ոչ միայն վեբ էջը
WireGuard-ի AllowedIPs-ը որոշում է, թե որ նպատակակետերն են մտնում թունել։ Եթե 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-ի քաղաքականությունը, երբ լաբորատորիան դուրս է գալիս շահագործումից, փոխարենը նոթբուք թողնելով, որը մատնանշում է հասցե, որին այն կարող է հասնել միայն այլևս գոյություն չունեցող թունելի միջոցով։