مشترکہ TAP VPN کو پورٹل پر اب بھی HTTPS کیوں درکار ہے
TAP VPN ساتھی کی تصدیق کرتا ہے، اس کے پیچھے موجود سروس کی نہیں۔ پورٹل پر ہوسٹ نام کی توثیق رکھیں اور جن پڑوسیوں پر اعتماد نہیں انہیں الگ رکھیں۔
دو آلات کے پاس درست VPN اسناد ہیں اور وہ ایک ہی برج شدہ Ethernet حصہ مشترکہ رکھتے ہیں۔ ان میں سے صرف ایک کو دفتری پورٹل کی طرف سے جواب دینا چاہیے، اور دوسرا اب بھی اس حصے پر پورٹل کا پتہ دعویٰ کر سکتا ہے۔ سرنگ نے اپنا کام کیا: اس نے دونوں ساتھیوں کی تصدیق کی اور سرور تک ہر راستے کو خفیہ کیا۔ جو اس نے نہیں کیا وہ یہ تصدیق کرنا تھا کہ ان میں سے کس کے پاس سروس کا نام ہے، اور یہی خلا وجہ ہے کہ پورٹل کو اب بھی درست سرٹیفکیٹ درکار ہے۔
VPN اصل میں کس چیز کی تصدیق کرتا ہے
VPN کا ہاتھ ملانا ایک سوال کا جواب دیتا ہے: کس ساتھی نے یہ سرنگ کس کلیدی مواد کے ساتھ مکمل کی۔ یہ جواب ہر ساتھی اور ہر رابطے کے لیے ہے، اور اس ساتھی کی بعد میں پیش کردہ سروسز کے بارے میں کچھ نہیں کہتا۔ TAP حصے میں ساتھی ایک پتہ بھی نہیں ہے، کیوں کہ وہ کوئی بھی MAC اور کوئی بھی IP پیش کر سکتا ہے جسے برج سیکھنے کو تیار ہو۔ تصدیق سرنگ کے سرے پر رکتی ہے، ایپلیکیشن پر نہیں۔
تین سوالوں کو ایک میں ملانے کے بجائے الگ کریں۔ ہر ایک کا اپنا طریقہ کار اور اپنا ناکامی کا انداز ہے۔
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
کسی تعیناتی میں مکمل طور پر تصدیق شدہ سرنگ اور اس کے پیچھے مکمل طور پر غیر تصدیق شدہ سروس ہو سکتی ہے۔ اس میں ایسے ہوسٹ پر تصدیق شدہ سرٹیفکیٹ بھی ہو سکتا ہے جس کا دوسری سطح کا پتہ کوئی دوسرا ساتھی دعویٰ کر رہا ہو، اسی لیے ڈیزائن میں ایک کے بجائے دوسرے کے آنے کے بجائے دونوں کنٹرول ہونے چاہئیں۔ جدول تین سطروں میں پوری دلیل ہے۔
مشترکہ حصے پر ARP کوئی ڈائریکٹری نہیں
ARP مقامی لنک پر IPv4 پتے کو MAC سے جوڑتا ہے اور اس لنک پر کسی سے بھی جواب قبول کرتا ہے۔ نرم گیر برج شدہ حصے پر ساتھی کسی دوسرے آلے کا پتہ دعویٰ کر سکتا ہے، اور برج فریموں کو اسی کو بھیجتا ہے جس نے آخری بار جواب دیا۔ سرور تک ہر کلائنٹ راستے کو خفیہ کرنے سے یہ نہیں بدلتا، کیوں کہ فریم برج تک پہنچنے سے پہلے ہی ڈکرپٹ ہو جاتے ہیں۔ ARP کی اعتماد کی حد سرنگ نہیں، حصہ ہے۔
دیکھیں کہ ہوسٹ نے اصل میں کیا سیکھا: ip neigh show موجودہ نقشہ جات اور ان کی حالت کی فہرست دیتا ہے، اور عام آپریشن کے دوران دو MAC پتوں کے درمیان بدلنے والا اندراج نظر انداز کرنے کے بجائے تحقیق کے قابل علامت ہے۔ صحت مند چھوٹے حصے میں ایسے اندراجات طویل عرصے تک مستحکم رہتے ہیں۔
ساتھیوں کی علیحدگی اور برج پالیسی بالکل اسی صورتِ حال کے لیے ہیں۔ جب سروس صرف IP ہو اور آلات کو ایک دوسرے کے فریم دیکھنے کی کوئی وجہ نہ ہو تو روٹ شدہ ڈیزائن عام طور پر بہتر جواب ہے۔
سرٹیفکیٹ کی توثیق وہیں رکھیں جہاں سروس ہے
ایپلیکیشن کا TLS اس سوال کا جواب دیتا ہے جو سرنگ نہیں دے سکتی: کیا یہ وہی سروس ہے جہاں میں پہنچنا چاہتا تھا۔ براؤزر ہوسٹ نام کو سرٹیفکیٹ کے خلاف جانچتا ہے، اور یہی جانچ زنجیر کا واحد حصہ ہے جو ساتھی کے بجائے پورٹل کا نام لیتا ہے۔
اس سے پہلے کہ انتباہ کو محض ظاہری بات سمجھیں، دیکھیں کہ سرور کیا پیش کرتا ہے۔ openssl s_client -connect portal.example.internal:443 -servername portal.example.internal زنجیر اور موضوع کے متبادل نام چھاپتا ہے۔ اگر آپ کا لکھا ہوا نام اس فہرست میں نہیں ہے تو انتباہ درست ہے اور سرٹیفکیٹ ہی درست کرنے والی چیز ہے۔ صارفین کو اسے نظرانداز کرنا سکھانا کام کرنے والے کنٹرول کو سجاوٹ میں بدل دیتا ہے۔
OpenVPN برجنگ گائیڈ Ethernet ماڈل اور اس کے گرد پالیسی کے اختیارات بیان کرتا ہے، اور یہ اس بات کا درست حوالہ ہے کہ حصے کو کیا اجازت دینی چاہیے۔ برج قاعدہ نرم کرنے سے پہلے اسے پڑھیں، کیوں کہ جو ماڈل یہ بیان کرتا ہے وہی اوپر کی ہر جانچ کا مفروضہ ہے۔
فیصلہ کریں کہ کیا ان ساتھیوں کو حصہ مشترکہ کرنا چاہیے
سب سے سستا حل عام طور پر دوسری سطح مشترکہ کرنا بند کرنا ہے جب ضرورت صرف IP رسائی ہو۔ روٹ شدہ VPN ہر کلائنٹ کو اس کا اپنا پتہ دیتا ہے، مشترکہ براڈکاسٹ ڈومین ہٹاتا ہے اور ساتھیوں کے درمیان ٹریفک کو طے شدہ کے بجائے پالیسی فیصلہ بناتا ہے۔ تب پورٹل کے پاس تحفظ کے لیے ایک پتہ ہوتا ہے اور کوئی پڑوسی نہیں جو اس پر دعویٰ کر سکے۔
اگر حصہ رہنا ہی ہے تو سرور کی طرف کی وہ ترتیب دیکھیں جو کلائنٹس کو ایک دوسرے تک پہنچنے دیتی ہے: grep -n client-to-client /etc/openvpn/server.conf۔ جب یہ غیر فعال ہو تو کلائنٹ ٹریفک سرور سے گزرتا ہے اور وہیں فلٹر کیا جا سکتا ہے۔ جب یہ فعال ہو تو ساتھی براہِ راست برج کے ذریعے فریموں کا تبادلہ کرتے ہیں، اور آپ کے فلٹرنگ مقامات برج اور ہوسٹ فائر وال ہیں۔
لکھیں کہ ہر ہوسٹ اصل میں کن تحفظات پر انحصار کرتا ہے: سرنگ کی تصدیق، حصے کی علیحدگی یا ایپلیکیشن TLS۔ تینوں پر انحصار کرنے والا ہوسٹ ٹھیک ہے۔ پہلے پر انحصار کرکے یہ سمجھنے والا کہ باقی دو اس کے ساتھ آ گئے، وہی ہے جو آخرکار غلط مواد پیش کرتا ہے۔