ایک ہی لینکس مشین پر دو VPN: نتائج ملائے بغیر ہر ایک کو الگ جانچیں
دو سبز آئیکن کوئی موازنہ نہیں ہیں۔ ہر ٹنل کو اس کے اپنے نام کی جگہ میں رکھیں، پہلے توقع لکھیں، اور نتیجے پر بھروسا کرنے سے پہلے راستہ ثابت کریں۔
دو سبز کنکشن آئیکن موازنے جیسے لگتے ہیں اور عام طور پر محض اتفاق ہوتے ہیں۔ اگر ٹیسٹ کی درخواست دونوں میں سے کوئی بھی ٹنل استعمال کر سکتی تھی، تو نتیجہ بہترین صورت میں ان میں سے ایک کو بیان کرتا ہے اور بدترین صورت میں کسی کو بھی نہیں۔ ہر مشاہدے کو نیٹ ورک سیاق، مطلوبہ منزل اور ٹیسٹ چلنے سے پہلے لکھی گئی توقع دیں۔ خود سنبھالی ہوئی لینکس مشین پر، نام والی نیٹ ورک نام کی جگہیں ہی وہ علیحدگی خریدنے کا سب سے سستا طریقہ ہیں۔
دو سبز بتیاں کوئی موازنہ نہیں ہیں
نام کی جگہ روٹنگ جدولوں، انٹرفیسوں اور نیٹ ورک اسٹیک کی حالت کو الگ کرتی ہے، اس لیے ایک کے اندر شروع ہونے والی درخواست خاموشی سے دوسرے کی ٹنل ادھار نہیں لے سکتی۔ جو چیز یہ الگ نہیں کرتی وہ پروسیسر، طبعی اپ لنک یا میزبان پر چلنے والی نام حل کرنے کی سروس ہے۔ اسی آخری خلا میں یہ ٹیسٹ زیادہ تر بغیر کسی کے دیکھے ناکام ہوتے ہیں۔ جو تلاش نام کی جگہ سے باہر نکل کر میزبان کے حل کنندہ سے پوچھتی ہے، وہ ایسا جواب لوٹاتی ہے جس کا زیرِ جانچ ٹنل سے کوئی تعلق نہیں۔
یہ طریقہ کار پہلے سے تیار اور منظور شدہ دو ٹیسٹ نام کی جگہیں، کام کرنے والی بیرونی رابطہ اور معاون کلائنٹ فرض کرتا ہے۔ یہ کچھ بناتا نہیں، کچھ درج نہیں کرتا اور کوئی ترتیب تبدیل نہیں کرتا۔ جب کلائنٹ کو مکمل ڈیسک ٹاپ سیشن درکار ہو یا وہ اس سے باہر چلنے سے انکار کرے، تو الگ مجازی مشینیں ہی ایماندار انتخاب رہتی ہیں۔
پہلی بار چلانے سے پہلے توقع مقرر کریں
ہر سیاق کے لیے طے کریں کہ کامیابی کیسی دکھتی ہے: حل کنندہ، سروس کا نام، متوقع پتہ اور ٹنل گرنے پر مطلوب رویہ۔ وہ منصوبہ بند قدریں اپنے الگ کالم میں رکھیں، کیونکہ منصوبے اور مشاہدے کو ملانے والا ریکارڈ وقت کی مہر والی فرضی کہانی ہے۔ نیچے دی گئی فہرست وہی شکل ہے جو ریکارڈ کو درکار ہے، اور پہلے کنکشن سے پہلے ہر سطر بھرنے کے قابل ہونی چاہیے۔
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
حل کنندہ کی وائرنگ کو اس ریکارڈ میں اپنی سطر چاہیے، کیونکہ جھوٹ بولنے کا سب سے زیادہ امکان اسی میدان میں ہے۔ نام کی جگہ سے جڑی فائلیں، مثلاً /etc/netns/vpn-a/resolv.conf کمانڈ نام کی جگہ کے اندر چلنے پر اپنے معمول کے راستوں پر دکھائی دیتی ہیں، جیسا کہ iproute2 کا نام کی جگہوں کا حوالہ بیان کرتا ہے، تاہم نام سروس کی تبدیلی کی ترتیب اور اس کے شروع کردہ کوئی بھی مقامی حل کنندہ اب بھی تلاش کو میزبان کی طرف واپس کھینچ سکتے ہیں۔
ایک وقت میں ایک ٹنل، دوسری منقطع
B کے نیچے رہتے ہوئے A کو اس کے موجودہ مالک کے ذریعے جوڑیں، پھر انتظامی سیاق سے پالیسی، راستے اور منتخب راستہ دیکھیں۔ نیچے دیے گئے تین کمانڈ صرف حالت پڑھتے ہیں؛ صرف آخری نام کی سروس سے رابطہ کرتا ہے، اور ان میں سے کوئی بھی ایپلیکیشن درخواست نہیں بھیجتا۔
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalراستے کی تلاش منزل کے بارے میں ایک فرضی سوال کا جواب دیتی ہے، اس لیے یہ نہیں دکھا سکتی کہ سروس ٹریفک قبول کرتی ہے۔ ان دو قسم کے شواہد کو الگ کالموں میں رکھیں، کیونکہ مسترد شدہ کنکشن کے ساتھ صحت مند راستہ ایک حقیقی اور عام نتیجہ ہے۔ پھر اصل ایپلیکیشن کے ساتھ ایک بے ضرر مجاز درخواست بھیجیں، جو A کے سیاق میں اس کے معمول کے غیر مراعات یافتہ صارف کے طور پر شروع ہو، سرٹیفکیٹ کی تصدیق اور ایپلیکیشن کی توثیق برقرار رکھتے ہوئے، اور نتیجہ سروس کے دیکھے گئے ماخذ پتے کے ساتھ درج کریں۔ A کو اس کے مالک کے ذریعے منقطع کریں اور B کے لیے پوری بنیادی لکیر دہرائیں، اپنی کی گئی کسی بھی ترتیب کی تبدیلی کو نوٹ کرتے ہوئے، ورنہ دونوں بنیادی لکیریں موازنے کے قابل نہیں رہیں گی۔
دونوں اوپر، پھر ایک وقت میں ایک نیچے
مستحکم حالت آسان حصہ ہے۔ دونوں ٹنلیں جڑی ہوں تو ہر سیاق کی تلاش اور ایپلیکیشن درخواست دہرائیں، پھر ایک ٹنل توڑیں اور دوسری جانچیں۔ جب کنکشن کی ترتیب ہی سوال ہو تو الٹی ترتیب میں دوبارہ جڑیں۔
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20کیپچر وہ بحثیں طے کرتا ہے جو ایپلیکیشن کا نتیجہ طے نہیں کر سکتا: یہ دکھاتا ہے کہ درخواست آپ کے متوقع انٹرفیس سے نکلی یا کسی بالکل اور چیز سے۔ ہر تبدیلی کے لیے مالک کا عمل، وقت کی مہر، راستے کا نتیجہ، نام کا نتیجہ اور ایپلیکیشن کا نتیجہ درج کریں۔ پھر متاثرہ نام کی جگہ کے اندر محفوظ بندش کی شرط جانچیں، کیونکہ علیحدگی کوئی کل سوئچ نہیں ہے۔ نام کی جگہ دو ٹنلوں کو الگ رکھتی ہے؛ جب اس کی پروفائل کہے کہ ٹریفک رکنا چاہیے، تو یہ کسی کو بھی ٹریفک ڈھونے سے نہیں روکتی۔
یہ ریکارڈ کیا دعویٰ کر سکتا ہے اور کیا نہیں
ایک کامیابی اس ترتیب کے لیے، اس میزبان پر، اس وقت وہ مشاہدات ثابت کرتی ہے۔ یہ ایک ہی ڈیسک ٹاپ روٹنگ جدول بانٹنے والے دو کلائنٹ کے بارے میں کچھ نہیں کہتی، اور دونوں ٹنلوں کے بوجھ اٹھانے کے دوران تھروپٹ کے بارے میں بھی کچھ نہیں کہتی۔ یہ الگ ٹیسٹوں والے الگ سوالات ہیں، اور موازنہ ہر سطر سے منسلک سیاق جتنا ہی بہتر ہوتا ہے۔
ناکامیوں کو ریکارڈ میں کامیابیوں کے ساتھ رکھیں، یہ نشان زد کرتے ہوئے کہ اس وقت کون سی ٹنل اوپر تھی۔ جو صاف صفحہ پیمائش کے وقت کی حالت چھپاتا ہے وہ اسے دکھانے والے بدصورت صفحے سے بدتر ہے۔ ریکارڈ کو بعد میں دوبارہ قابلِ استعمال بناتا ہے سیاق، نہ کہ اسکور۔
ایک مشین پر دو ٹنلوں کا ایماندارانہ موازنہ ممکن ہے، لیکن صرف انہی سیاقوں میں جو آپ نے واقعی قابو کیے۔ اس سے آگے ہر چیز ایک ایسی خواہش ہے جس کے ساتھ سبز آئیکن لگا ہے۔