OpenVPN लाई TAP बाट TUN मा सार्ने: काम गर्ने माइग्रेसन क्रम

dev tap लाई dev tun ले बदल्दा टनेलले के बोक्छ भन्ने परिवर्तन हुन्छ, केवल यसको नाम होइन। TAP इन्टरफेसले Ethernet फ्रेमहरू ब्रिजमा सुम्पन्छ, त्यसैले क्लाइन्टहरू अफिसको स्विचमा जोडिएझैं व्यवहार गर्छन्। TUN इन्टरफेसले IP प्याकेट बोक्छ, त्यसैले क्लाइन्टलाई मार्ग चाहिन्छ र अर्को पक्षलाई फर्कने बाटो चाहिन्छ। क्लाइन्ट, ठेगाना योजना र LAN को फिर्ता मार्ग सबै त्यो परिवर्तनसँगै सर्नुपर्छ।

माइग्रेसन टनेलसहितको नेटवर्क पुनर्डिजाइन हो, र तलको क्रमले यसलाई उल्टाउन सकिने बनाउँछ।

Ethernet मा वास्तवमै के निर्भर छ त्यसको सूची बनाउनुहोस्

होस्ट होइन, अनुप्रयोगहरूको सूची बनाउनुहोस्। प्रत्येकले मार्गित TCP वा UDP सेवा, ब्रोडकास्ट पत्ता लगाउने, अफिस LAN बाट DHCP, IP नभएको Ethernet प्रोटोकल, वा दुवै छेउ एउटै सबनेटमा छन् भन्ने अनुमानमध्ये कुन प्रयोग गर्छ निर्धारण गर्नुहोस्। सामान्य IP पहुँच मार्गित डिजाइनमा टिक्छ। कच्चा Ethernet फ्रेम चाहिने प्रोटोकल टिक्दैन, र कुनै पनि मार्गनिर्देशनले त्यसलाई काम गराउँदैन। पत्ता लगाउनेमा निर्भर अनुप्रयोगलाई कटओभर अगाडि निर्णय गरिएको प्रतिस्थापन संयन्त्र चाहिन्छ, त्यसैकै क्रममा होइन।

त्यो सूची नै स्वीकृति सूची पनि हो। सार्न नसकिने प्रत्येक प्रविष्टि अभिलेखित अपवाद वा त्यै कार्यभारका लागि मात्र सानो TAP खण्ड जीवित राख्ने कारण बन्छ।

ठेगाना र फिर्ता मार्ग योजना बनाउनुहोस्

LAN, पुरानो ब्रिज दायरा वा क्लाइन्टले पहिलै नै पुग्ने कुनै पनि नेटवर्कसँग नओभरल्याप हुने क्लाइन्ट प्रिफिक्स छान्नुहोस्। सबनेट टोपोलोजी सर्भरलाई dev tun, topology subnet र server 10.78.0.0 255.255.255.0 जस्तो टुक्रा चाहिन्छ, तर त्यो टुक्रा मात्र हो, काम गर्ने प्रोफाइल होइन। यसको वरिपरि स्वीकृत TLS, पहिचान, यातायात र पहुँच नीति राख्नुहोस्, र खाली भएको प्रमाणित गरेको प्रिफिक्स प्रयोग गर्नुहोस्।

त्यसपछि क्लाइन्टले पुग्नुपर्ने गन्तव्य र फिर्ता बाटो कसले दिन्छ भन्ने लेख्नुहोस्। सर्भरलाई फर्वार्डिङ सक्षम र अनुमति दिएको अगाडिको बाटो चाहिन्छ। LAN राउटरलाई नयाँ प्रिफिक्सतर्फ फर्कने मार्ग चाहिन्छ, वा डिजाइनलाई त्यसले जनाउने दृश्यताको लागतसहित स्रोत अनुवाद चाहिन्छ। क्लाइन्टमा धकेलिएको मार्गले क्लाइन्ट कन्फिगर गर्छ, LAN को जवाफ बाटो होइन।

अलग सुन्ने पोर्टमा परीक्षण गर्नुहोस्

काम गर्ने एक मात्र प्रवेश बिन्दु प्रतिस्थापन गर्नुको सट्टा नयाँ सेवा पुरानोको छेउमा यसको आफ्नै पोर्ट र आफ्नै ठेगाना दायरामा उभ्याउनुहोस्। माइग्रेसनका लागि कसैले CA पुनर्निर्माण नगरोस् भनेर विद्यमान दर्ता प्रक्रियामार्फत परीक्षण प्रोफाइल जारी गर्नुहोस्। परीक्षण मार्ग मात्र सक्रिय हुँदा एक प्रतिनिधि क्लाइन्ट जोड्नुहोस्, त्यसपछि दिइएका ठेगाना, निजी DNS, सूचीका अनुप्रयोग र रोकिएर रहनुपर्ने मार्ग तुलना गर्नुहोस्।

पुनः जडान र फिर्ता ट्राफिक परीक्षण समावेश गर्नुहोस्। पूरा हुने ह्यान्डशेकले अर्को पक्षले जवाफ दिन सक्छ कि सक्दैन भन्नेबारे केही भन्दैन।

रोलब्याकसहित समूहमा क्लाइन्ट सार्नुहोस्

असफलता आउटेज नभई सहयोग कार्य हुने गरी साना समूहमा माइग्रेट गर्नुहोस्। प्रत्येक समूहको वास्तविक कार्यप्रवाह उत्तीर्ण नभएसम्म पुरानो सेवा चलिरहेको र अभिलेखित राख्नुहोस्, र रोलब्याकलाई पुनर्निर्माण नभई अघिल्लो प्रोफाइलमा फर्कने परिवर्तनको रूपमा लेख्नुहोस्। प्रत्येक समूह सर्दा ठेगानामा आधारित फायरवाल नियम, अनुगमन र सर्भरले सुरु गरेको कुनै पनि पहुँच नयाँ प्रिफिक्सका लागि अद्यावधिक गर्नुहोस्।

पुरानो बाटो तुलनाका लागि अअझै रहँदा कसैले नभनेको अनुप्रयोग पत्ता लगाउने ठाउँ पनि समूहले दिन्छ।

स्वीकृतिपछि मात्र ब्रिज हटाउनुहोस्

TAP यन्त्र हटाउनु पहिलो होइन, अन्तिम चरण हो। केही मेटाउनु अगाडि ब्रिजले अजै सर्भरको व्यवस्थापन ठेगाना, अनुगमन मार्ग वा असम्बन्धित कार्यभार बोक्छ कि जाँच्नुहोस्। सुरुवाती निर्भरता, ब्रिज सदस्यता र DHCP आरक्षणहरू तिनीहरूका मालिकमार्फत, त्यही क्रममा, के हटाइयो भन्ने टिप्पणीसहित हटाउनुहोस्।

मार्गित पहुँच मोडेलले सूचीका लागि काम गर्दा माइग्रेसन सकिन्छ, ip link को आउटपुटबाट TAP इन्टरफेस हराउँदा होइन।