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 पछि लागिरहनु सत्र बर्बाद गर्नु हो।

प्रतिस्थापन प्रमाणित नहुँदासम्म मूल प्रोफाइल र चलिरहेको कन्फिगरेसन राख्नुहोस्। क्लाइन्ट परिवर्तन फर्काउन छिटो हुन्छ; कसैले अनुमानमा भत्काएको ब्रिज नेटवर्क फेरि बनाउन त्यस्तो छिटो हुँदैन।