پے در پے دو VPN ہاپ: آپ کا ٹریفک واقعی کون دیکھتا ہے؟
سلسلہ وار ہاپ پہلے گیٹ وے پر ڈکرپٹ اور دوبارہ انکرپٹ کرتے ہیں؛ نیسٹڈ ہاپ صرف بیرونی تہہ ہٹاتے ہیں۔ دونوں ڈیزائن دیکھیں اور جانیں کون سا آپریٹر کیا پڑھتا ہے۔
ہر کلائنٹ پروفائل ایک سرور کا نام دیتا ہے، اس لیے صارف کی جگہ سے ایک ٹنل اور تحفظ ختم ہونے کی ایک جگہ ہے۔ اُس پہلے گیٹ وے کے بعد کیا ہوتا ہے، یہ ایسا ڈیزائن فیصلہ ہے جو کلائنٹ کبھی نہیں دیکھتا، اور دونوں عام ڈیزائن جانچ میں بہت مختلف برتاؤ کرتے ہیں۔ سلسلہ وار زنجیر میں پہلا گیٹ وے ڈکرپٹ کرتا ہے اور دوبارہ انکرپٹ کرتا ہے۔ نیسٹڈ زنجیر میں یہ بیرونی تہہ ہٹاتا ہے اور ایسی اندرونی ٹنل آگے بھیجتا ہے جسے یہ کھول نہیں سکتا۔ ہاپ کی تعداد دونوں میں یکساں ہے، اسی لیے فرق گننا نہیں، کھینچنا چاہیے۔
کلائنٹ سے شروع کریں اور دونوں سروں کے نام دیں
وہاں سے شروع کریں جہاں صارف شروع کرتا ہے، کنکشن پروفائل میں۔ اس میں ایک دور دراز پتہ، ایک تصدیقی طریقہ اور، جب ڈیزائن معاونت کرے، راستوں کی فہرست ہوتی ہے۔ کلائنٹ سے گیٹ وے A تک اُس بیرونی ٹنل کو نام دیں اور مثال کے پتے دیں: کلائنٹ کا ٹنل پتہ 10.77.0.2، A کا 10.77.0.1، اور A کا عوامی آخری نقطہ 198.51.100.10، TEST-NET-2 دستاویزی حد سے لیا گیا تاکہ مثال میں کچھ بھی کسی حقیقی میزبان سے ٹکرا نہ سکے۔
اُس پروفائل میں گیٹ وے B کا کوئی ذکر نہیں ہے، اور یہ کوئی نقص نہیں۔ دوسرا ہاپ A کا ہے، اور کلائنٹ کی واحد ذمہ داری ٹریفک A تک پہنچانا اور جو واپس آئے اسے قبول کرنا ہے۔ A ٹنل ختم کرتا ہے، آگے بھیجتا ہے یا نیا کھولتا ہے — یہ وہ سوال ہے جس کا جواب اس پوری سیر کا بقیہ حصہ دیتا ہے، اور یہی طے کرتا ہے کہ A کیا پڑھ سکتا ہے۔
سلسلہ وار: A ڈکرپٹ کرتا ہے، پھر دوبارہ انکرپٹ
سلسلہ وار ڈیزائن میں A ٹریفک کو دو بار ختم کرتا ہے۔ یہ کلائنٹ سے تحفظ ہٹاتا ہے، ایپلیکیشن کا IP پیکٹ حاصل کرتا ہے، اور پھر اُس پیکٹ کو دوسری ٹنل سے بھیجتا ہے جو A نے B کی طرف بنائی ہے۔ ان دو کارروائیوں کے درمیان پیکٹ A کے آگے بھیجنے کے راستے میں نجی منزل کی طرف پتہ شدہ عام IP پیکٹ کے طور پر بیٹھا ہے۔
اس سے دو نتائج نکلتے ہیں جو صاف کہنے چاہئیں۔ A اندرونی پیکٹ پر پالیسی لاگو کر سکتا ہے، راستوں، فلٹر قواعد اور ماخذ و منزل کی لاگنگ کی صورت میں، اور A کو دو سیٹ اسناد رکھنے پڑتے ہیں: ایک کلائنٹ کے لیے سرور کے طور پر اور ایک B کے کلائنٹ کے طور پر۔ ہر لمحہ تحفظ موجود ہے، پھر بھی محفوظ شے A پر اپنی شناخت بدل لیتی ہے۔
اس سے یہ نہیں نکلتا کہ A ایپلیکیشن کا سادہ متن پڑھتا ہے۔ جب کلائنٹ اور خدمت TLS چلاتے ہیں اور ایک دوسرے کے سرٹیفکیٹ تصدیق کرتے ہیں، A پڑھنے کے قابل درخواست کے بجائے TLS ریکارڈ سلسلہ دیکھتا ہے۔ یہ تصدیق کرنے کے لیے کہ وہ تحفظ کہاں ختم ہوتا ہے، ٹنل کا خاکہ نہیں، خدمت کے سرٹیفکیٹ سلسلے کو دیکھنا پڑتا ہے۔
نیسٹڈ: A صرف بیرونی تہہ ہٹاتا ہے
نیسٹڈ ڈیزائن میں کلائنٹ پہلے B کی طرف اندرونی ٹنل بناتا ہے اور پھر وہ ٹنل بیرونی ٹنل کے اندر رکھ کر A تک لے جاتا ہے۔ A بیرونی سرخی ہٹاتا ہے، اندرونی ٹنل پاتا ہے اور اس کی چابیاں رکھے بغیر آگے بھیجتا ہے، اس لیے اندرونی تحفظ اب بھی B پر ختم ہوتا ہے۔
پھر کلائنٹ کا اوپری لنک دو تہیں اٹھاتا ہے، جبکہ A اور B کے درمیان راستہ ایک۔ A اندرونی ٹنل کے بیرونی پتے دیکھتا ہے، جو یہ جاننے کے لیے کافی ہے کہ ٹریفک ہے اور تقریباً کدھر جا رہا ہے، اور پے لوڈ پڑھنے کے لیے کافی نہیں۔ سلسلہ وار صورت سے پورا فرق یہی ہے، اور کوئی ہاپ گننے والا اسے نہیں دکھاتا۔ A اب بھی جو کر سکتا ہے وہ ہے جو پڑھ نہیں سکتا اسے آگے بھیجنے سے انکار کرنا، اور یہ اُس گیٹ وے کے آپریٹر کے لیے ہمیشہ دستیاب ہے۔
نیسٹنگ اُس خصوصیت کی قیمت لیتی ہے۔ ہر تہہ سرخی کا اضافی بوجھ بڑھاتی ہے، اس لیے MTU اور MSS کی منصوبہ بندی درست ہونے کے بجائے لازمی ہو جاتی ہے، اور ایک تہہ سے چلنے والا راستہ دو کے ساتھ بڑے پیکٹ خاموشی سے گرا سکتا ہے۔ ہر تہہ کو اپنا دوبارہ جڑنے اور زندہ رکھنے کا رویہ بھی چاہیے، اور ایک تہہ میں خرابی دوسری کے ذریعے جزوی رکاوٹ جیسی دکھتی ہے۔
صرف ٹنل نہیں، ناظرین بھی کھینچیں
ٹنل تصویر کا آسان حصہ ہیں۔ ناظرین ہی ڈیزائن کا موضوع ہیں، اس لیے ہر زاویۂ نظر کے لیے ایک سطر لکھیں اور بھریں کہ ہر ایک واقعی کیا پڑھ سکتا ہے۔
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
دو سطریں ہمیشہ گڈمڈ ہو جاتی ہیں: A کا آپریٹر اور کلائنٹ کی ٹنل کا فراہم کنندہ۔ یہ ایک ہی ادارہ ہو سکتے ہیں، اور الگ گیٹ وے نام انہیں خودمختار نہیں بناتے۔ خودمختار ملکیت کے لیے الگ انتظامی کنٹرول، الگ اسناد اور الگ لاگنگ چاہیے۔
میٹا ڈیٹا دونوں ڈیزائنوں میں بچا رہتا ہے۔ وقت، پیکٹ کے حجم اور کنکشن کی تعداد ہر ہاپ پر قابل مشاہدہ رہتی ہے، اس لیے دو ہاپ سگنل ہٹانے کے بجائے ارتباط کی قیمت بڑھاتے ہیں۔ نامرئی ہونے کا وعدہ کرنے والا ڈیزائن کسی کے اُس پر بھروسا کرنے سے پہلے اُس فہرست کے سامنے جانچا جانا چاہیے۔
چننے سے پہلے ناکامی کے راستے چلیں
صارف کو ملنے والے ترتیب میں کلائنٹ سے جان بوجھ کر چیزیں توڑیں۔ انٹرفیس اور اس کے MTU سے شروع کریں، کیونکہ نیسٹنگ تصدیق میں ناکام ہونے سے بہت پہلے پیکٹ کے حجم پر ناکام ہوتی ہے۔
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1پھر تحفظ کے آخری نکات کو مان لینے کے بجائے تصدیق کریں۔ جو ٹنل چالو ہو اُس کے اندر سے خدمت سے اس کا سرٹیفکیٹ مانگیں، اور کلائنٹ جو سلسلہ دیکھتا ہے اس کا موازنہ خدمت کے اصل میں پیش کردہ سلسلے سے کریں۔ دوبارہ دستخط کرنے والا یا مداخلت کرنے والا گیٹ وے وہ سرٹیفکیٹ بدل دیتا ہے، اور جانچ ایک ہی کمانڈ میں نظر آنے لگتی ہے۔
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullدوبارہ جڑنے کے میٹرکس کے ساتھ ختم کریں: کلائنٹ کی ٹنل گرتی ہے، B کی ٹنل گرتی ہے، A اور B کے درمیان راستہ بدلتا ہے۔ نوٹ کریں کہ کیا واپس آتا ہے اور کیا نہیں، اور کیا اندرونی کنکشن کبھی اپنے مطلوبہ کیریئر سے باہر کے راستے پر گرتا ہے۔ ہر آزمائش کے استعمال کردہ پتے درج کریں، کیونکہ کسی دوسرے رسائی نیٹ ورک پر اسے دہرانا کسی دوسرے سوال کا جواب دیتا ہے۔ ہر دوبارہ جڑنے کے بعد MTU جانچ بھی دہرائیں، کیونکہ بدلا ہوا راستہ ایک بھی کنفیگریشن سطر ہلے بغیر قابل استعمال حجم کم کر سکتا ہے۔
سلسلہ وار چنیں جب A کو اندرونی پیکٹ پر پالیسی لاگو کرنی ہو، یا جب کلائنٹ دو تہوں والی ٹنل نہ چلا سکے۔ نیسٹنگ چنیں جب اندرونی پے لوڈ A پر ناقابلِ مطالعہ رہنا ہو۔ انتخاب کو اس کے ناظرین اور MTU اعداد کے ساتھ لکھیں، اور اگلے شخص کو ایک سوال کا جواب دینے کے لیے پوری تصویر دوبارہ نہیں کھینچنی پڑے گی۔