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 آلہ ہٹانا پہلا نہیں، آخری قدم ہے۔ کچھ بھی مٹانے سے پہلے جانچیں کہ پل اب بھی سرور کا انتظامی پتہ، نگرانی کا راستہ یا غیر متعلق کام کا بوجھ اٹھا رہا ہے یا نہیں۔ آغاز کے انحصارات، پل کی رکنیت اور ریزرویشن ان کے مالکان کے ذریعے، اسی ترتیب سے، کیا ہٹایا گیا اس کے نوٹ کے ساتھ ہٹائیں۔

منتقلی اس وقت مکمل ہوتی ہے جب روٹ شدہ رسائی کا ماڈل فہرست کے لیے کام کرے، نہ کہ جب ip link کے آؤٹ پٹ سے TAP انٹرفیس غائب ہو۔