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 সংরক্ষণ তাদের মালিকদের মাধ্যমে, সেই ক্রমে অবসর দিন, আর কী সরানো হলো তা টুকে রাখুন।

মাইগ্রেশন তখনই শেষ, যখন রাউটেড অ্যাক্সেস মডেল তালিকার জন্য কাজ করে, তখন নয় যখন TAP ইন্টারফেস ip link এর আউটপুট থেকে হারিয়ে যায়।