Ներքին անունները ձախողվում են VPN-ում, մինչդեռ հանրային կայքերը լուծվում են
Երկու անսարքություն գալիս է միասին՝ ինտրանետի անունը չի լուծվում, և հարցումները դեռ դուրս են գալիս թունելից։ Համեմատեք ադապտերների կարգը, վերջածանցը և ուղարկված լուծիչը։
Մեկ օգտատեր հաղորդում է, որ ինտրանետի հոսթի անունը VPN-ի միջոցով չի լուծվում։ Երկրորդ հաղորդումը, նույն նոթբուքից, ասում է, որ արտահոսքի թեստը դեռ ցույց է տալիս տեղական լուծիչի պատասխանները։ Դրանք մեկ խնդիր են թվում, բայց երկուսն են՝ տարբեր ապացույցներով, և առաջինի սովորական վերանորոգումը վատացնում է երկրորդը։ Բաժանեք դրանք, նախքան որևէ կարգավորում դիպչելը։
Երկու ախտանիշ, որ մեկ անսարքություն չեն
Ներքին անվան լուծման ձախողումը նշանակում է, որ հարցը գնացել է մի տեղ, որտեղ դրա պատասխանը չկա։ Թունելից դուրս եկող հարցումները նշանակում են, որ հարցը գնացել է սխալ տեղ նույնիսկ այն դեպքում, երբ պատասխանը հասանելի էր։ Սրանք հակադիր ձախողումներ են՝ մեկում բացակայում է պատասխանը, մյուսում կա ավելորդ նպատակակետ։
Թակարդն այն է, որ գրասենյակի լուծիչը ամենուր ավելացնելը ուղղում է առաջինը և երաշխավորում երկրորդը։ Հանրային լուծիչը ամենուր ավելացնելը հակառակն է անում։
Գրեք երկու դիտարկումներն էլ ժամանակի նշումով, ապա հերթով անցեք ներքևի չորս ստուգումները։
Ո՞ր ադապտերի լուծիչն է ստանում հարցը
Windows-ում DNS հաճախորդը սերվերներ է ընտրում ադապտերների կապման կարգով, և թունելի ադապտերը ինքնաբերաբար առաջինը չէ։ Բացեք ադապտերի լրացուցիչ կարգավորումները և հեռահար մուտքի միացումը տեղափոխեք ֆիզիկական ադապտերից վեր, ապա նորից միացեք, որպեսզի փոփոխությունը կիրառվի նոր սեսիայի վրա։
Կապման կարգը միայն առաջին կեսն է։ Հաճախորդը պետք է նաև իմանա, թե որ անուններն են պատկանում այդ ադապտերին, և դա վերջածանցի հարց է, ոչ թե կարգի։
Դրեք ipconfig /all արդյունքը նոթբուքի կողքին, երկուսն էլ վերցված, երբ թունելը ակտիվ է։ Աշխատող մեքենան իր գրասենյակային ադապտերի վրա ցույց կտա միացմանը հատուկ DNS վերջածանց, իսկ նոթբուքը թունելի վրա գուցե ոչինչ ցույց չտա։ Այդ տարբերությունը բացատրում է հաղորդումների մի ամբողջ դաս, որոնք ասում են, թե սերվերը հենց այնտեղ է, իսկ անունը դեռ ձախողվում է, որովհետև առանց վերջածանցի կարճ անունը երբեք չի լրացվում այն գոտուն, որը սպասարկում է գրասենյակի լուծիչը։
Կարճ անունը վերջածանց է ուզում ավելի շուտ, քան երթուղի
Առանց որակավորման հոսթի անուն մուտքագրելը լուծիչից խնդրում է գուշակել դոմեն։ Գուշակությունը գալիս է միացմանը կցված վերջածանցների ցանկից, և եթե այդ ցանկը դատարկ է, հարցումը դուրս է գալիս որպես մեկ պիտակ, որին ոչ մի մասնավոր գոտի չի համապատասխանի։
Պատճենեք աշխատող մեքենայի վերջածանցը VPN ադապտերի IPv4 հատկությունների մեջ DNS ներդիրում, ապա նորից միացեք։ Linux-ում համարժեքը թունելի հղման որոնման դոմենն է, որը systemd-resolved-ը ցուցադրում է յուրաքանչյուր հղման համար, ոչ գլոբալ։
Ձեր նշումներում երկու կարգավորումները առանձին պահեք։ Վերջածանցը փոխում է, թե ինչ է հարցվում, լուծիչի հասցեն՝ թե ում է հարցվում։ Մեկը ուղղելը, երբ մյուսը սխալ է, տալիս է պատահական թվացող արդյունք։
Հարցրեք լուծիչին ուղղակիորեն, ապա անունին
Ուղղակի հարցում գրասենյակի լուծիչին առանձնացնում է անվան խնդիրը ուղու խնդրից, որովհետև այն ամբողջությամբ շրջանցում է հաճախորդի լուծիչի ընտրությունը։
nslookup intranet.corp.example 10.20.0.53 nslookup intranet resolvectl status
Առաջին հրամանը հարցնում է կոնկրետ սերվերին լրիվ որակավորված անվան մասին։ Եթե այն պատասխանում է, լուծիչը և դեպի այն տանող ուղին կարգին են, և անսարքությունը ընտրության կամ վերջածանցի մեջ է։ Եթե ժամկետը լրանում է, հասցեն սխալ է կամ անհասանելի, և խնդիրը երթուղավորումն է, ոչ DNS-ը։ Երկրորդ հրամանը ցույց է տալիս, թե ինչ է լինում կարճ անվան հետ, իսկ երրորդը տպում է հղմանը հատուկ լուծիչի կարգավորումը systemd հոսթի վրա։
Ուշադրություն դարձրեք վայրի քարտերի պատասխաններին, որոնք որոշ ցանցեր վերադարձնում են անհայտ անունների համար։ Հավանական թվացող պատասխանը ապացույց չէ, որ նախատեսված սերվերն է պատասխանել, ուստի համեմատեք վերադարձված հասցեն այն հասցեի հետ, որն իրականում օգտագործում է ներքին ծառայությունը։ Եթե հասցեն պատկանում է կայանման էջի կամ պրոքսիի, լուծիչը պատասխանել է, բայց պատասխանը երբեք ձերը չի եղել։ Այդ տարբերությունը խնայում է մեկ ժամ՝ հետապնդելով թունել, որը ողջ ընթացքում աշխատում էր։
Linux-ում այն VPN հաճախորդը, որը վերագրում է /etc/resolv.conf ֆայլը, ամբողջովին փոխարինում է տեղական լուծիչներին։ vpnc-ն դա կանխելու համար ցուցադրում է DNSUpdate no կարգավորումը, և systemd-resolved-ը կարող է միայն ցանկված դոմենները ուղղել թունելի հղմանը։ Երկու մոտեցումներն էլ հանրային անունները պահում են տեղական լուծիչի վրա, մինչ ներքին անունները ուղարկում են գրասենյակ։
Արտահոսքը կանոն է, ոչ թե նշիչ
Անվան լուծումը UDP փոխանակում է 53 պորտի վրա, ուստի թունելը, որը կրում է վեբ երթևեկություն, բայց ոչ UDP, հարցումը թողնում է ֆիզիկական ուղու վրա։ Ապացուցեք դա՝ ֆիքսելով ֆիզիկական ցանցային քարտի վրա, մինչ հանրային անուն է լուծվում։ Այդ ինտերֆեյսի վրա ընթեռնելի տեսքով երևացող հարցումը նշանակում է, որ թունելը այն չի կրում։
sudo tcpdump -ni eth0 -c 20 'udp port 53' resolvectl query example.com
Եթե հարցումը հայտնվում է այդ ինտերֆեյսի վրա ընթեռնելի տեսքով, թունելը այն չի կրում։ Վերանորոգումը կանոն է, որը 53 պորտը թույլատրում է միայն VPN-ի ուղարկած լուծիչին և մերժում է այլ նպատակակետեր, գումարած հաճախորդի կարգավորում, որը լուռ չի հրաժարվում ուղարկված տարբերակից։
Այս վերջին մասը ավելի կարևոր է, քան թվում է։ Մեկնարկեք OpenVPN-ը այսպես՝ route-nopull և ուղարկված DNS տարբերակը անհետանում է երթուղիների հետ միասին, եթե քաշման զտիչը չլայնացվի այն պահելու համար։ և այն հաճախորդը, որը անտեսում է dhcp-option DNS կարգավորումը, կշարունակի օգտագործել այն, ինչ ուներ առաջ։ Սերվերի կողմի ցանկացած փոփոխություն պահանջում է նոր սեսիա՝ ուժի մեջ մտնելու համար, քանի որ լուծիչների ցանկը տրվում է, երբ թունելը բարձրանում է, և հնացած սեսիան շարունակում է ցույց տալ հին վիճակը։
Նախքան տոմսը փակելը գրեք, թե որ ձախողումն եք իրականում տեսել։ Ներքին պատասխանի բացակայությունը և թունելից փախչող հարցումը տարբեր վերանորոգումներ են պահանջում, և առաջինը ուղղող վերջածանցի փոփոխությունը կարող է լուռ վատացնել երկրորդը։ Հաջորդը, ով կվերցնի տոմսը, կվստահի պիտակին, ուստի պիտակը դարձրեք ճշգրիտ։