Ինչու է հոթսփոթը վերահասցեավորում DNS-ը մինչև VPN-ի միացումը։
Հոթսփոթը վերագրում է հարցումները իր ցանցում, և հոսթի անվան վերջնակետը լուծվում է նախքան որևէ թունելի գոյությունը։ Հետևեք, թե որ լուծիչը պատասխանեց յուրաքանչյուր հարցմանը։
Հյուրանոցային ցանցին միանալը ձեր առջև դնում է DNS-ի երկու որոշում տարբեր պահերին՝ այն հարցումները, որ սարքը կատարում է մուտք գործելիս, և այն հարցումները, որ արվում են թունելը կանգնելուց հետո։ Հոթսփոթը կարող է ազդել առաջինների վրա իր վերահսկած ցանցի միջոցով։ Երկրորդները կախված են հենց հաճախորդի քաղաքականությունից, ինչը ստուգելու առանձին բան է։
Անցեք կապը հերթականությամբ՝ առաջին DHCP վարձակալությունից մինչև այն հարցումը, որը լուծեց մասնավոր անուն։ Այն ժամանակ աջակցության տոմսում նույնական թվացող երկու խափանումներ հստակ բաժանվում են՝ մեկը տեղի ունեցավ թունելից առաջ, մյուսը՝ դրա ներսում։
Ինչի կարող է դիպչել հոթսփոթը և ինչի ոչ
Մուտքի ցանցը DHCP-ով տալիս է լուծիչի հասցե և կարող է որսալ 53 պորտը դեպի այդ հասցեն։ Դա բավական է յուրաքանչյուր անպաշտպան հարցմանը պատասխանել պորտալի հասցեով կամ արգելափակման էջով։ Դա նաև բավական է կոտրելու VPN հաճախորդին, որի վերջնակետը գրված է որպես հոսթի անուն։
Այն, ինչ հոթսփոթը չի կարող, հարցումը կարդալն ու վերագրելն է, երբ այն արդեն շարժվում է հաստատված թունելի ներսում, պայմանով, որ թունելն իսկապես տանում է այն։ Որսալը կախված է հարցը բաց տեքստով տեսնելուց։
Հարցումները միևնույն է դուրս են գալիս թունելից հոթսփոթի հետ չկապված պատճառներով՝ դիտարկիչի անվտանգ DNS կարգավորումը, split-DNS կանոն, որը կորպորատիվ վերջածանցը պահում է տեղական լուծիչում, կամ հաճախորդ, որը կարգավորված է DNS-ը թունելից դուրս թողնելու համար։ Յուրաքանչյուրը հաճախորդի կողմի ընտրություն է, և յուրաքանչյուրը դրսից նայելիս նման է հոթսփոթի միջամտության։
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Սկզբնական հարցումը տեղի է ունենում մինչև թունելի գոյությունը
Հոսթի անուն ստացած հաճախորդը նախ պետք է լուծի այն, և այդ պահին ոչ մի թունել չի պաշտպանում հարցումը։ Եթե հոթսփոթը պատասխանում է պորտալի հասցեով, բանակցությունը ձախողվում կամ կախվում է։ Եթե այն ոչնչով չի պատասխանում, հաճախորդը հայտնում է անվան սխալ, և թունելը երբեք չի սկսվում։ Երկու ելքերից յուրաքանչյուրը բացատրում է դատարկ թունելի մատյան, որը հակառակ դեպքում անմեղ է թվում։
Օպերացիոն համակարգերը նաև գործարկում են իրենց միացելիության ստուգումները և պորտալի հայտնաբերումը, որոնք նկարագրված են RFC 8910-ում և RFC 8952-ում, և այդ հարցումները դուրս են գալիս մինչև ցանկացած VPN-ի կանգնելը։ Դրանք վստահված սերվերի մատյանում տեսնելը սպասված վարք է, ոչ թե արտահոսքի ապացույց։
Գործնական լուծումը հաճախորդին տալ վերջնակետ, որը լուծում չի պահանջում։ Երբ դա անհնար է, նախ ավարտեք մուտքը, ապա միացեք։
Պարզեք, թե որ լուծիչը պատասխանեց
Հարցրեք համակարգին, ոչ դիտարկիչին, և գործարկեք հարցումը երկու անգամ՝ մեկը այն լուծիչով, որ սարքն այժմ օգտագործում է, մեկը՝ ֆիքսված հասցեի դեմ։
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Առաջին հրամանի պատասխանը, որը տարբերվում է երրորդից, ասում է, որ տեղական լուծիչը այլ բան է վերադարձնում, և հենց դա է անում վերահասցեավորող հոթսփոթը։ Երրորդի խափանումը առաջինի հաջողության հետ ցույց է տալիս պորտալին՝ տեղական լուծիչը մատուցեց մուտքի հասցե, մինչ արտագնա 53 պորտը դեն էր նետվել։ Երկուսում էլ ժամանակի սպառումը նշանակում է, որ ցանցը դեն է նետում DNS-ը, մինչև նույնականացումը ավարտվի։
Կրկնեք միանալուց հետո և համեմատեք։ Քեշավորված պատասխանը վերապրում է անցումը, ուստի մաքրեք քեշը կամ երկրորդ դիտարկման համար հարցրեք նոր անուն։
Հետագա հարցումները պահեք ձեր նախատեսած ուղու վրա
Ամբողջական թունելի պրոֆիլը, որը նաև որսում է DNS-ը, ամենապարզ դասավորությունն է՝ յուրաքանչյուր հավելվածի յուրաքանչյուր հարցում գնում է այն լուծիչին, որը թունելը մղում է, և տեղական ցանցը տեսնում է միայն գաղտնագրված երթևեկություն։ Ապացուցեք դա՝ միանալուց հետո լուծելով ներքին և հանրային անուն, ապա երկու պատասխանները համեմատելով այն բանի հետ, ինչ թունելի լուծիչը վերադարձնում է ինքնուրույն։
Split-DNS-ը պահանջում է մտադրությամբ գրված դոմենների ցանկ՝ կորպորատիվ վերջածանցները թունելով, մնացած ամեն ինչ տեղում, և երկուսի միջև ոչ մի համընկնում։
Դիտարկիչի անվտանգ DNS-ը այդ քաղաքականությունից դուրս է, ուստի եթե այն պետք է անջատված լինի, որ պրոֆիլը կանխատեսելի վարվի, անջատեք այն այդ պրոֆիլի համար, ոչ թե մեքենայի։ Դա արեք դիտարկիչի կարգավորումներում, ոչ թե խմբագրելով համակարգի լուծիչը, որպեսզի փոփոխությունը հաջորդ անգամ երևա։ Գրանցեք պատասխանը, լուծիչը և կապի փուլը մեկ տողում յուրաքանչյուր փորձի համար։ Այն հաշվետվությունը, որ ասում է, թե DNS-ը ձախողվել է հյուրանոցի Wi-Fi-ում, նկարագրում է ախտանիշ առնվազն երեք տարբեր պատճառով։