مکمل ٹنل کا راستہ اسے اٹھانے والے سرور کو کیوں کاٹ دیتا ہے

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

ایسا راستہ جو اپنی ہی ترسیل کھا جائے

انکیپسولیشن ہر پیکٹ کو دوسرے ہیڈر میں لپیٹتا ہے۔ بیرونی ہیڈر مقامی طبعی پتے سے سرور کے عوامی پتے تک بھیجا جاتا ہے، اور کسی بھی ٹنل کے وجود سے پہلے اسے طبعی رابطہ عبور کرنا ہوتا ہے۔

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

سب سے طویل سابقے کا میل کسی بھی میٹرک کو دیکھنے سے پہلے تلاش کا فیصلہ کرتا ہے، اس لیے ایک پتے کا راستہ مشین کے ہر ڈیفالٹ راستے سے آگے نکل جاتا ہے۔ مرمت کے پیچھے پورا طریقہ کار یہی ہے۔

ڈیفالٹ سے پہلے استثنا نصب کریں

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

زیادہ تر کلائنٹ یہ بغیر کہے کرتے ہیں۔ OpenVPN دور کا پتہ تلاش کرتا ہے اور ڈیفالٹ گیٹ وے دوبارہ لکھنے سے پہلے اسے پن کرتا ہے، اور اس کا route-delay اختیار ان پلیٹ فارمز کے لیے ہے جہاں یہ ترتیب دوڑتی ہے۔ wg-quick بالکل الگ راستہ لیتا ہے، پیکٹوں کو نشان زد کر کے اور پالیسی قاعدے سے مشورہ کر کے استثنا شامل کرنے کے بجائے۔ مختلف طریقہ کار، ایک ہی ضرورت: بیرونی پیکٹ کو اس ٹنل سے بچنا ہی ہوگا جو وہ خود بناتا ہے۔

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

سرور پر آئینے کا عکس

وہی جال دوسری طرف الٹا انتظار کرتا ہے۔ سرور کو دوسری ٹنل کے ذریعے ڈیفالٹ راستہ دیں، یا کلائنٹس کے عوامی پتوں کو ڈھانپنے والا راستہ اس کی طرف دھکیلیں، تو اس کے جوابات غلط سمت کی عادت اپنا لیں گے۔

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

وہ استثنائیں جو ٹنل مسلسل چراتی ہے

چند کاموں کو کھلا انٹرنیٹ چاہیے ہوتا ہے چاہے ٹنل ڈیفالٹ راستے کی مالک ہو، اور ہر ایک کو اپنا استثنا چاہیے۔ متحرک DNS اپڈیٹر عام طور پر پہلے ٹوٹتا ہے۔

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

جو استثنا کسی نے نہیں لکھا وہ ایسا استثنا ہے جسے اگلی دوبارہ تعمیر خاموشی سے گرا دے گی۔

دوبارہ جڑنے کے بعد اسے ثابت کریں، پہلے نہیں

ایک نہیں، تین منزلیں جانچیں: آخری نقطہ، ٹنل کے پیچھے ایک نجی پتہ، اور اس سے آگے ایک عوامی پتہ۔ ایک کامیاب تلاش باقی دو کے بارے میں تقریباً کچھ نہیں بتاتی۔

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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