OpenVPN को TAP से TUN पर ले जाना: माइग्रेशन का एक क्रम जो काम करता है
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 आरक्षण उनके मालिकों के ज़रिए, उसी क्रम में रिटायर करें, और क्या हटाया गया इसका नोट रखें।
माइग्रेशन तब पूरा होता है जब रूटेड पहुँच मॉडल सूची के लिए काम करता है, तब नहीं जब TAP इंटरफ़ेस ip link के आउटपुट से गायब हो जाता है।