ولې 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 ډیرې حیرانتیاوې تشریح کوي۔