OpenVPN بمطابق stunnel: لفافے کو آگے بھیجیں، پورٹ 1194 کو نہیں
دو سننے والے، تین پورٹس۔ دیکھیں کہ فارورڈنگ کہاں اترتی ہے، لفافہ کہاں بندھتا ہے، کہاں جڑتا ہے، مقامی جانچ نے کیا چھوڑا اور دونوں شناختیں۔
TLS لفافہ OpenVPN کے آگے رکھیں اور تعیناتی کو دوسرا سننے والا مل جاتا ہے، جن میں سے صرف ایک کو کبھی انٹرنیٹ کی طرف ہونا چاہیے۔ جب سرنگ اسی مشین سے کام کرے اور باہر سے ناکام ہو، تو فارورڈنگ عموماً دونوں میں سے غلط کی طرف ہوتی ہے۔ جو چیز میل کھانی چاہیے وہ ایک زنجیر ہے: عوامی قاعدہ لفافے تک پہنچتا ہے، اور لفافے کا اپنا بیک اینڈ کنکشن اصل VPN ساکٹ تک پہنچتا ہے۔ چار چھلانگیں یہ زنجیر اٹھاتی ہیں، اور ان میں سے کوئی بھی تفتیش کو جلدی ختم کر سکتی ہے۔
دو ساکٹ، دو مالک، ایک عوامی
لفافہ بیرونی کنکشن کے لیے TLS ختم کرتا ہے اور ڈکرپٹ شدہ بائٹ اسٹریم ایک عام OpenVPN TCP سننے والے کو دیتا ہے۔ یہ الگ کنفیگریشن فائلوں والے الگ ساکٹ ہیں، اس لیے ایک میں ترمیم دوسرے کو اچھوتا اور پھر بھی بظاہر صحت مند رکھتی ہے۔ اس کا مطلب یہ بھی ہے کہ دونوں ایک دوسرے سے دور ہو سکتے ہیں جب ایک کو دوسرے کے بغیر بدلا جائے۔
خود مشین سے کام کرنا عوامی راستے کے بارے میں بہت کم ثابت کرتا ہے۔ اصل پورٹ پر سیدھا کنکشن لفافے کو چھوڑ دیتا ہے، لفافے کے LAN پتے پر کنکشن ترجمے کو چھوڑ دیتا ہے، اور باہر والے صارف کا کام صرف مکمل کلائنٹ طرفہ ترتیب ہی کرتی ہے۔ نام بھی غور سے پڑھنے چاہئیں، کیونکہ localhost اس میزبان کو ظاہر کرتا ہے جو وہ مخصوص جزو چلاتا ہے، نہ کہ اس میزبان کو جس پر آپ اتفاقاً ٹائپ کر رہے ہیں۔ یہ فرق اپنے نوٹس میں رکھیں، کیونکہ وہ جانچ جو اپنی چھلانگ درج کیے بغیر ریکارڈ ہو، دو مختلف چیزوں کے موازنے کی دعوت دیتی ہے۔
فارورڈنگ اصل میں کہاں اترتی ہے
زنجیر کو تین پورٹ نمبروں کی بجائے چار چھلانگوں کے طور پر تھامنا آسان ہے، کیونکہ ایک ہی نمبر ہر سرے پر مختلف معنی دے سکتا ہے۔ جدول کو سطر بہ سطر پڑھیں: ہر سطر ایک ساکٹ ہے جسے کنکشن قبول کرنا اور پھر اگلا کھولنا ہوتا ہے۔ جب کوئی سطر غلط ساتھی کی طرف ہو، تو آخری کالم کا علامتی اثر وہی ہوتا ہے جو صارف بتاتا ہے۔
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
لفافے کی بجائے اصل VPN پورٹ کو نشانہ بنانے والا قاعدہ TLS کا اختتام مکمل طور پر چھوڑ دیتا ہے، اور یہی اس غلطی کی سب سے عام شکل ہے: کلائنٹ ایسے سننے والے کے ساتھ مصافحہ کھولتا ہے جو OpenVPN فریمنگ کی توقع رکھتا ہے، اس لیے کنکشن کھل کر پھر رک سکتا ہے۔ ترجمہ شدہ پورٹ کو یادداشت کی بجائے لفافے کی کنفیگریشن فائل سے تصدیق کریں، کیونکہ وہ فائل اگلی بار ترمیم کرنے والے نے شاید کوئی اور نمبر چنا ہو۔ نیچے کے دو حکم ایک ساتھ اس سوال کے دونوں پہلو دکھاتے ہیں۔
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'وہ بائنڈ پتہ جو آپ کو مسترد کرتا ہے
127.0.0.1 سے بندھی accept سطر صرف خود میزبان کو جواب دیتی ہے، اس لیے LAN پتے پر آنے والی فارورڈنگ جڑ نہیں سکتی اور کلائنٹ کو ایسا انکار نظر آتا ہے جو پیکٹ فلٹر کے مسئلے جیسا لگتا ہے۔ فائر وال کو چھونے سے پہلے ساکٹ دیکھیں، کیونکہ ساکٹ سستا جواب ہے۔ یا تو لفافے کو اس انٹرفیس سے باندھیں جسے فارورڈنگ نشانہ بناتی ہے، یا اسے loopback پر رکھیں اور فارورڈنگ کو کسی واقعی کام کرنے والی چیز کے ذریعے loopback تک پہنچائیں۔ یہ دو ڈیزائن ہیں، اور ہر ایک کو اپنا قاعدہ چاہیے۔
دونوں کو ملانا ہی وہ طریقہ ہے جس سے کام کرنے والا لفافہ باہر سے ناقابل رسائی ہو جاتا ہے جبکہ ہر فائل درست دکھتی ہے۔ نیچے کی جانچ ایک حکم ہے، اور یہ ایسے سوال کا جواب دیتی ہے جس کا جواب فائر وال قواعد کا جائزہ نہیں دے سکتا۔ اگر آؤٹ پٹ loopback پتہ دکھائے جبکہ فارورڈنگ LAN پتہ نشانہ بناتی ہے، تو درستی accept سطر میں ہے، پیکٹ فلٹر میں نہیں۔
ss -lntp '( sport = :8443 )'مقامی جانچ نے واقعی کیا ثابت کیا
وہ کامیابی جو اپنی چھلانگ درج کیے بغیر ریکارڈ ہو، دیگر چھلانگوں کے بارے میں ثبوت نہیں ہے۔ لکھیں کہ جانچ نے کون سا پتہ استعمال کیا اور کس عمل نے جواب دیا۔ پھر اسی Wi-Fi کے فون سے نہیں بلکہ نیٹ ورک سے باہر دہرائیں، کیونکہ ہیئر پن رویہ راؤٹرز کے درمیان مختلف ہوتا ہے اور ایسا کنکشن بھی جو کبھی LAN سے باہر نہ نکلا، فارورڈنگ کے بالکل شامل نہ ہونے کے باوجود کلائنٹ کو مطمئن کر سکتا ہے۔ صرف وہی دوسری کوشش باہر والے شخص کے طے کردہ راستے کی مشق کرتی ہے۔
جب کوشش ناکام ہو، ایک کنکشن کو دونوں لاگز میں ٹریک کریں: لفافے کی قبول شدہ اور جڑی ہوئی سطریں، پھر VPN ڈیمون کا اپنا سیشن لاگ۔ جو پہلی حد کچھ بھی درج نہ کرے، اگلی تبدیلی کی جگہ وہی ہے۔ جب OpenVPN ساتھی کے اختیارات کا موازنہ شروع کرے، تو ان پیغامات کو اسی عمل درآمد کے قواعد سے پرکھیں۔ link-mtu کے تضاد کی وارننگ خود بخود مہلک نہیں، link-mtu کو 1500 پر پن کرنا یہ ثابت نہیں کرتا کہ تقسیم رک گئی، اور سائفر کی بات چیت راؤٹر کی فارورڈنگ کی نہیں بلکہ OpenVPN کی اندرونی ترتیب کی چیز ہے۔
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerوہ جانچیں بیک اینڈ ساکٹ اور لفافے کے لاگ کا احاطہ کرتی ہیں، جو مسترد شدہ بیک اینڈ کو مسترد شدہ مصافحے سے الگ کرتی ہیں۔ انہیں اسی وقت چلائیں جب ایک کوشش جاری ہو، بعد میں نہیں۔ ایک ہی کوشش کے ٹائم اسٹیمپ ہی موازنے کو قابل اعتماد بناتے ہیں۔
دو شناختیں، دو ناکامی کے سلسلے
بیرونی سند لفافے کی ہے اور اندرونی شناخت OpenVPN کی ہے، اور وہ مختلف اداروں سے آ سکتی ہیں۔ کسی بھی جانچ کو بند کرنا تاکہ راستہ صحت مند دکھے، حقیقی تحفظ کو ظاہری نتیجے سے بدل دیتا ہے۔ دونوں تصدیقیں رکھیں اور ترتیب سے انہیں ڈی بگ کریں، کیونکہ پیغامات کی ترتیب پرت کا نام بتاتی ہے: لفافے کی سند کا مسئلہ کسی بھی VPN اختیار کی بات چیت سے پہلے ظاہر ہوتا ہے، جبکہ اندرونی شناخت کی ناکامی صرف اس وقت ظاہر ہوتی ہے جب بہاؤ قائم ہو چکا ہو۔
stunnel دستی accept، connect اور کلائنٹ موڈ کی درست تعریف کرتا ہے، اور وہ حصے ساکٹ کے سوال کا جواب اندازے سے زیادہ تیزی سے دیتے ہیں۔ جب آپ اب بھی نہ بتا سکیں کہ کس پرت نے جواب دیا، تو نیچے کے حکم سے وہ سند پڑھیں جو عوامی پورٹ پیش کرتا ہے۔ آؤٹ پٹ میں لفافے کی سند ہونے کا مطلب ہے کہ فارورڈنگ لفافے تک پہنچی، اور خاموشی یا پروٹوکول کی خرابی کا مطلب ہے کہ نہیں پہنچی۔ وہی ایک فرق یہاں کسی بھی دوسری جانچ سے زیادہ وقت بچاتا ہے۔
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer