VPN-ը միացած է, բայց անունները ձախողվում են. որտեղ է իրականում կոտրվում DNS-ը

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

Ինչ է իրականում պետք որոնմանը

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

Հաճախորդը իմանում է իր լուծիչը VPN պրոֆիլից, թունելի DHCP-ից կամ սեփական կարգավորումից, և թե որ աղբյուրը հաղթի, կախված է հարթակից։ Windows-ում ipconfig /all ցուցադրում է DNS սերվերները յուրաքանչյուր ադապտերի համար, այնպես որ տեսնում եք՝ ուղարկված արժեքն իրոք հասե՞լ է։ Ուղարկված արժեքը, որը երբեք չի հասել օպերացիոն համակարգին, հանգիստ և սովորական ձախողում է։ Կարդացեք կարգավորված արժեքը նախքան պրոֆիլին դիպչելը։

Linux-ը և macOS-ը նույն հարցին պատասխանում են տարբեր հրամաններով, և պատասխանն արժանի է նույն ընթերցմանը՝ resolvectl status և scutil --dns երկուսն էլ թվարկում են սերվերները ըստ ինտերֆեյսի։ Համեմատեք այդ ցանկը այն հասցեի հետ, որը պրոֆիլը պնդում է, թե ուղարկում է։ Այստեղ անհամապատասխանությունը բացատրում է ամեն ինչ ներքևում, այնպես որ լուծեք այն նախքան անունները փորձարկելը։

Փորձարկեք մեկ հանրային և մեկ մասնավոր անուն

Հարցրեք սովորական հանրային հոսթի անունը և փաստաթղթավորված մասնավոր հոսթի անունը նույն մեքենայից և գրանցեք, թե որ սերվերն է պատասխանել յուրաքանչյուրին։ Եթե երկուսն էլ ձախողվեն, լուծիչը կամ նրա երթուղին կոտրված է։ Եթե ձախողվի միայն մասնավոր անունը, լուծիչը պատասխանել է, և հարցը դառնում է գոտին կամ երթուղավորումը։ Կատարեք երկու հարցումները մեկ րոպեի ընթացքում, որպեսզի երթուղու փոփոխությունը չկարողանա բացատրել տարբերությունը։

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

nslookup տպում է և՛ սերվերը, որին հարցրել է, և՛ ստացված պատասխանը, և դա հենց այն զույգն է, որ ձեզ պետք է։ Կատարեք այն երկու անգամ նույն տերմինալում և գրեք պատասխանող հասցեն յուրաքանչյուր պատասխանի կողքին։

nslookup example.com
nslookup host.corp.example 10.20.30.53

Հաստատեք, որ հաճախորդը իրոք հասնում է այդ սերվերին

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

Յուրաքանչյուր հարթակ դրան պատասխանում է մեկ տողով, և ելքում նշված ինտերֆեյսը ամբողջ պատասխանն է։ Եթե այն ցույց է տալիս ֆիզիկական ադապտերին, մինչ լուծիչը թունելի հետևում է, պրոֆիլը չի ուղարկում նախածանց, որը կծածկի այն։

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Բաժանված թունելի պրոֆիլում լուծիչը կարող է լինել ուղարկված երթուղիներից դուրս, ինչը պրոֆիլի խնդիր է, ոչ սերվերի։ Համեմատեք լուծիչի հասցեն ուղարկված նախածանցերի հետ և հաստատեք, որ դրանցից մեկը ծածկում է այն։ Նույն անհամապատասխանությունը բացատրում է, թե ինչու DNS-ը աշխատում է մի ցանցում և ձախողվում մյուսում նույնական պրոֆիլով։

Հիշեք, որ դիտարկիչները կարող են շրջանցել համակարգի լուծիչը

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

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

Մաքրեք քեշը և նորից փորձարկեք իրական առաջադրանքը

Կարգավորումը ուղղելուց հետո մաքրեք լոկալ լուծիչի քեշը, որպեսզի հին պատասխանը չապրի ուղղումից ավելի։ Կարճ վերականգնումից հետո նոր ձախողումը նշանակում է, որ պատճառը դեռ կա, ոչ թե մաքրումը ձախողվեց։ Ընտրեք այն տողը, որը համապատասխանում է ձեր մեքենային, որովհետև երեք քեշերը առանձին են։

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Այնուհետև կրկնեք սկզբնական առաջադրանքը, ոչ սինթետիկ որոնում, որովհետև առաջադրանքն է, ինչը կարևոր է օգտվողին։ Մեկ անգամ նորից միացեք, որպեսզի կրկնակի ստուգումը ծածկի այն վիճակը, որում օգտվողը իրոք կլինի։ Microsoft-ի nslookup-ի տեղեկագիրքը այն էջն է, որը արժե պահել հարցման արգումենտների համար։

Եթե անունները ձախողվում են միայն անջատվելուց հետո, հաճախորդը չի վերականգնել նախորդ կարգավորումը, ինչը կյանքի ցիկլի սխալ է՝ հաղորդելու համար, ոչ DNS սերվեր՝ փոխարինելու։ Աշխատող որոնումը նաև արտահոսքի թեստ չէ, որովհետև ելքի երկիրը ոչինչ չի ասում, թե որ լուծիչն է պատասխանել։