OpenVPN-ի հրող DNS-ն անտեսվում է. ո՞ր բաղադրիչն է այն կիրառում

Մատյանը ցույց է տալիս սերվերի հրած ընտրանքը, թունելը աշխատում է, և ներքին անունները դեռ ձախողվում են։ Ուղիղ հարցումը ռեզոլվերին պատասխանում է, ուրեմն սերվերը կարգին է, բայց յուրաքանչյուր հավելված շարունակում է հարցնել տեղական երթուղիչին։ Կլիենտին հասածը առաջարկ է, ոչ թե փոփոխություն ռեզոլվերում, և անունների լուծմանը տիրող բաղադրիչը տարբերվում է Linux, Windows և macOS-ում։ Հենց որ բաժանեք ընտրանքը իր տիրոջից, չորս խոտան ծածկում են գրեթե յուրաքանչյուր հաշվետվություն. hook չկա, երկու մրցակից hook, բաժանված DNS-ն աշխատում է ինչպես նախագծված է, կամ կարճ անուն, որը սերվերի փոխարեն վերջածանց է պահանջում։

Հրված ընտրանքը առաջարկ է, ոչ տեղադրում

Սերվերի վրա երկու հրահանգ նկարագրում են մտադրություն, ոչ ազդեցություն.

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Կլիենտը չի ստանում կարգավորված ռեզոլվեր։ Այն ստանում է միջավայրի փոփոխականներ, foreign_option_1 և հաջորդները, մեկը յուրաքանչյուր հրված տողի համար, և ինչ-որ տեղական բան պետք է կարդա դրանք և վերագրի օպերացիոն համակարգի ռեզոլվերի վիճակը։ Linux-ում լռելյայն ոչինչ չի անում դա, այդ պատճառով ճիշտ սերվերը և միացված կլիենտը դեռ կարող են անունները լուծել LAN-ի միջոցով։

Երկու ծայրերի միջև երեք փուլ կա. հրումը պետք է հասնի, կլիենտը պետք է բացահայտի այն, և hook-ը պետք է կիրառի այն։ Կարդացեք միջին փուլը կլիենտի մատյանում, իսկ վերջինը՝ ռեզոլվերի վիճակում, երբեք հակառակը, որովհետև մատյանի մեկ տող ապացուցում է միայն առաջին երկուսը։

Համոզվեք, որ հրումը հասել է, և գտեք տիրոջը

Սկսեք անվանելով գործարկիչը. մերկ openvpn հրահանգ, systemd-ի օրինակ, NetworkManager կամ մատակարարի կլիենտ։ Դա է որոշում, թե որտեղ կարող է ապրել hook-ը։ systemd-resolved-ով հոսթում, resolvectl status թվարկում է յուրաքանչյուր կապը իրականում օգտագործվող DNS սերվերներով և որոնման դոմեններով, և թունելի կապը միշտ չէ, որ կոչվում է tun0։

Եթե հրված հասցեն մատյանում կա, բայց ոչ մի կապի վրա չկա, ինտեգրումը բացակայում է։ Եթե այն կապի վրա է, և հարցումները դեռ դուրս են գալիս այլ տեղ, խնդիրն այն է, թե որ հարցումներն են ընտրում այդ կապը։ NetworkManager-ը dns=dnsmasq ֆայլում /etc/NetworkManager/NetworkManager.conf գործարկում է տեղական փոխանցիչ, որը դիտավորությամբ կիրառում է բաժանված DNS. VPN դոմենի ներսում գտնվող անունները գնում են VPN ռեզոլվերին, իսկ մնացածը պահպանում է իր նախկին ուղին։ Այդ վարքը խոտանի է նմանվում, երբ սպասում էիք, որ ամբողջ երթևեկությունը կտեղափոխվի. ստուգեք կապի առանձին կարգավորումները այս գործիքով nmcli connection show "My VPN", որտեղ ipv4.dns և ipv4.dns-search պահում են սարքի հաղորդածի հետևում եղած արժեքները, նախքան այն կոտրված անվանելը։ Եթե յուրաքանչյուր հարցում իսկապես պետք է հասնի VPN ռեզոլվերին, հեռացրեք dns=dnsmasq -ը NetworkManager.conf ֆայլից և վերագործարկեք NetworkManager-ը, ինչը անունների լուծումը վերադարձնում է կապի կարգավորումներին. հակառակ դեպքում պահեք բաժանված DNS-ը և ուղղեք հրված դոմենների ցանկը։

Linux. ընտրանքները փոխանցեք ռեզոլվերին

Տարածման փաթեթները hook են մատակարարում դրա համար, և կլիենտին պետք է թույլատրվի գործարկել այն։ Տիպիկ դասավորություն systemd-resolved-չունեցող հոսթում.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved-ի հետ հին resolv.conf սկրիպտը գուցե ոչինչ էական չփոխի, որովհետև stub ռեզոլվերը պահում է վիճակը յուրաքանչյուր կապի համար։ update-systemd-resolved օգնականը փաստագրում է hook-ի ձև, որը օգտագործում է up-restart և down-pre, ինչը կարևոր է, երբ ինտերֆեյսը վերապրում է միակ միացման փորձից։ Ինչ էլ ընտրեք, մեկ բաղադրիչ պետք է տիրի վիճակին։ NetworkManager-ի կողքին անկապ hook ավելացնելը տալիս է երկու գրող նույն կապին, և արդյունքն այն ժամանակ կախված է հերթականությունից, ոչ թե ձեր կոնֆիգուրացիայից։

Կա նաև դեպք, երբ NetworkManager-ը լիովին անտեսեց հրված ընտրանքը, մինչև սերվերի հասցեն մուտքագրվեց կապի IPv4 կարգավորումներում, որից հետո ռեզոլվերի վիճակը ցույց տվեց, որ այն օգտագործվում է։ Արժե փորձել սկրիպտները վերագրելուց առաջ, որովհետև այն խնդիրը shell hook-ից տեղափոխում է կապի պրոֆիլ, որն արդեն կրում է թունելը։

Windows-ը և macOS-ը կիրառում են տարբեր մասեր

Windows-ի կլիենտը իսկապես սահմանում է VPN ադապտերի DNS սերվերները, բայց Windows-ը դեռ ինտերֆեյս է ընտրում մետրիկայով և դեռ վերջածանց է պետք կարճ անունը ընդլայնելու համար։ Հաստատեք ադապտերի վիճակը, ոչ թե պրոֆիլը.

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Եթե հասցեն բացակայում է, սահմանեք այն այս հրահանգով Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, ապա ավելացրեք վերջածանցը ադապտերի IPv4 հատկություններին, որպեսզի fileserver դառնա fileserver.corp.example։ Մեքենայի մակարդակով SearchList արժեքը Tcpip\Parameters -ի տակ նույնն է անում։ Որտեղ երկար անունը լուծվում է, իսկ մերկը՝ ոչ, ռեզոլվերն արդեն ճիշտ է, և մեղավորը որոնման ցանկն է։ Ուղղումները հերթով. հրեք DOMAIN որպեսզի կլիենտը սովորի վերջածանցը, ավելացրեք այդ վերջածանցը ադապտերի կամ կապի որոնման ցանկին, և որպես ժամանակավոր միջոց ամրացրեք անունը hosts ֆայլում, կամ LMHOSTS -ում Windows-ի վրա. NetBIOS-ի զննումը չի անցնում երթուղիչով, ուստի գրասենյակի LAN-ում կարճ անուն գտնող հեռարձակումը երբեք չի հասնում թունելի կլիենտին։

block-outside-dns block-outside-dns-ը Windows կլիենտի վարք է, ոչ թե տեղափոխելի պրոֆիլի տող, և Linux կամ macOS պրոֆիլ պատճենելը այն այնտեղ չի վերարտադրում։ Եթե Windows-ում հանրային անունները աշխատում են, իսկ ներքինը ձախողվում, համեմատեք ադապտերների հերթականությունը Ընդլայնված կարգավորումներում այս հրահանգի հետ ipconfig /all։ macOS-ում յուրաքանչյուր ծառայության ռեզոլվերի հերթականությունը պատկանում է համակարգին, ուստի օգտագործեք scutil --dns -ը՝ տեսնելու, թե որ դոմենի համար որ ռեզոլվերն է հարցվում, և ցանկացած առանձին հաղորդված պրոֆիլի ուղղում դիտարկեք որպես կլիենտից կախված, ոչ թե ընդհանուր։

Նույն նոթբուքում գտնվող վիրտուալ մեքենան սրանից ոչինչ չի ժառանգում։ Տվեք հյուրին իր սեփական ռեզոլվերի գրառումը ներքին դոմենի համար, կամ թույլ տվեք հիպերվիզորի NAT-ին փոխանցել իր հարցումները հոսթի միջով, ինչը ճիշտ է միայն այնքան ժամանակ, քանի դեռ հոսթի թունելը աշխատում է։

Պատմությունը երրորդ պատճառն է։ Նախկին պրոֆիլի DNS սերվերները կամ վերջածանցի կարգավորումները կարող են վերապրել վերամիացումներից, ուստի երբ ադապտերը ճիշտ տեսք ունի, իսկ որոնումները դեռ ձախողվում են, համեմատեք կենդանի ադապտերը Get-VpnConnection -ի հետ և ջնջեք կամ վերագրեք հնացած գրառումը, նախքան սերվերին դիպչելը։

Ապացուցեք, թե ուր գնաց հարցումը

Մեկ որոնման ընթացքում որսումը լուծում է վեճը. tcpdump -ni eth0 port 53 ցույց է տալիս հարցումներ ֆիզիկական ինտերֆեյսի վրա, ինչը նշանակում է, որ դրանք դուրս են գալիս թունելից դուրս, և ռեզոլվերը երբեք չի փոխվել։ dig @10.8.0.1 name.corp.example ապա բաժանում է մնացած երկու դեպքերը։ Եթե ուղիղ հարցումը պատասխանում է, ռեզոլվերն աշխատում է, և կլիենտը չի օգտագործում այն. եթե ժամկետը լրանում է, ռեզոլվերը թունելի միջով անհասանելի է, և ոչ մի տեղական փոփոխություն չի օգնի։

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

Հասանելիությունը ներառում է VPN հոսթի firewall-ը, որը պետք է թույլատրի UDP և TCP 53-ը լողավազանից։ Փակ պորտը ճիշտ կոտրված հրումի տեսք ունի, և այդպես նաև ռեզոլվեր, որը պատասխանում է միայն թունելի ցանցի ներսից։ Կրկնեք որսումը մեկ անջատում և վերամիացումից հետո, որովհետև կարգավորումները, որոնք հայտնվում են առաջին միացման ժամանակ և անհետանում երկրորդում, hook-ի կյանքի ցիկլի խոտան են, ոչ թե բացակայող ընտրանք։

Պահեք մեկ տեր և ստուգեք հերթով

Սկրիպտը, որը վերագրում է ադապտերի DNS-ը գուշակված թունելի վիճակի հիման վրա, կրկնօրինակում է կոնֆիգուրացիան, որն արդեն կրում է պրոֆիլը, և լուռ ձախողվում է առաջին անգամ, երբ գուշակությունը սխալ է։ Նախընտրեք կապի սեփական DNS կարգավորումները կամ մեկ փաստագրված hook, և գրի առեք, թե որն եք ընտրել, որպեսզի հաջորդ մարդը երկրորդը չավելացնի։

Փակեք շղթան չորս ստուգումներով. հրված հասցեն առկա է թունելի կապին, ներքին անունը լուծվում է որպես լրիվ որակավորված անուն, նույն անունը լուծվում է առանց վերջածանցի, և երկուսն էլ դեռ ճիշտ են մեկ վերամիացումից հետո։ Մեկ որսում ասում է, թե չորսից որն է ձախողվել։ OpenVPN 2.6-ի ձեռնարկը թվարկում է dhcp-option և սկրիպտի հրահանգները իրենց հարթակային նշումներով։