Բաժանված թունելը բացառում է դիտարկիչը, ոչ նրա DNS հարցումները

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

Տվյալների ուղին և լուծիչի ուղին բաժանվում են

Բացառումը հավելվածի փաթեթները հանում է թունելից, ինչը երթուղավորման և հրապատի որոշում է տվյալների ուղու վրա։ Անունների լուծումը այլ որոնում է. գործընթացը հարցնում է համակարգի լուծիչին, և այդ լուծիչը որոշում է, թե որ սերվերն է ստանում հարցը։

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

Գտեք, թե որ գործընթացն է տալիս հարցը

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Կարդացեք գործող կարգավորումը նախքան փորձարկելը. որ կապերն են կրում DNS սերվերներ, ինչ անվանատարածքներ են պահանջում, և արդյոք անուն-առանձին քաղաքականությունը վերացնում է լռելյայնը։ Linux-ում բաժանված DNS-ը օգտագործում է երթուղային դոմեններ, Windows-ում անունների լուծման քաղաքականության աղյուսակը նույն գործն է անում անվանատարածքների համար։ Ոչ մեկը չի երևում արտահոսքի փորձարկման էջից։

Որոշեք, թե որ լուծիչը որ անունը կտեսնի

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

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

Մի վերագրեք DNS-ի բոլոր դաշտերը, որպեսզի մեկ փորձարկման պիտակ կանաչ դառնա։ Պիտակը նկարագրում է մեկ գործընթացի մեկ հարցում մեկ պահին։

Ստուգեք հարցումն ու կապը առանձին

Փորձարկեք երկու ուղիները անկախ։ Կապի փորձարկումը ցույց է տալիս տվյալների երթուղին, իսկ լուծիչի փորձարկումը ցույց է տալիս, թե ով ստացավ անունը։

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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