دو DNS نام، ایک OpenVPN پورٹ: اصل میں کیا منتخب کرتا ہے

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

حل کرنے والا جو واپس دیتا ہے اسی سے شروع کریں

کلائنٹ vpn-a.example مانگتا ہے اور ایک پتہ پاتا ہے؛ وہ پتہ اور ایک پورٹ ہی اس کا پورا ڈائل ہے۔ نام تلاش کے دوران مقامی طور پر خرچ ہو جاتا ہے اور کبھی تار پر خانہ نہیں بنتا، اس لیے دوسرے سرے کا سننے والا یہ نہیں دیکھ سکتا کہ کون سا لیبل استعمال ہوا۔ vpn-a.example اور vpn-b.example کو ایک ہی میزبان کی طرف اشارہ کریں، دونوں تلاشیں ایک ہی منزل دیں گی، اسی لیے ڈیمن بغیر کوئی فرق درج کیے دونوں رابطوں کو ایک ہی مثال میں جذب کر لیتا ہے۔ پتے پر مبنی پروفائل بھی اسی وجہ سے نام پر مبنی پروفائل کی طرح برتاؤ کرتے ہیں۔

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

گنتی میں آنے والا واحد منتخب کنندہ پیکٹ کے اندر جاتا ہے

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

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

پروٹوکول تقسیم کرنے والا کہاں رکتا ہے

sslh منصوبہ جس قسم کا ملٹی پلیکسر دستاویز کرتا ہے وہ ایک پورٹ پر سنتا ہے، ابتدائی بائٹس کا معائنہ کرتا ہے، اور رابطہ اس بیک اینڈ کو سونپ دیتا ہے جو پہچانا گیا پروٹوکول بولتا ہے۔ جب ایک پورٹ کو SSH، HTTPS اور OpenVPN کی ایک ساتھ خدمت کرنی ہو تو یہ حقیقی قدر ہے۔

sslh ہر پروٹوکول کے لیے الگ جانچ رکھتا ہے، اور اس کی TLS جانچ کسی اصلی ClientHello سے سرور نام یا ALPN قدر نکال سکتی ہے۔ اصل OpenVPN کو پہچاننا TLS توسیع پڑھنے سے مختلف درجہ بندی ہے، اور دونوں مل کر نہیں چلتے، کیونکہ جو کلائنٹ سننے والے ساکٹ پر کبھی ClientHello نہیں بھیجتا وہ جانچ کو پڑھنے کے لیے کچھ بھی نہیں چھوڑتا۔ اسی لیے OpenVPN سے مطابقت رکھنے والا قاعدہ “یہ OpenVPN کلائنٹ ہے” کا جواب دیتا ہے اور آگے نہیں جاتا۔ اس قاعدے کے پیچھے دو OpenVPN بیک اینڈ الگ نہیں پہچانے جا سکتے، سامنے والے حصے کے پاس انتخاب کی کوئی بنیاد نہیں، اور ہر سیشن ایک ہی جگہ اترتا ہے۔ ملٹی پلیکسنگ ایک پورٹ کو مختلف سروسز کے درمیان بانٹتی ہے؛ یہ ایک سروس کے اندر ورچوئل ہوسٹنگ نہیں کرتی۔

وہ ترتیبیں جو واقعی دو سرور الگ کرتی ہیں

سب سے سستی دیانتدار تقسیم دوسرا عوامی پتہ ہے، ہر مثال کے لیے ایک، اور موجودہ پروفائل پہلے ہی وہ رکھتے ہیں جو درکار ہے کیونکہ وہ الگ الگ پتوں کی طرف اشارہ کرتے ہیں۔ اگلا اسی پتے پر مختلف پورٹ ہے، جو ہر پروفائل میں ایک عدد کے سوا کچھ خرچ نہیں کرتا۔ TCP اور UDP الگ پورٹ جدولیں رکھتے ہیں، اس لیے 1194/tcp اور 1194/udp غیر متعلق ساکٹ ہیں اور ہر ایک میں سے ایک ایک ہی میزبان پر ساتھ رہ سکتا ہے؛ یہ نام کی روٹنگ نہیں بلکہ نقل و حمل کی تقسیم ہے، اور اکثر اس سے خلط کیا جاتا ہے۔ دونوں گزینه فائر وال جائزے سے گزرتی ہیں، کیونکہ قاعدہ اس چیز سے مطابقت رکھتا ہے جو واقعی پیکٹ میں ہے۔

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

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

بنانے سے پہلے منتخب کنندہ ثابت کریں

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

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

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

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