Split-DNS գրառում. ասեք, թե որտեղ է արվել յուրաքանչյուր դիտարկում

Երկու մարդ լուծում են նույն Split-DNS խնդիրը և ստանում են տարբեր resolver հասցեներ։ Մեկը օգտագործել է որոնման գործիք, մյուսը՝ փաթեթներ գրառել ադապտերում, իսկ երրորդը կարդացել է հաճախորդի սեփական ախտորոշումը։ Նրանցից ոչ ոք չի ստում, և ոչ ոք չի նկարագրում նույն փուլը։ Դիտարկման կետն անվանելը հակասությունը վերածում է քարտեզի։

Մեկ որոնում, մի քանի դիտարկման կետեր

Մեկ ներքին անվան համար կա առնվազն հինգ տեղ նայելու՝ հավելվածը և այն resolver API-ն, որը նա կանչում է, հաճախորդի վրա գործող դոմենի քաղաքականությունը, գրառումը ադապտերի կամ զտիչի վրա, վերահսկվող դարպասի սահմանը և resolver-ը, որը իրականում ստանում է հարցումը։

Յուրաքանչյուրը պատասխանում է տարբեր հարցի, և ոչ մեկը միայնակ չի ապացուցում, թե ուր գնաց հարցումը։

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

Հաճախորդի զտիչը գտնվում է հավելվածի և լարի միջև

Split-DNS-ով VPN հաճախորդը կիրառում է դոմենի համապատասխանեցումը նախքան փաթեթը կթողնի մեքենան։ Թունելավորված վերջածանցի անունները գնում են ներքին resolver-ին, մնացած ամեն ինչ՝ տեղականին։ Զտիչը քաղաքականություն է, և քաղաքականությունը կարող է տարբերվել ըստ հարթակի և հաճախորդի տարբերակի։

Cisco-ի Secure Client-ի Split-DNS ուղեցույցը ընդգրկում է դոմենի համապատասխանեցումը և Windows-ի զտիչը, և այն բաժանում է այն, ինչ հավելվածը տեսնում է բնիկ resolver API-ն օգտագործելիս, այն ամենից, ինչ տեսնում է nslookup-ի նման գործիքը։ Այդ տարբերություններն են էությունը։

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

nslookup-ը գնում է այլ ուղով, քան հավելվածը

nslookup-ը կառուցում է իր սեփական DNS հարցումը և կարող է շրջանցել օպերացիոն համակարգի resolver քաղաքականությունը։ Դա այն դարձնում է օգտակար գործիք կոնկրետ սերվերին կոնկրետ հարց տալու համար, և մոլորեցնող գործիք՝ ստուգելու, թե ինչ կզգա հավելվածը։

Windows-ում անունների լուծման քաղաքականության աղյուսակը որոշում է, թե որ վերջածանցն է օգտագործում որ սերվերը։ Այն կարդալը ցույց է տալիս քաղաքականությունը, որին կհետևի հավելվածը, և հաճախ դա է պակասող մասը։

Կարդացեք քաղաքականությունը և ապա նույն հարցը տվեք սովորական resolver-ի միջոցով:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Գաղտնագրված resolver-ները թաքցնում են հարցումը, ոչ կապը

Սեփական DNS-over-HTTPS resolver-ով դիտարկիչն այլ դեպք է։ Հարցումը դուրս է գալիս TLS-ի ներսում, ուստի փաթեթների գրառումը ցույց է տալիս կապ resolver-ի հասցեին, բայց ոչ հարցված անունը։

Նախ պարզեք դիտարկիչի կառավարվող քաղաքականությունը, ապա համեմատեք այն օպերացիոն համակարգի որոնման հետ։ Դիտարկիչը, որին թույլատրված է ընտրել իր resolver-ը, կարող է ընդհանրապես չտեսնել Split-DNS քաղաքականությունը։

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

Համեմատեք պիտակավորված թեստի հետ

Թեստի համար ընտրեք հաստատված ներքին անուն, ինչպես նաև հանրային անուն, որը զգայուն իմաստ չի կրում։ Յուրաքանչյուրի համար գրանցեք ժամը, գրառման տեսակը, պատասխանը և սպասված քաղաքականությունը։

Որտեղ թույլատրված է, համեմատեք resolver-ի ստացումը հաճախորդի կամ դարպասի մեկ նեղ դիտարկման հետ:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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