WireGuard-ը DNS չի ուղարկում՝ մասնավոր BIND գոտու սպասարկում

Դուք բարձրացրել եք WireGuard-ը, թունելը անցկացնում է երթևեկությունը, իսկ ներքին անունը դեռ չի լուծվում։ Հաջորդ քայլը սովորաբար WireGuard-ի կարգավորումներում DNS պարամետր փնտրելն է, կարծես հավասարը կարող է լուծիչ ուղարկել, ինչպես անում են որոշ այլ VPN-ներ։ Չի կարող։ Ձեռքսեղմումը կրում է բանալիներ, ինտերֆեյսի հասցեներ և թույլատրված IP հասցեներ, և դրանում դաշտ չկա DNS սերվերների կամ որոնման դոմենների համար։ Լուծիչի քաղաքականությունը ապրում է կլիենտում, և ուղղումը հենց այնտեղ է։

Թունելը և լուծիչը առանձին պայմանագրեր են

WireGuard-ը միտումնավոր փոքր է։ Այն տեղափոխում է փաթեթներ ձեր նշած հասցեների համար և նույնականացնում հավասարներին․ այդ շերտից վեր ամեն ինչ ձեր ձևավորումն է։ OpenVPN կարող է ուղարկել dhcp-option DNS, որովհետև նրա կառավարման ալիքը կրում է կարգավորում, և այդ տարբերությունը սայթաքեցնում է երկուսի միջև տեղաշարժվողներին։

Այսպիսով աշխատող թունելը ոչինչ չի ասում անունների լուծման մասին։ Կլիենտը կարող է կատարյալ ուղի ունենալ դեպի 10.90.0.1 և դեռ ուղարկել իր հարցումները հանրային լուծիչի, ինչի պատճառով ախտանիշը թվում է «VPN-ը կոտրեց DNS-ը», մինչդեռ DNS-ը երբեք VPN-ին ուղղված չի եղել։

Սպասարկեք գոտին՝ չդառնալով ռեկուրսիվ լուծիչ

Սերվերի կողմը փոքր հեղինակավոր գոտի է, ոչ ընդհանուր լուծիչ։ Այս օրինակում դարպասը 10.90.0.1 է, կլիենտները՝ 10.90.0.0/24, և այն հավելվածը, որ ձեզ հետաքրքրում է, պատասխանում է 10.60.0.20-ում։

Միավորեք այս կարգավորումները գոյություն ունեցող options բլոկի մեջ, փոխարենը երկրորդը ստեղծելու:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Ապա հայտարարեք գոտին և նրա ֆայլը:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Ստուգեք վերաբեռնելուց առաջ, որովհետև վերաբեռնման պահին շարահյուսական սխալը տապալում է ամբողջ սերվերը յուրաքանչյուր գոտու համար, որը նա սպասարկում է:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Բացեք UDP և TCP 53 միայն VPN ինտերֆեյսում։ Հանրային ինտերֆեյսում մասնավոր հեղինակություն հրապարակելը հրավիրում է և՛ հարցումներ, և՛ թվարկում, և allow-transfer-ը պետք է փակ մնա, եթե երկրորդականն իսկապես դրա կարիքը չունի։

Ուղղեք կլիենտին դեպի այն՝ յուրաքանչյուր հղման համար

Ենթադրեք, որ կապը պատկանում է NetworkManager-ին, իսկ լուծիչը systemd-resolved-ն է։ Նախ կարդացեք գոյություն ունեցող քաղաքականությունը, հատկապես ցանկացած արմատային երթուղային դոմեն, որովհետև ~. գրառումը կգերազանցի այն, ինչ դուք պատրաստվում եք ավելացնել։

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Տիլդան է կարևոր նշանը։ Այն նշում է դոմենը որպես միայն-ուղի․ corp.example-ի տակ գտնվող անունները գնում են այս հղման DNS սերվեր, և դոմենը չի ավելացվում որպես կարճ անվան որոնման վերջածանց։ Առանց դրա՝ portal մուտքագրելը սկսում է լուծել portal.corp.example-ը, ինչը հարմար է ձեզ և զարմանալի մյուսների համար։ Պահեք տիլդան չակերտների ներսում, որովհետև առանց չակերտների այն shell-ի ընդլայնում է, որը սպասում է մատնանշելու ձեր տնային թղթապանակին։

Կիրառեք փոփոխությունը ինտերֆեյսին տիրող կառավարչի միջոցով, ապա նորից միացրեք կապը։ Մի գործարկեք wg-quick-ի երկրորդ օրինակ նույն ինտերֆեյսի համար․ երկու սեփականատեր կվիճեն ուղիների համար, և նրանցից մեկը կհաղթի ամենավատ պահին։

Ստուգեք ուղին անունից առաջ

Հարցրեք անունը կլիենտից և հաստատեք և՛ պատասխանը, և՛ այն սերվերը, որ ստեղծել է այն:

resolvectl query portal.corp.example

Եթե սա վերադարձնում է 10.60.0.20, DNS պայմանագիրը կատարված է։ Եթե ժամանակը սպառվում է, նախ ստուգեք ուղին դեպի 10.90.0.1, ապա հրամուրի կանոնը, ապա allow-query-ը սերվերում։ Անվան լուծման խափանումները այս կարգաբերման մեջ գրեթե միշտ հասանելիություն կամ ACL են, ոչ գոտու ֆայլ։ Աշխատեք կլիենտից դուրս, որովհետև սերվերը չի կարող ասել ձեզ, թե ինչու հարցումը երբեք չհասավ։

Հիշեք, որ հավելվածը դեռ կարիք ունի իր ուղուն և իր ծառայության թույլտվությանը։ Լուծված անունը, որը մատնանշում է անհասանելի հասցեի, այլ խափանում է նույն հագուստով։

Ինչ դեռ ավտոմատ չէ

Սեփական լուծիչ տրամաբանությամբ հավելվածները լիովին անտեսում են համակարգի լուծիչը, և ոչ մի քանակությամբ nmcli դա չի փոխում։ Տեղակայումները, որոնք վավերացնում են DNSSEC-ը, մասնավոր գոտու համար պահանջում են վստահության խարսխի հստակ ձևավորում․ պատասխանը վավերացումն անջատելու ընդհանուր հրահանգ չէ։ Փորձարկեք նույն կլիենտ ծրագրով, որ գործարկում են ձեր օգտատերերը, ոչ այն գործիքով, որը պատահաբար օգտագործում է համակարգի լուծիչը։ Այդ երկուսի միջև եղած տարբերությունը ողջ սխալի հաշվետվությունն է։

Նավատորմերը կարող են ավտոմատացնել այս կլիենտ քաղաքականությունը իրենց մատակարարման համակարգի միջոցով, բայց քաղաքականությունը մնում է առանձին օբյեկտ՝ սեփականատիրոջով։ BIND 9 տեղեկատուն ընդգրկում է վերևում օգտագործված լսելու և հարցումների կառավարումը, և դա ճիշտ տեղն է ձեր տեղադրված տարբերակի վարքը հաստատելու համար։

Հաջորդ քայլը․ ավելացրեք գոտու սերիական համարի ավելացումը և ստուգման հրամանները ձեր փոփոխությունների ընթացակարգում, որպեսզի գրառման խմբագրումը չկարողանա չստուգված հասնել արտադրություն։