Ինչու nslookup-ը լուծում է VPN-ով, բայց բրաուզերը՝ ոչ

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

Ստորև բերված ստուգումները հետևում են այդ ուղիներին համակարգից դեպի դուրս։ Մի խմբագրեք VPN պրոֆիլը, մինչև չիմանաք, թե որ ուղին պատասխանեց և որը ձախողվեց։

Երեք քաղաքականություն են որոշում պատասխանը

Յուրաքանչյուր ինտերֆեյս կրում է իր լուծիչների ցանկը և որոնման վերջածանցները։ VPN ադապտերը սերվերներ է ավելացնում, մինչդեռ ֆիզիկական ադապտերը պահում է իրենը, և համակարգը կարող է վերցնել այն, որն առաջինն է պատասխանում, ուստի որոնումը կարող է սպասարկվել թունելից դուրս՝ առանց որևէ մեկի ընտրության։ Անունների լուծման քաղաքականության աղյուսակի կանոնները կարող են ընտրված տիրույթներ ուղարկել ընտրված սերվերներին, և հենց այդպես է սովորաբար արտահայտվում split DNS-ը Windows-ում։ Իսկ VPN հաճախորդը կամ դարպասը կարող են մղել լուծիչի հասցե, որը գոյություն ունի միայն մասնավոր ցանցի ներսում։

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

Ինչու բրաուզերը այլ հարց է տալիս

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

Հասցեների ընտանիքի նախապատվությունը բացատրում է ուշացում, ոչ թե ձախողում։ Այն բրաուզերը, որը միայն IPv4 կրող թունելում նախ IPv6 գրառումներ է հարցնում, սպասում է ժամկետի ավարտին, մինչև հետ կանգնի։ Firefox-ը հենց դրա համար նախապատվություն է կրել, և այն անջատելը ախտորոշիչ քայլ է, ոչ թե վերանորոգում։

Կարդացեք լուծիչների ցանկը և կանոնները

Windows-ում տպեք այն, ինչ պահում է համակարգը, նախքան տեսություն կառուցելը։ Get-DnsClientServerAddress-ը ցույց է տալիս սերվերները ըստ ինտերֆեյսի, Get-DnsClientNrptRule-ը թվարկում է անվանատարածքի կանոնները, իսկ Resolve-DnsName-ը պատասխանում է ճշգրիտ անունին համակարգի ուղով։ Համեմատեք այդ պատասխանը VPN-ի սերվերին հասցեով ուղիղ հարցման հետ։ Երբ Resolve-DnsName-ը ձախողվում է, իսկ ուղիղ հարցումը հաջողվում է, կասկածելին լուծիչների ցանկն է կամ անվանատարածքի կանոնը։

Ստուգեք նաև հենց անունը։ Ներքին կարճ անունը կարող է պահանջել մասնավոր վերջածանց, որը տալիս է միայն VPN ադապտերը, մինչդեռ լիարժեք որակավորված անունը լավ լուծվում է։ Հաջող որոնումից հետո վկայագրի նախազգուշացումը այլ խնդրի է պատկանում։

Անհասանելի մղված լուծիչը

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

Եթե լուծիչը անհասանելի է, վերանորոգումը երթուղի կամ ներառված ենթացանց է, ոչ թե այլ DNS սերվեր։

Գաղտնագրված DNS-ը շրջանցում է ամբողջ ուղին

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

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

Ձախողմանը համապատասխան վերանորոգումներ

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

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

Գրանցեք, թե որ ուղին պատասխանեց, որը ձախողվեց և ինչ փոխեցիք։ Այն ժամանակ նույն ախտանիշի հաջորդ զեկույցը կպահանջի մեկ հրաման՝ կես օրվա փոխարեն։