Բաժանված DNS և VPN. տիրույթի կանոնները IP ուղիներ չեն
Բաժանված DNS-ը լուծիչ ընտրում է ըստ անվան, և պատասխանը դեռ ուղի է պահանջում։ Թեստավորեք տիրույթի կանոնն ու ուղին առանձին՝ այն հարթակում, որն իրականում օգտագործում եք։
Ձեր նոթբուքը intranet.corp-ը լուծում է թունելի միջոցով, մինչդեռ gitlab.com-ը շարունակում է գնալ մատակարարի լուծիչին, և սա այն դասավորությունն է, որն աշխատում է ինչպես նախագծվել է։ Երկու առանձին որոշումներ ստեղծեցին այն. անվանման համապատասխանության կանոնն ընտրեց լուծիչը, և ուղին վերադարձրեց պատասխանը։ Կոտրեք դրանցից որևէ մեկը, և դիտարկիչը ցույց կտա ձախողում, որը դրսից նույնն է թվում։ Բաժանված DNS-ի մասին զեկույցների մեծ մասը նկարագրում է երկրորդ ձախողումը՝ մեջբերելով առաջինի ապացույցները։
Երկու կեսերն ապրում են տարբեր տեղերում և սովորաբար խմբագրվում են տարբեր մարդկանց կողմից։ Մեկը VPN պրոֆիլին կցված DNS քաղաքականությունն է, մյուսը՝ ուղի, որը թունելը տեղադրում կամ պահում է։ Վրիպազերծումը կանգ է առնում, երբ ոչ ոք չի հաստատում, թե որ կեսն է իրականում տեղաշարժվել։
Երկու որոշում՝ թաքնված մեկ հարցման մեջ
Անվան կեսը քաղաքականության օբյեկտ է, ոչ թե ուղի։ Windows-ում դա VPN պրոֆիլի անվանման լուծման քաղաքականությունն է. Apple հարթակներում՝ DNS կարգավորումների օբյեկտի համապատասխան տիրույթների հավաքածուն. Linux-ում՝ երթուղավորման տիրույթ, բաժանված լուծիչի տող կամ անվան ծառայության փոխարկիչի հերթականությունը։ Ուղու կեսը սովորական երթուղավորում է, տեղադրված թունելի կամ ձեռքի կողմից, և այն գաղափար չունի, թե ինչ է հոսթի անունը։ Պրոֆիլը, որը թույլ է տալիս վերջածանց, միայն որոշում է, թե ով է պատասխանում. այն երբեք պատասխանը հասանելի չի դարձնում։
Արագ ախտանշանային թեստը բաժանում է դրանք. փոխարինեք անունը հասցեով։ Եթե հասցեն աշխատում է, ուղին կարգին է, իսկ կանոնը՝ սխալ։ Եթե հասցեն նույնպես ձախողվում է, կանոնը կարող է ճիշտ լինել, իսկ ուղին՝ բացակայել։
Ինչպես է յուրաքանչյուր հարթակ արտահայտում նույն անվան կանոնը
Մտադրությունը նույնն է, իսկ դաշտերի անունները՝ ոչ։ Մի հաճախորդից մյուսը պատճենված օրինակը վերլուծվում է մաքուր և երբեք չի համապատասխանում։ Երեք ձևերն այսպիսի տեսք ունեն.
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Համապատասխանության կամ երթուղավորման տիրույթը վերջածանցի թեստ է, ուստի intranet.corp-ը ծածկում է git.intranet.corp-ը և չի ծածկում corp.intranet-ը, և այն շրջելը ողջ կարգավորման ամենատարածված սխալն է։ Windows-ը քարտեզագրումը կրում է որպես պրոֆիլին կցված անվանման լուծման քաղաքականություն՝ իր առաջնահերթության կարգով ընդդեմ ցանկացած վերջածանցի ցանկի, որն արդեն ուներ միջերեսը։ Apple հարթակները համապատասխան տիրույթները կցում են ցանցային ընդլայնման DNS կարգավորումների օբյեկտին, և համակարգը կիրառում է դրանք յուրաքանչյուր սահմանափակ լուծիչի համար։ Այս ձևերից ոչ մեկը ուղի չէ, և ոչ մեկը չի կարող անհասանելի հասցեն հասանելի դարձնել։ Windows-ի անվանման լուծման քաղաքականություն տեղեկությունը թվարկում է այդ հարթակի դաշտերի անուններն ու առաջնահերթության կանոնները, և դրանք այն կանոնները չեն, որ օգտագործում են Apple-ի կամ systemd-ի փաստաթղթերը։
Ճիշտ պատասխանը դեռ ուղի է պահանջում
Լուծիչի պատասխանը միայն հասցե է, և հավելվածը դեռ պետք է հասնի դրան։ Բաժանված թունելի ձևավորումը հաճախ հրում է 10.20.0.0/16-ը և պահում լռելյայն ուղին, այնպես որ ներքին անունը լուծվում է, և կապը հետո կախվում է։ Հակառակ դեպքը նույնքան սովորական է. ուղին գոյություն ունի, հանրային լուծիչը մասնավոր անվանը պատասխանում է NXDOMAIN-ով, և ձախողումը գրանցվում է որպես երթուղավորման խնդիր։ Նախ ուղին թեստավորելը ձեզ թողնում է նայելու ուղիներին մի անվան համար, որը երբեք չէր լուծվելու։
Կա նաև երրորդ դարպաս, որը ոչ մի կես չի ծածկում։ Դարպասի ACL-ը, հրապարակի կանոնը կամ հաճախորդի կողմի քաղաքականությունը կարող են գցել կապը այն բանից հետո, երբ երկու որոշումներն էլ ճիշտ էին։ Երբ անունը լուծվում է, ուղին գոյություն ունի, և կապը դեռ ժամկետանց է լինում, դադարեցրեք DNS-ի թեստավորումը։
Անունների և ուղիների թեստավորումը ֆիքսված հաջորդականությամբ
Ընտրեք հաջորդականություն և պահեք այն, այլապես կհետապնդեք վերջին ձախողված քայլը։ Լուծեք փաստաթղթավորված ամբողջական ներքին անունը, հաստատեք, որ պատասխանը հասցե է, որը կարող է կրել երթուղային աղյուսակը, ապա կրկնեք հանրային անունով՝ ապացուցելու, որ թունելը ամեն ինչ չի որսացել։ systemd հոսթում հարցումն ու լուծիչի երթուղավորման տիրույթը մեկ հրամանի հեռավորության վրա են.
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows հաճախորդը նույն երկու հարցերն է տալիս այլ cmdlet-ներով։ Երկրորդը հայտնում է այն միջերեսը, որն իրականում կօգտագործեր համակարգը.
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Եթե որոնումը հասցե է վերադարձնում, և ուղու ստուգումը նշում է ֆիզիկական միջերեսը, ապա անվան կանոնն աշխատել է, իսկ ուղին՝ ոչ։ Եթե կարճ անունը ձախողվում է, մինչ ամբողջական անունը լուծվում է, վերջածանցների ցանկն է սխալ, ոչ թե լուծիչը։
Որտեղ է համեմատությունը սովորաբար սխալվում
Առաջին սխալը անկապ հանրային լուծիչից մասնավոր անվան մասին հարցնելն է և մերժումը VPN-ի մասին ապացույց կարդալը։ Երկրորդը ենթադրելն է, թե աշխատող հանրային որոնումն ապացուցում է թունելի լուծիչի ուղին։ Երրորդը բաժանված թունելավորումը և բաժանված DNS-ը մեկ ձևավորման որոշում համարելն է, մինչ տեղակայումը կարող է ճիշտ լինել մեկում և կոտրված՝ մյուսում։ Ամեն սխալ վստահ եզրակացություններ է տալիս թեստից, որը երբեք չի վարժեցրել մեղադրվող մասը։
Սեփական անվտանգ DNS ունեցող դիտարկիչը նույնպես կարող է շրջանցել համակարգի կանոնը, դրա համար էլ այն, որ մի դիտարկիչ ձախողվում է, մինչ մյուսը հաջողում է, հակասություն չէ։ Համեմատեք պատասխանող լուծիչին, ոչ թե բողոքող դիտարկիչին։
Երբ երկու կեսերն էլ տեսանելի են, մնացած հարցը քաղաքականության հարց է, ոչ տեխնիկական. որ անվանատարածքներն են պատկանում կազմակերպությանը, ով է տիրապետում յուրաքանչյուր պատասխանի, և դրանցից որոնք պետք է ընդհանրապես լքեն մեքենան։ Գրեք դա պրոֆիլի կողքին, որովհետև կանոնին հաջորդ հպվող մարդուն դա պետք կգա։