Wi-Fi कहता है जुड़ा है, कुछ भी लोड नहीं होता: पुराने Mac रिज़ॉल्वर

किसी शाब्दिक पते पर ping करें और वह जवाब देता है। किसी साइट को नाम से खोलें और कुछ नहीं होता, जबकि नेटवर्क आइकन ज़ोर देता है कि कनेक्शन ठीक है। जिस Mac ने अभी-अभी किसी VPN से जुड़ा है, उसमें यह संयोजन लगभग हमेशा यह बताता है कि लुकअप ऐसे सर्वर की ओर हैं जो अब पहुँच में नहीं है, यह नहीं कि नेटवर्क बंद है। पते किसी पहले के समय Wi-Fi सेवा पर पिन किए गए थे और तब से किसी ने उन्हें हटाया नहीं। बहिष्कार से निदान करें, फिर पिन की गई प्रविष्टियाँ मिटा दें।

मरम्मत फ़्लश नहीं, मिटाना है, और यह अंतर मायने रखता है क्योंकि ज़्यादातर लोग पहले जो कमांड आज़माते हैं वे बिल्कुल कुछ और करते हैं।

जुड़ा हुआ लिंक के बारे में एक कथन है

macOS हर नेटवर्क सेवा के लिए एक रिज़ॉल्वर कॉन्फ़िगरेशन रखता है। DHCP से आए मान एक स्रोत हैं, हाथ से लिखे मान दूसरा, और प्रोफ़ाइल द्वारा धकेले गए या क्लाइंट द्वारा लिखे गए मान तीसरा। पिन किए गए मान नेटवर्क जो देता है उससे ऊपर हैं, और स्टैक में कुछ भी उन्हें दोबारा सत्यापित नहीं करता। इसलिए जा चुका सर्वर सूची में तब तक रहता है जब तक कोई व्यक्ति उसे न हटाए या सेवा शून्य से फिर से न बने।

इसीलिए अपना हैंडशेक पूरा करने वाला टनल उस लुकअप में कुछ नहीं बदलता जो पहले ही गलत दिशा में था। VPN ने रिज़ॉल्वर जोड़ा; जो असफल हो रहा था उसकी जाँच उसने नहीं की।

नामों को पैकेटों से अलग करें

पहले किसी होस्ट तक शाब्दिक पते से पहुँचें। जब वह लोड होता है, पैकेट ठीक हैं और दोष रिज़ॉल्वर का है। जब वह लोड नहीं होता, वहीं रुकें और समस्या को रूटिंग समस्या मानें, क्योंकि DNS बदलाव पहले से उलझी तस्वीर में केवल एक चर जोड़ेंगे।

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

पिन किए गए सर्वर हटाएँ

नेटवर्क सेटिंग्स में, Wi-Fi सेवा का विवरण खोलें और DNS टैब पर जाएँ। हर सर्वर पंक्ति हटाएँ, बदलाव की पुष्टि करें, फिर खोज डोमेन में ऐसे मान देखें जो आपने कभी नहीं जोड़े। सूची खाली छोड़ें, सेवा को फिर से जोड़ें, और पुष्टि करें कि DHCP द्वारा दिया गया पता अपने आप फिर दिखता है। खाली सूची वह अस्थायी स्थिति है जो सिद्ध करती है कि पिन किए गए मान ही समस्या थे।

पुराने संस्करण वही पैनल एक स्तर गहरा, Advanced बटन के पीछे छिपाते हैं, समान व्यवहार और वही परिणाम के साथ।

पैनल नहीं, स्थिति पढ़ें

scutil --dns | head -40 उन रिज़ॉल्वरों को छापता है जो macOS वास्तव में उपयोग करता है, दायरे के अनुसार समूहित, और किसी ज्ञात आंतरिक नाम का तेज़ nslookup दिखाता है कि उत्तर आता है या नहीं। दोनों आउटपुट तुलना करें: साफ़ पैनल पर अब भी पुराना सर्वर सूचीबद्ध होने का अर्थ है कि वह सेटिंग किसी दूसरे लेखक के पास है। वह अलग बग है, अलग उपाय के साथ।

जब दोनों साफ़ दिखें और नाम अब भी असफल हों, तो खराबी कहीं और चली गई है और अब आप DNS कॉन्फ़िगरेशन डीबग नहीं कर रहे हैं।

प्रविष्टियाँ कौन वापस रखता है

मिटाने के बाद लौटने वाले सर्वरों का कोई स्रोत होता है। डिवाइस प्रबंधन में कॉन्फ़िगरेशन प्रोफ़ाइल देखें, क्योंकि प्रोफ़ाइल DNS ले जा सकती हैं और अपने ही समय-क्रम पर फिर मूल्यांकित होती हैं। क्लाइंट की प्राथमिकताओं में कनेक्ट होने पर DNS सेट करने का विकल्प देखें, और तय करें कि इस मशीन पर वह अब भी अपनी जगह के योग्य है या नहीं। अगर VPN को सचमुच एक निजी रिज़ॉल्वर चाहिए, तो उसे उन डोमेन तक सीमित करें जिनका वह मालिक है, उस वैश्विक सूची में लिखने के बजाय जिसे हर भविष्य का नेटवर्क विरासत में लेता है।

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

बाकी सब रखरखाव का तमाशा है: ऐसे कमांड जो जानबूझकर किए गए लगते हैं, मापने योग्य कुछ नहीं बदलते, और अगले व्यक्ति के लिए वही टूटा लुकअप छोड़ जाते हैं।