Փոխե՞լ է VPN-ը իմ DNS-ը։ Համեմատեք առաջ և հետո
Պրոֆիլը կարող է դիտավորյալ տեղափոխել ձեր հարցումները։ Համեմատեք լուծիչի քաղաքականությունը և փաստացի պատասխանը VPN-ի միանալուց առաջ և հետո՝ մեկ փոփոխական պահելով։
Միացնում եք թունելը, բացում մասնավոր վահանակը, և անունը լուծվում է մի հասցեի, որը երբեք չեք տեսել։ Կամ հակառակն է լինում՝ բրաուզերը շարունակում է աշխատել, մինչդեռ հրամանի տողի գործիքը հանկարծ ոչինչ չի լուծում։ Երկու արդյունքն էլ գալիս են նույն փոփոխությունից, և մարդիկ սովորաբար դա բացատրում են VPN-ի մասին մեկ նախադասությամբ՝ «օգտագործում է իր սեփական DNS-ը», ինչը բավականաչափ ճշգրիտ չէ վրիպազերծելու կամ ստուգելու համար։ Այդ նախադասության մեջ թաքնված են երկու հարց՝ ո՞ր հարցումներն է այս պրոֆիլը պետք է ստանձնի, և արդյո՞ք ձեր մեքենան իրոք ուղարկել է դրանք այն լուծիչին, որը տրվել է իրեն։ Դրանք առանձին պահելն է ամբողջ մեթոդը, որովհետև դրանք խառնող փորձարկումը երկու ուղղությամբ էլ վստահ սխալ պատասխան է տալիս։
Ինչո՞ւ է պրոֆիլն ընդհանրապես լուծիչ տրամադրում
Թունելի ներսում հեռավոր ծայրի հետևում գտնվող անունները սովորաբար լուծվում են հասցեների, որոնք գոյություն ունեն միայն այդ ցանցում։ corp.internal-ի նման մասնավոր գոտին չունի հանրային պատվիրակում, ուստի այն սպասարկող լուծիչը պետք է հասանելի լինի թունելի ներսից։ Նույն մեխանիզմը ծառայում է նաև երկրորդ նպատակին՝ երբ հարցումները այլապես դուրս կգային ձեր մատակարարի միջով, հեռավոր կողմի լուծիչը հարցումը պահում է գաղտնագրված ուղու ներսում։ Այդ պատճառով DNS սերվերի հասցեն գալիս է որպես կապի քաղաքականության մաս, այլ ոչ որպես գլոբալ կարգավորում, որը դուք մեկ անգամ ընտրել եք մեքենայի համար։
Հասցեն ինքնին ոչինչ չի որոշում։ Լուծիչը կարող է պատասխանել միայն այն դեպքում, երբ դեպի այն ուղի կա, և ամենահաճախ հանդիպող խափանումն այն լուծիչն է, որը հասանելի է միայն քանի դեռ թունելը բարձրացված է։ Երբ թունելն ընկնում է, իսկ քաղաքականությունը մնում է, հարցումները գնում են առանց ուղու հասցեի, և ախտանիշը ժամանակի սպառումն է, ոչ թե մաքուր սխալ։ Այդ տարբերությունը կարևոր է, երբ կարդում եք հաջորդ փորձարկման արդյունքը, որովհետև ժամանակի սպառումը մարդկանց ուղարկում է տրանսպորտի կարգավորումներ, որոնք երբեք ներգրավված չեն եղել։
Համեմատեք երկու ձևավորումները նախքան պատասխանները համեմատելը
Ամբողջական թունելը և բաժանված DNS-ը հակառակ սպասումներ են ստեղծում, և դրանցից ոչ մեկը խափանում չէ։ Ամբողջական թունելի դեպքում յուրաքանչյուր հարցում կարող է տեղափոխվել մատակարարի կամ կորպորատիվ լուծիչի մոտ, ուստի ակնկալելի է, որ հանրային անունները միանալուց հետո այլ կերպ պատասխանեն։ Բաժանված DNS-ի դեպքում միայն ցանկում նշված տիրույթներն են գնում մասնավոր լուծիչի մոտ, իսկ մնացած ամեն ինչ մնում է տեղական. Windows-ում տիրույթների ցանկը գտնվում է Name Resolution Policy Table-ում, macOS-ում՝ DNS կարգավորումների համապատասխան տիրույթներում, իսկ systemd-resolved հոսթում՝ յուրաքանչյուր կապի երթուղային տիրույթներում։
Այս համեմատությունն է, որ պետք է անել առաջինը, որովհետև այն որոշում է, թե ինչն է համարվում խափանում։ Բաժանված DNS-ի դեպքում հանրային անունը, որը պատասխանում է նոր լուծիչից, այն է, ինչ արժե ուսումնասիրել, մինչդեռ ճիշտ պատասխանող ներքին անունը համակարգն է, որն անում է իր գործը։ Ամբողջական թունելի դեպքում անոմալիան հանրային անունն է, որը դեռ պատասխանում է ձեր մատակարարի լուծիչից։ Microsoft-ի՝ VPN անունների լուծման փաստաթուղթը նկարագրում է այս կանոնների Windows հերթականությունը, ներառյալ այն, թե ինչպես է համապատասխան քաղաքականության գրառումը դիտարկվում ադապտերի սեփական սերվերներից առաջ։
Սենյակում կա նաև երրորդ լուծիչ, որը հեշտ է մոռանալ։ Բրաուզերի անվտանգ DNS-ը ինքն է լուծում անունները և կարող է շարունակել պատասխանել այն բանից հետո, երբ թունելը փոխել է օպերացիոն համակարգի քաղաքականությունը, ուստի բեռնվող էջը վկայում է, որ բրաուզերի լուծիչն է աշխատել, ոչ թե որ պրոֆիլը կիրառվել է։ Եթե համեմատում եք միայն այն, ինչ ցույց է տալիս բրաուզերը, ժամանակի կեսը ստուգում եք սխալ շերտը։
Գրանցեք ելակետային վիճակ միայն մեկ փոփոխականով
Փոխեք թունելը։ Միևնույն քայլում մի փոխեք նաև անունը, գործիքը կամ որոնման վերջածանցը։ Ընտրեք մի անուն, որի մասին ձեզ թույլատրվում է հարցնել, նշեք, թե որ հավելվածն եք օգտագործել, և գրեք կա՛մ վերադարձած հասցեն, կա՛մ ճշգրիտ սխալը։ Windows-ում Get-DnsClientServerAddress -AddressFamily IPv4-ը տպում է սերվերները յուրաքանչյուր ադապտերի համար, իսկ Get-DnsClientNrptPolicy-ը՝ քաղաքականության գրառումները. systemd-resolved-ով Linux-ում resolvectl status-ը ցույց է տալիս յուրաքանչյուր կապի DNS սերվերներն ու երթուղային տիրույթները. macOS-ում scutil --dns-ը տպում է լուծիչների այն հերթականությունը, որին համակարգը իրականում կհետևի։
Այնուհետև միացեք հաճախորդի սովորական կառավարման միջոցով և կրկնեք ճիշտ նույն հրամանները։ Պահպանեք առաջին ելքը, ոչ թե հիշողությունը դրա մասին, որովհետև համեմատությունն է ամբողջ իմաստը, և քեշը մաքրելուց հետո վերցված երկրորդ ընթերցումն արդեն այլ չափում է։ Եթե ելակետը վերցվել է բրաուզերը առջևում, իսկ միանալուց հետո գործարկումը կատարվում է տերմինալում, դուք համեմատում եք երկու լուծիչ, ոչ թե մեկ լուծիչի երկու վիճակ։
Հստակ հարցումը և հավելվածի որոնումը տարբեր փորձարկումներ են
Մեկ կոնկրետ սերվերի հարցնելը՝ nslookup name 10.20.0.1-ով կամ dig @10.20.0.1 name-ով, ապացուցում է մեկ բան՝ որ ձեր նշած սերվերը պատասխանում է, երբ հասանելի է։ Սա ամբողջությամբ շրջանցում է ընտրության տրամաբանությունը, ուստի չի կարող ասել, թե արդյոք համակարգը կընտրեր այդ սերվերն այս անվան համար։ Օգտագործեք այն՝ ստուգելու, թե արդյոք հատկացված լուծիչը հասանելի է, և մի օգտագործեք այն քաղաքականությունը ստուգելու համար։
Տեղական լուծիչով որոնումն իսկապես գործադրում է ընտրություն։ resolvectl query name-ն անցնում է նույն երթուղային տիրույթների կանոններով և հաղորդում, թե որ արձանագրությունն է պատասխանել, Resolve-DnsName-ը Windows-ում անցնում է քաղաքականության աղյուսակով և հաճախորդի քեշով, իսկ scutil --dns-ը ցույց է տալիս այն հերթականությունը, որին կհետևի որոնումը։ Գործարկեք երկու տեսակներն էլ և պահեք դրանք ձեր նշումների առանձին սյուներում։ Հաջող հստակ հարցումը ձախողված հավելվածի որոնման կողքին երթուղային կամ ընտրության խնդիր է, ոչ թե լուծիչ, որը հրաժարվում է աշխատել։
Քեշը կանգնած է ձեր և պատասխանի միջև։ Օպերացիոն համակարգը, տեղական stub լուծիչը, բրաուզերը և բացասական քեշը բոլորը պահում են արդյունքներ, ուստի որոնումը կարող է հաջողվել առանց մեկ փաթեթի մեքենայից դուրս գալու։ Արձանագրեք արդյունքը նախքան որևէ բան մաքրելը՝ ipconfig /flushdns, resolvectl flush-caches կամ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS-ում։ Բաց թողեք ցանցի լայն վերակայումը այս փուլում, որովհետև այն ոչնչացնում է այն ապացույցները, որ դեռ հավաքում եք։
Ի՞նչ է նշանակում տարբերությունը
Համեմատեք գրանցված երկու տողերը և դասակարգեք փոփոխությունը նախքան մեկ կարգավորման անգամ դիպչելը։
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Մեկ տող արժանի է շեշտադրման։ Այն անունը, որը լուծվում է, աշխատող ծառայություն չէ, և DNS-ի հաջողությունը միայն ասում է, որ հասցե է գտնվել։ Այն ոչինչ չի ասում փոխանցման, հրապարակային պատնեշի կանոնների կամ այն մասին, թե արդյոք ձեր հաշիվն ընդհանրապես կարող է օգտվել ծառայությունից, ուստի ավարտեք՝ փորձարկելով իրական հավելվածը, փոխարենը ենթադրելու, որ խափանումն ինքնըստինքյան հեռացել է։
Վերականգնեք ելակետը և ստուգեք այն
Անջատվեք հաճախորդի սեփական կառավարման միջոցով, ոչ թե գործընթացը սպանելով, ապա նորից կարդացեք նույն երեք հրամանները։ Յուրաքանչյուր կապի սերվերները, քաղաքականության գրառումները և ձեր փորձնական անվան պատասխանը պետք է վերադառնան ավելի վաղ գրառված ելակետին։ Մաքուր անջատումից հետո մնացած քաղաքականության գրառումն իրական արատ է, որն արժե գրանցել, և հենց դրա համար էլ գեներացված լուծիչի ֆայլի ձեռքով խմբագրումը վատ սովորություն է՝ ֆայլը վերագրվում է, և խմբագրումն անհետանում է, կամ խմբագրումը մնում է և ամրացնում լուծիչ, որն այլևս ուղի չունի։
Անցեք այս ցանկով մեկ անգամ՝ հերթականությամբ։ Որոշեք, թե որ ձևավորումն է պրոֆիլն իրականացնում, նախքան որևէ արդյունք գնահատելը։ Անունը, գործիքը և վերջածանցը պահեք ֆիքսված երկու գործարկումներում։ Առանձնացրեք հստակ հարցումը հավելվածի որոնումից։ Կարդացեք գործող քաղաքականությունը, ոչ միայն պատասխանը։ Մաքրեք քեշերը վերջինը՝ համեմատությունը գրելուց հետո։ Ստուգեք իրական հավելվածով, ապա մեկ անգամ վերագործարկեք և հաստատեք, որ անջատված վիճակը դեռ մաքուր է։