Ինչու մասնավոր DNS անունները ձախողվում են VPN հաճախորդներում և որտեղ ստուգել

Դուք բացում եք նոթբուքը հյուրանոցի սենյակում, գործարկում հաճախորդը, մուտքագրում ներքին ֆայլային սերվերի անունը և ոչինչ չեք ստանում։ Թունելը հաղորդում է, որ միացված է, և նույն ենթացանցի հասցեին ping-ը դեռ պատասխանում է, այսինքն՝ տրանսպորտն ինքնին կարգին է։ Ձախողվում է միայն անունը, և այդ բացը խնդիրը նեղացնում է երկու տեղի՝ ո՞ր լուծիչին հարցրեց հաճախորդը և կարո՞ղ է ստացված պատասխանը վերադառնալ թունելով։ Ուղղեք մեկը և բաց թողեք մյուսը, և խափանումը պարզապես կտեղափոխվի։

Ցանկացած պրոֆիլ խմբագրելուց առաջ ստուգեք, թե հաճախորդն ինչ է անում անվան հետ։ Linux-ում resolvectl query files.corp.example ցույց է տալիս, թե որ միացումն ու որ լուծիչը ստեղծեցին պատասխանը։ Windows-ում Resolve-DnsName files.corp.example ցույց է տալիս պատասխանող սերվերն ու վերադարձված հասցեն։

Կարդացեք պատասխանը, նախքան ինչ-որ բան փոխելը

Եթե անունը վերադառնում է որպես NXDOMAIN մի քանի միլիվայրկյանում, հարցումը երբեք չի հասել ձեր զոնային, և պատասխանել է ինչ-որ հանրային կամ հյուրանոցային լուծիչ։ Եթե այն վերադառնում է երկար դադարից հետո, ճանապարհին ինչ-որ բան գցում է UDP 53 պորտը, և հաճախորդը վերջիվերջո անցել է պահուստային տարբերակի։ Եթե այն պատասխանում է ճիշտ հասցեով, բայց կապը դեռ կպչում է, ապա լուծումը կարգին է, և ձեր խնդիրը երթուղավորման կամ հենց ծառայության մեջ է։

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

Բաշխեք լուծիչը թունելի ներսից

Հաճախորդները բաժանվում են երկու խմբի։ Մեկին սերվերը կարող է լուծիչ տալ միացման հաստատման պահին. մյուսը կարգավորումը պահում է տեղական ֆայլում, որը ոչ մի դարպաս չի կարող հեռվից փոխել։

OpenVPN առաջին խմբում է։ Սերվերում push "dhcp-option DNS 10.8.0.53"-ը և push "dhcp-option DOMAIN corp.example"-ը իջնում են կառավարման ուղիով, բայց միայն այն դեպքում, երբ հաճախորդի կոնֆիգուրացիայում pull-ը դեռ միացված է։ Ձեռքով խմբագրված հաճախորդը, որը կրում է pull-filter ignore "dhcp-option", երբեք չի տեսնի դրանք, և այդ մեկ տողը բացատրում է զարմանալիորեն շատ դեպքեր «սերվերը հրում է, բայց իմ նոթբուքը համաձայն չէ»։

WireGuard-ը երկրորդ խմբում է, որովհետև արձանագրությունն ընդհանրապես տարբերակների շուրջ բանակցություն չունի։ Լուծիչն ու որոնման դոմեյնը մտնում են հաճախորդի սեփական [Interface] բլոկի մեջ որպես DNS = 10.8.0.53, corp.example։ wg-quick-ը դա կիրառում է resolvconf-ի կամ systemd-resolved-ի միջոցով, իսկ Windows-ում պաշտոնական հաճախորդը տեղադրում է NRPT կանոններ, որոնք գոյություն ունեն միայն այնքան ժամանակ, քանի դեռ թունելը բարձրացված է. Get-DnsClientNrptPolicy-ը թվարկում է դրանք, ինչը դարձնում է այն արագ միջոց պարզելու՝ արդյոք հաճախորդը երբևէ կիրառել է ձեր ֆայլը։

IPsec/IKEv2-ը մեջտեղում է։ strongSwan-ի attr փլագինը կարող է վերադարձնել ավազանից վերցված DNS սերվեր, և Windows հաճախորդը սովորաբար ընդունում է այն, բայց պրոֆիլը, որը ամրացնում է իր սեփական անվանական սերվերը, հաղթում է ամեն ինչի, ինչ առաջարկում է դարպասը։ Linux հաճախորդում համարժեք ձեռքով քայլը resolvectl dns wg0 10.8.0.53-ն է, ապա resolvectl domain wg0 '~corp.example'-ը. երկուսն էլ անհետանում են ինտերֆեյսի հետ, ինչը հենց այն է, ինչ ուզում եք թունելով սահմանափակված կարգավորման համար։

Սահմանափակեք վերջածանցը՝ փոխանակ կուլ տալու ամեն հարցումը

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

Ներս ուղարկեք միայն մասնավոր վերջածանցը։ systemd-resolved-ում ~-ով սկսվող դոմեյնը միայն երթուղավորման համար է, ուստի ~corp.example-ը նշանակում է, որ այդ վերջածանցի տակ գտնվող հարցումները գնում են այդ միացման սերվերներին, մինչդեռ մնացած ամեն ինչ շարունակում է օգտագործել ֆիզիկական ցանցը։ Windows-ը նույնն անում է անվանատարածքով սահմանափակված NRPT կանոններով, իսկ macOS-ը՝ /etc/resolver/-ի տակ գտնվող լրացուցիչ լուծիչի ֆայլով։

Multicast անուններն արժանի են իրենց սեփական պատասխանին։ .local անունները կառուցվածքով link-local են (RFC 6762), և կետ-կետ tun ինտերֆեյսը չի կրում այդ multicast խումբը, ուստի հանրային լուծիչ ավելացնելը դրանք չի հրապարակի, և ներքին unicast լուծիչին դրանց մասին հարցնելը վերադարձնում է NXDOMAIN։ avahi-ի նման անդրադարձիչը անդրադարձման ռեժիմում կարող է կապել երկու սեգմենտ, բայց դա սերվերի կողմի որոշում է, որը ոչ մի հաճախորդ չի կարող պահանջել։ Եթե տպիչը կամ NAS-ը պետք է հասանելի լինեն անունով, փոխարենը տվեք նրանց A գրառում ձեր զոնայում։

Ապացուցեք, որ պատասխանը կարող է վերադառնալ

Անհասանելի հասցեին ուղղված ճիշտ պատասխանը ճիշտ նույն տեսքն ունի, ինչ լուծիչի խնդիրը, քանի դեռ չեք ստուգել երթուղին։ Հարցրեք միջուկին, թե ուր կգնա պատասխանը. ip route get 10.20.5.20-ը նշում է ինտերֆեյսը և, ավելի օգտակար, այն աղբյուր հասցեն, որը կօգտագործի։

Հետևեք հենց լուծիչի հասցեին։ Այն հաճախորդը, որի DNS = 10.8.0.53-ի կողքին AllowedIPs = 10.20.0.0/16 է, իր հարցումներն ուղարկում է ֆիզիկական NIC-ով դուրս, որտեղ դրանք լուռ մահանում են, որովհետև լուծիչը չկա թունելի պահանջած ոչ մի նախածանցի մեջ։ Այդ անհամապատասխանությունը այս ամբողջ ոլորտում ամենատարածված մեկ պատճառով խափանումն է, և այն անտեսանելի է, քանի դեռ չեք համեմատել DNS կարգավորումը թույլատրված նախածանցների հետ տող առ տող։

Համընկնող միջակայքերը հակառակ խափանում են առաջացնում։ Պատասխանը ճիշտ է, երթուղին գոյություն ունի, և այն ցույց է տալիս սխալ հոսթի, որովհետև տանը 192.168.0.0/24-ը ավելի կոնկրետ է, քան թունելի երթուղին նույն միջակայքին։ Վերահամարակալեք մի կողմը կամ հրեք ավելի նեղ երթուղի, ապա հաստատեք ծառայության հոսթի firewall-ն ու վերադարձի ուղին. strongSwan-ի գրառումները փոխանցման մասին ընդգրկում են այդ ուղու sysctl կողմը։

Սերտիֆիկատները առանձին ինքնության ստուգում են, որը մարդիկ բարդում են DNS-ի վրա։ Եթե զննարկիչը հաղորդում է անվան անհամապատասխանություն լուծման սխալի փոխարեն, ապա որոնումն արդեն աշխատել է, և ուղղելու բանը սերտիֆիկատի SAN-ն է։ Փորձեք HTTPS-ը անվան վրա, երբեք՝ մերկ IP-ի վրա։

Կրկին փորձեք հաճախորդից, ոչ թե դարպասից

Փորձեք հենց այն ծրագրում, որից օգտատերը բողոքում է, որովհետև հրամանի տողից որոնումը չի ապացուցում, որ զննարկիչն անցնում է նույն ուղով։ Chrome-ի անվտանգ DNS-ը և Firefox-ի network.trr.mode-ը կարող են ամբողջությամբ շրջանցել համակարգի լուծիչը, և երբ դա անում են, մասնավոր անունը կա՛մ ձախողվում է, կա՛մ արտահոսում հանրային լուծիչ։ resolvectl query-ը ձեռքով գործարկված dig @10.8.0.53 files.corp.example-ի հետ համեմատելը ձեզ ասում է, թե երկուսից որն է տեղի ունեցել։

Ապա անջատվեք և նորից միացեք, նախքան այն ուղղված հայտարարելը։ Ինտերֆեյսի վրա ձեռքով դրված կարգավորումները անհետանում են ինտերֆեյսի հետ, և պրոֆիլը, որը ճիշտ էր թվում միայն մոռացված տեղական փոփոխության պատճառով, կձախողվի հաջորդ բեռնման ժամանակ։

Կարճ ստուգաթերթ հաջորդ մեքենայի համար. անունը լուծվում է թունելի լուծիչով, վերջածանցը սահմանափակ է, ոչ համաշխարհային, լուծիչի հասցեն գտնվում է թույլատրված նախածանցների ներսում, պատասխանի հոսթը պատասխանում է ծառայության պորտին, և սերտիֆիկատը ծածկում է օգտատիրոջ մուտքագրած անունը։