Tailscale MagicDNS काम करता है, लेकिन macOS पर nslookup विफल होता है

Mac पर ping tailnet मशीन का नाम हल करता है जबकि nslookup विफलता लौटाता है, और दोनों कमांड सच कहते हैं। ऐप्स सिस्टम रिज़ॉल्वर से नाम हल करते हैं, जिसे Tailscale हर इंटरफ़ेस के लिए कॉन्फ़िगर करता है, जबकि nslookup और host एक स्थिर फ़ाइल पढ़ते हैं जिसे MagicDNS कभी नहीं छूता। दोनों रास्ते एक भी पैकेट खोए बिना अलग हो सकते हैं। कोई भी DNS सेटिंग बदलने से पहले तय करें कि आपके विफल ऐप ने कौन-सा रास्ता लिया।

दो हल करने के रास्ते, दो अलग जवाब

macOS पर ऐप ट्रैफ़िक सिस्टम रिज़ॉल्वर से गुज़रता है, और इंटरफ़ेस के अनुसार सीमित रिज़ॉल्वर प्रविष्टियाँ तय करती हैं कि कौन-सा सर्वर किस डोमेन के लिए जवाब देगा। Tailscale वहाँ अपनी MagicDNS प्रविष्टि स्थापित करता है, इसलिए Safari और ssh tailnet नाम ढूँढ लेते हैं। nslookup, host और dig इसके बजाय /etc/resolv.conf पढ़ते हैं या कमांड लाइन पर सर्वर लेते हैं, और वह फ़ाइल आमतौर पर अब भी राउटर या ऑफ़िस सर्वर का नाम बताती है। उस फ़ाइल को भेजे गए tailnet नाम के लिए कोई आधिकारिक जवाब प्रतीक्षा में नहीं है, इसलिए टूल विफलता बताता है जबकि सिस्टम रास्ता सफल होता है।

कोई भी टूल गलत व्यवहार नहीं कर रहा है। वे अलग-अलग सर्वर से पूछते हैं, और उन सर्वरों में से केवल एक ही आपके tailnet के बारे में जानता है।

सिस्टम रास्ते से वही नाम जाँचें

सिस्टम लुकअप कॉल को पहला परीक्षण बनाएँ, फिर उसकी तुलना सीधे MagicDNS रिज़ॉल्वर को भेजी गई क्वेरी से करें। दोनों में वर्तनी एक जैसी रखें, tailnet डोमेन सहित, क्योंकि छोटा नाम और पूरी तरह योग्य नाम अलग-अलग सवाल हैं जिनके अलग-अलग जवाब हैं।

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

वे तीन आउटपुट तीन सवालों के जवाब देते हैं: सिस्टम क्या लौटाता है, किन डोमेन के लिए कौन-से रिज़ॉल्वर कॉन्फ़िगर हैं, और MagicDNS स्वयं क्या जानता है। दूसरे और तीसरे में मौजूद पर पहले में अनुपस्थित नाम tailnet की नहीं, स्थानीय कॉन्फ़िगरेशन की ओर संकेत करता है।

नाम हल होने के बाद सेवा जाँचें

सही DNS जवाब केवल यह साबित करता है कि कोई नाम किसी पते से जुड़ा है। इसके पीछे की सेवा रुकी हो सकती है, पोर्ट किसी एक्सेस नियम से फ़िल्टर हो सकता है, और प्रमाणपत्र आपके टाइप किए गए से अलग होस्ट का नाम बता सकता है।

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

मूल त्रुटि पाठ रखें, क्योंकि प्रमाणपत्र चेतावनी, कनेक्शन समय-सीमा और नाम-न-मिला—तीनों अलग-अलग जगह ले जाते हैं। नेम सर्वर बदलने से तीसरा ठीक होता है और पहले दो पर एक पूरी दोपहर बर्बाद होती है।

MagicDNS ऑफ़िस DNS का विकल्प नहीं है

ऑफ़िस ज़ोन के भीतर का नाम tailnet डिवाइस का नाम नहीं है, भले ही वही क्लाइंट दोनों तक पहुँच सके। जब गंतव्य सबनेट राउटर के पीछे होता है, क्लाइंट को उस ज़ोन के लिए आंतरिक रिज़ॉल्वर की ओर इंगित split DNS चाहिए, जो MagicDNS से अलग सेटिंग है और उसके साथ प्रलेखित है।

खोज डोमेन भी मायने रखते हैं। अयोग्य छोटे नाम में क्रम से हर कॉन्फ़िगर किया गया प्रत्यय जोड़ा जाता है, इसलिए हाल ही में किसी दूसरे नेटवर्क से जुड़ा लैपटॉप पुराने प्रत्यय से हल हो सकता है। ज़ोन को टूटा घोषित करने से पहले जाँचें कि कौन-सा प्रत्यय लागू हुआ।

जब दोनों रास्ते विफल हों, tailnet के तथ्य निर्णय करते हैं

अगर सिस्टम लुकअप और सीधी क्वेरी दोनों उस डिवाइस के लिए विफल हों जिसे आप मानते हैं कि मौजूद है, तो समस्या Mac के रिज़ॉल्वर से ऊपर है।

एडमिन कंसोल में मशीन का नाम और tailnet डोमेन पुष्ट करें, पुष्ट करें कि डिवाइस ऑनलाइन और स्वीकृत है, और पुष्ट करें कि क्लाइंट की DNS सेटिंग स्थानीय रूप से अक्षम नहीं हुई है। ऑफ़लाइन डिवाइस अपना नाम रखता है और उसके पास लौटाने के लिए कोई पता नहीं होता।

फिर साक्ष्य के आधार पर चुनें। जो नाम सिस्टम रास्ते पर हल होता है और nslookup में विफल होता है वह टूल-रास्ते का अंतर है; जो नाम हल होता है पर सेवा मना करती है वह एक्सेस या प्रमाणपत्र की समस्या है; जो नाम कहीं हल नहीं होता वह tailnet या DNS कॉन्फ़िगरेशन की समस्या है। तीन मालिक, तीन सुधार, और MagicDNS दस्तावेज़ पहले मामले के macOS ब्यौरे को कवर करता है।