کیا مکمل ٹنلنگ لمبی تقسیم شدہ ٹنل فہرست سے زیادہ آسان ہے؟

تقسیم شدہ ٹنل فہرست تین ایپس سے شروع ہو کر مشین کے زیادہ تر حصے کو ڈھک لیتی ہے، اور ہر نئی سطر کسی کی استثنا ہوتی ہے۔ اس مقام پر فہرست خاموشی سے اضافی مراحل والا ڈیفالٹ بن چکی ہوتی ہے۔ مکمل ٹنلنگ ترتیب کو الٹ دیتی ہے: سب کچھ ٹنل میں داخل ہوتا ہے الا یہ کہ دستاویزی استثنا کچھ اور کہے۔ یہ زیادہ آسان ہے یا نہیں، یہ گیٹ وے اور ان مقامی خدمات پر منحصر ہے جو آپ توڑیں گے۔

اپنے برقرار رکھے گئے اصول گن کر شروع کریں

اندراجات گنیں، پھر گنیں کہ کتنے میں نامزد مالک اور آخری تصدیق کی تاریخ ہے۔ دوسرا عدد اہم ہے، کیونکہ بے مالک استثنا اس وقت جانچی نہیں جا سکتی جب اس سے متعلق سافٹ ویئر کا نام بدلے یا اسے تبدیل کیا جائے۔ قابلِ عمل فائل کے راستے سے منسلک اصول اپ ڈیٹ کے بعد خاموشی سے ناکام ہو جاتے ہیں، اور ناکامی پرانی بجائے غیر مستحکم VPN جیسی دکھتی ہے۔ اس پر رائے قائم کرنے سے پہلے فہرست لکھ لیں۔

ہر اندراج کو تین سوالوں کا جواب دینا چاہیے: اس کے بغیر کیا ٹوٹتا ہے، یہ کس نے طے کیا، اور اگر وجہ ختم ہو جائے تو آپ کیسے جان پائیں گے۔ جو اندراجات تینوں کا جواب نہیں دے سکتے وہ منتقلی کی بجائے حذف کے امیدوار ہیں، اور انہیں پہلے حذف کرنا بعد کی موازنہ کو دیانت دار بناتا ہے۔

اگر زیادہ تر اندراجات ٹریفک کا بڑا حصہ روٹ کرتے ہیں تو آپ پہلے ہی دیکھ بھال کے بوجھ کے ساتھ مکمل ٹنل چلا رہے ہیں۔ پھر فیصلہ اس بارے میں ہے کہ ڈیفالٹ کہاں رہتا ہے، نہ کہ یہ کہ ڈیفالٹ ہونا چاہیے یا نہیں۔

جانچیں کہ گیٹ وے ڈیفالٹ اٹھا سکتا ہے یا نہیں

مکمل ٹنلنگ ہر پیکٹ کو ایک ہی آلے پر منتقل کرتی ہے، جو اس آلے کے CPU بوجھ، conntrack جدول، پتہ ترجمہ اور اپ اسٹریم بینڈوتھ کی ضرورت کو ایک ساتھ بدل دیتی ہے۔ جو گیٹ وے چند اندرونی سب نیٹس کی آسانی سے خدمت کرتا تھا وہ ایک صارف کی تمام براؤزنگ کے لیے ناپا نہیں گیا ہو گا۔ اوسط کی بجائے اس سب سے بڑی متوقع بیک وقت سیشن تعداد کو دیکھیں، کیونکہ چوٹی پہلے ٹوٹتی ہے۔

ip -s link show dev tun0
conntrack -C
ss -s

مشخصات سے استدلال کی بجائے تبدیلی سے پہلے اور بعد میں وہی کام کا بوجھ ناپیں۔ ایک مشین پر عام استعمال کی ایک دوپہر دکھا دے گی کہ گیٹ وے حد کے قریب ہے یا نہیں، اور پیر کی صبح اسے دریافت کرنے کے مقابلے میں اس کی کوئی لاگت نہیں۔

راستے کے MTU کو بھی سرے سے سرے تک جانچیں، کیونکہ مکمل ڈیفالٹ ہر ایپ کو ٹنل کے زیادہ سے زیادہ پیکٹ سائز سے روشناس کرتا ہے۔ جو ایپس ٹنل سے باہر کام کرتی تھیں وہ اب ایسے فریگمینٹیشن رویے پر منحصر ہو سکتی ہیں جس کے بارے میں آپ کو کبھی سوچنا نہیں پڑا۔

تصدیق کریں کہ مقامی خدمات اور نجی DNS اب بھی کام کرتے ہیں

ایپ کے نام کی بجائے پروٹوکول کے مطابق وہ فہرست بنائیں جو مقامی رہنا چاہیے: پرنٹرز اور ڈسپلے کے لیے دریافت پروٹوکول، سمارٹ ہوم برج، راؤٹر کا انتظامی صفحہ، مقامی ڈویلپمنٹ سرور جو صرف LAN میں حل ہونے والے نام سے پہنچتا ہے۔ یہ تب ٹوٹتے ہیں جب ڈیفالٹ راستہ ٹنل کی طرف اشارہ کرنے لگے، اور خاموشی سے ٹوٹتے ہیں کیونکہ کلائنٹ پر کوئی خرابی درج نہیں ہوتی۔

نجی DNS دوسرا انحصار ہے۔ اگر اندرونی نام پہلے ٹنل کے حل کنندہ سے حل ہوتے تھے تو کچھ نہیں بدلتا؛ اگر وہ مقامی طور پر حل ہوتے تھے تو مکمل ڈیفالٹ کو انہیں زون جاننے والے حل کنندہ تک لے جانا ہو گا۔ تبدیلی کے بعد ایک اندرونی اور ایک عوامی نام آزمائیں، یہ ماننے کی بجائے کہ حل کنندگان کی فہرست بچ گئی ہے۔

مقامی استثنائیں اسی پروفائل میں لکھیں جو ان کی مالک ہے۔ صرف کسی کی یادداشت میں رکھی گئی استثنا اگلی منتقلی میں سب سے پہلے گم ہونے والی چیز ہے۔

ایک پروفائل منتقل کریں اور حدود کی تصدیق کریں

پروفائل کو اس کی اپنی کنفیگریشن کے ذریعے بدلیں، نہ کہ پہلے کے تجربات سے بچے ہوئے دستی راستوں پر نیا ڈیفالٹ تہہ کریں۔ وہ بچے ہوئے راستے ہی ایسی منتقلی کی عام وجہ ہیں جو کام کرتی دکھتی ہے اور ایک دن بعد متضاد رویہ دکھاتی ہے۔ پرانی پروفائل دستیاب رکھیں تاکہ واپسی دوبارہ تعمیر کی بجائے ایک انتخاب ہو۔

پھر دو حدود الگ الگ تصدیق کریں: کہ عوامی اور نجی منزلیں دونوں کام کرتی ہیں، اور یہ کہ ناپسندیدہ ٹریفک ٹنل سے باہر نہیں جاتی۔ کامیاب صفحہ لوڈ پہلی بات ثابت کرتا ہے اور دوسری کے بارے میں کچھ نہیں کہتا۔

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

دوبارہ جڑنے کے بعد اور کٹوتی کے بعد جانچ دہرائیں، کیونکہ گراوٹ کے دوران ٹریفک روکنے والا kill switch بعد میں درست طور پر بحال ہونے والے راستے سے مختلف خصوصیت ہے۔ آسان ڈیزائن وہ ہے جس کی حقیقی کوریج آپ کسی ایپ یا نیٹ ورک کی تبدیلی کے بعد بھی بیان کر سکیں۔