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 आश्चर्य स्पष्ट करतात।