Թունելը աշխատում է, ուրեմն ինչու է մասնավոր անունը դեռ ձախողվում?

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

Ո՞ր լուծիչին հասավ հարցումը։

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Այստեղ խառնվում են երկու փուլ՝ սերվեր, որը հրում է լուծիչի հասցեն, և հաճախորդ, որը տեղադրում է այն ակտիվ կապի վրա։ Պրոֆիլը կարող է պարունակել ընտրանքը, և մատյանը կարող է ցույց տալ, որ այն գալիս է, մինչդեռ օպերացիոն համակարգը շարունակում է օգտագործել հին սերվերը։ Համեմատեք մատյանը կապի հաղորդածի հետ և վստահեք կապին։

Օգտագործեք հասցե, որին ամպային ցանցն իսկապես պատասխանում է

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

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

Թունելը չի կրում անվանատարածքը

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

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

Անցեք սահմանները հերթականությամբ

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

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

Պահեք շղթան այնտեղ, որտեղ հաջորդ մարդը կգտնի այն

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

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