Ինչու MagicDNS-ը լուծում է սարքերը, բայց ոչ գրասենյակի հոսթանունները

MagicDNS-ը tailnet-ի յուրաքանչյուր սարքի տալիս է անուն, որը ստացվում է նրա մեքենայի անունից և tailnet-ի DNS դոմենից։ Այդ անունը ստեղծում է Tailscale-ը, և դրան պատասխանվում է Tailscale-ի լուծիչի ուղով։ Գրասենյակի հոսթանուն, ինչպիսին է files.office.example-ը, պատկանում է զոնայի, որը Tailscale-ը երբեք չի գրել, ուստի սարքի անվանափոխումը չի կարող այն ստեղծել։ Երկու անվանատարածքները գոյակցում են՝ պարզապես տարբեր սեփականատերեր ունեն։

Այդ մեխանիզմը շատ տարածված բողոքի հետևում է՝ Tailscale-ի հոսթը պատասխանում է, և ֆայլային սերվերը դեռևս լուծման սխալ է վերադարձնում։

Երկու անվանատարածք, երկու սեփականատեր

Սարքի անունը գեներացվում է մեքենայի սեփական հոսթանունից, բախումները լուծում է Tailscale-ը, և արդյունքը ապրում է tailnet դոմենի տակ։ Գրասենյակի զոնան պահպանում է նա, ով վարում է գրասենյակի լուծիչը, գրառումները ստեղծում են ադմինիստրատորը կամ դինամիկ գրանցումը։ Կարճ անունները թաքցնում են տարբերությունը՝ files-ը կարող է լինել որոնման վերջածանցի ընդլայնում, որին պատասխանում է գրասենյակի DNS-ը, tailnet սարք, կամ ընդհանրապես ոչինչ։ Ամբողջ անվան հարցումը ցույց է տալիս, թե որ համակարգն իրականում պատասխանեց։

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

Ուղղեք գրասենյակի զոնան իր լուծիչին

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

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

Հասանելիությունը գալիս է լուծումից առաջ

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

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

Անջատեք անվան ձախողումը ծառայության ձախողումից

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

Կրկնեք փորձարկումը ընտրված ելքի հանգույցով, եթե դա է սարքի սովորական ռեժիմը։ Ելքի հանգույցի DNS մշակումը տարբերվում է առանց ելքի հանգույցի կարգավորումից, և միայն մեկ ռեժիմում փորձարկելը կարող է բաց թողնել այն ձախողումը, որը օգտվողները իրականում տեսնում են։

Գրանցեք զոնան, լուծիչի հասցեն և այն երթուղին, որը կրում է հարցումը։ Այս երեքը բացատրում են MagicDNS-ի անակնկալների մեծ մասը՝ առանց վերանվանման ևս մեկ փուլի։