macOS पर OpenVPN TAP: डीबग करने से पहले क्लाइंट जाँचें

एक पुराना प्रोफ़ाइल आधुनिक Mac पर आता है, क्लाइंट उसे बिना किसी शिकायत के आयात करता है, और कनेक्शन टूट जाता है या उससे कभी ट्रैफ़िक नहीं गुज़रता। प्रमाणपत्रों पर पूरी दोपहर बिताने से पहले प्रोफ़ाइल में डिवाइस पंक्ति पढ़ें। अगर वहाँ dev tap लिखा है, तो आप क्लाइंट से Ethernet जैसा इंटरफ़ेस माँग रहे हैं, और macOS पर ऐसे अधिकांश सत्र इसी अनुरोध पर समाप्त होते हैं।

चरण 1: पुष्टि करें कि प्रोफ़ाइल वास्तव में TAP माँगता है

प्रोफ़ाइल का नाम बदला जाता है, लपेटा जाता है और फिर से निर्यात किया जाता है, इसलिए वही फ़ाइल जाँचें जो आपने वास्तव में आयात की। डिवाइस निर्देश और कोई भी include खोजें जो उसे ओवरराइड कर सके। ज़्यादातर मामलों में आउटपुट की दो पंक्तियाँ सवाल तय कर देती हैं। जब dev और dev-type दोनों दिखें, तो बाद वाला निर्देश जीतता है, और कॉपी किया गया प्रोफ़ाइल ठीक ऐसी ही बारीकी छिपाता है।

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

अगर फ़ाइल में dev tap या dev tap0 है, तो क्लाइंट को TAP इंटरफ़ेस लागू करना होगा। अगर उसमें dev tun है, तो इस लेख का बाकी हिस्सा लागू नहीं होता और खराबी कहीं और है।

क्लाइंट का नाम और संस्करण, macOS का संस्करण और प्रोफ़ाइल कहाँ से आया, यह लिख लें। ये तीन तथ्य तय करते हैं कि नीचे दिए दो रास्तों में से कौन-सा रास्ता संभव भी है।

चरण 2: जानें कि डिवाइस मोड वास्तव में क्या बदलता है

TUN इंटरफ़ेस IP पैकेट ले जाता है। क्लाइंट IP साथी को संबोधित पैकेट पढ़ता और लिखता है, और ऑपरेटिंग सिस्टम उन्हें किसी भी अन्य इंटरफ़ेस की तरह रूट करता है।

TAP इंटरफ़ेस Ethernet फ़्रेम ले जाता है, जिनमें ब्रॉडकास्ट और ARP भी शामिल हैं। यही ब्रिज वाले सर्वर को DHCP से पते बाँटने और क्लाइंट को चिल्लाकर डिवाइस खोजने देता है, और इसीलिए कुछ पुराने डिज़ाइन इस पर निर्भर हैं।

कीमत यह है कि TAP को ऐसा ड्राइवर चाहिए जो सिस्टम को Ethernet इंटरफ़ेस दिखाए। Apple ने उस कर्नेल एक्सटेंशन मॉडल को बंद कर दिया है जिस पर पुराने Mac TAP ड्राइवर निर्भर थे, और उसका जगह लेने वाला API उन क्लाइंट में जादुई रूप से नहीं आता जिन्हें कभी इसे इस्तेमाल करने के लिए अपडेट नहीं किया गया। प्लेटफ़ॉर्म की क्षमता और भेजा गया उत्पाद दो अलग चीज़ें हैं।

चरण 3: संगत क्लाइंट और माइग्रेशन के बीच चुनें

दो ईमानदार रास्ते हैं। पहला ऐसा क्लाइंट है जिसका प्रकाशक आपके macOS संस्करण और हार्डवेयर के लिए घोषित करता है कि वह आपके ज़रूरी TAP इंतज़ाम का समर्थन करता है। चार साल पुरानी फ़ोरम पोस्ट नहीं, और संग्रहीत इंस्टॉलर नहीं: वर्तमान घोषणा के साथ एक परीक्षण कनेक्शन।

दूसरा है सेवा को TUN पर ले जाना, जो क्लाइंट बदलाव जितना ही सर्वर बदलाव है। इसके लिए रूटेड टोपोलॉजी, पतों का पूल, दूरस्थ नेटवर्क के लिए धकेले गए रूट और उन नेटवर्क से पूल तक वापसी मार्ग चाहिए।

जो काम नहीं करता वह है अपनी स्थानीय प्रति में tap को tun बनाना और आशा करना। सर्वर अब भी ब्रिज कर रहा है, क्लाइंट अब IP बोलता है, और कुछ भी मेल नहीं खाता।

चरण 4: चालू सेवा बदलने से पहले तथ्य जुटाएँ

मूल प्रोफ़ाइल को अछूता रखें और प्रयोगों के लिए प्रति बनाएँ। एक मिनट में बहाल हो सकने वाली फ़ाइल साफ़-सुथरे फ़ोल्डर से ज़्यादा क़ीमती है। बदलाव के काम करने लगने पर प्रति को जान-बूझकर हटा दें, सूची में एक जैसे दिखने वाले दो प्रोफ़ाइल न छोड़ें। यही एक आदत असफल माइग्रेशन के बाद होने वाली ज़्यादातर उलझन रोकती है। मौजूदा व्यवहार दर्ज करें ताकि आप साबित कर सकें कि क्या बदला: टनल ऊपर आता है या नहीं, पता मिलता है या नहीं, किसी जाने-पहचाने होस्ट तक पहुँचते हैं या नहीं, और नाम हल होता है या नहीं।

गेटवे के मालिक से तीन सवाल पूछें। सर्वर ब्रिज वाली टोपोलॉजी पर चल रहा है या रूटेड? कौन-से दूरस्थ प्रीफ़िक्स पहुँच-योग्य होने चाहिए? और कॉन्फ़िगरेशन बदलने के लिए रखरखाव विंडो है, या सर्वर को छुए बिना काम करने की उम्मीद है?

इनके जवाब तय करते हैं कि आप आज दोपहर क्लाइंट की समस्या हल कर रहे हैं या अगले हफ़्ते नेटवर्क बदलाव की योजना बना रहे हैं।

चरण 5: दोनों सिरों से माइग्रेशन जाँचें

जब सर्वर के पास रूटेड कॉन्फ़िगरेशन हो और आपके पास मेल खाता प्रोफ़ाइल हो, तो इस क्रम में परखें: टनल बनता है, क्लाइंट को नए पूल से पता मिलता है, दूरस्थ पक्ष का होस्ट जवाब देता है, और धकेली गई DNS सेटिंग से नाम हल होता है।

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

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

जब फिर भी विफल हो, तो पहली त्रुटि पढ़ें

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

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