OpenVPN Access Server اصل میں کن پورٹس پر سنتا ہے؟
Access Server ہوسٹ پر ساکٹ فہرست دیکھیں: طے شدہ سننے والوں کو پہچانیں، loopback کو شائع شدہ پورٹس سے الگ کریں، اور پورٹ بند کرنے سے پہلے فارورڈنگ جانچیں۔
آپ ss -lntup Access Server ہوسٹ پر چلاتے ہیں اور توقع سے دوگنی لمبی فہرست حاصل کرتے ہیں۔ آدھی اندراجات ڈیمن کی شکل والے پورٹس ہیں جن کا سیٹ اپ کے دوران کسی نے ذکر نہیں کیا۔ ردِعمل یہ ہے کہ 443 یا 1194 کے علاوہ سب کچھ بند کر دیا جائے، اور اسی طرح لوگ اپنا ہی کلائنٹ پورٹل توڑ دیتے ہیں۔
Access Server ایک ہی سننے والا نہیں ہے۔ یہ VPN سروس، ویب سروس اور کلسٹر کا شریک ہے، اور آپ نے کتنے TCP ڈیمن کنفیگر کیے ہیں اس کے مطابق یہ اضافی ڈیمن مخصوص پورٹس اور فائر وال ری ڈائریکشن بنا سکتا ہے۔
فہرست کو ترتیب سے دیکھیں: ساکٹ پڑھیں، جانی پہچانی چیزوں کا نقشہ بنائیں، باقی کو مالک اور بائنڈ کے مطابق درجہ بند کریں، اور پھر جانچیں کہ اصل میں انہیں کیا شائع کرتا ہے۔
ایک صرف پڑھنے والے کمانڈ سے شروع کریں
sudo ss -lntup ہر سننے والے ساکٹ کے لیے ٹرانسپورٹ، مقامی پتہ، پورٹ اور مالک عمل دیتا ہے۔ جھنڈے اہم ہیں: -l سننا، -n عددی، -t TCP، -u UDP، -p عمل۔ root کے بغیر آپ کو ساکٹ ملتے ہیں مگر عمل کے نام نہیں، اور درجہ بندی کے لیے بالکل وہی کالم درکار ہے۔
کوئی بھی رائے قائم کرنے سے پہلے ہر قطار کے چار خانے لکھیں: پروٹوکول، بائنڈ پتہ، پورٹ اور کمانڈ۔ Access Server ورژن اور کنفیگر شدہ ڈیمن تعداد اس فہرست کے پاس رکھیں، کیونکہ دونوں توقع بدل دیتے ہیں۔
ایک جیسی نظر آنے والی دو قطاریں ایک جیسی نہیں ہوتیں۔ ایک ہی نمبر پر TCP اور UDP الگ افشا کے ساتھ الگ ساکٹ ہیں، اور 0.0.0.0 اور :: الگ پتہ خاندانوں کے لیے الگ بائنڈ ہیں۔ صرف 127.0.0.1 سے بندھی سروس دوسرے ہوسٹ سے براہ راست قابل رسائی نہیں، اگرچہ مقامی ری ڈائریکٹ اب بھی اسے شائع کر سکتا ہے۔
وہ سننے والے جنہیں آپ کو پہچاننا چاہیے
یہ طے شدہ اقدار زیادہ تر تعیناتیاں ڈھانپتی ہیں اور موازنے کے لیے بنیاد دیتی ہیں۔ یہ طے شدہ ہیں، مکمل اجازت فہرست نہیں۔
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
اس سے آگے ہر چیز کو وضاحت چاہیے، اندازہ نہیں۔ آپ اکثر صرف مقامی سننے والے دیکھیں گے جو ان اجزا کے ہیں جو پروڈکٹ اپنے لیے نصب کرتا ہے۔ انہیں یاد رکھے گئے پورٹ نمبر کے بجائے PID اور سروس کنفیگریشن سے تصدیق کریں، اور نامعلوم پورٹ کو محض نامعلوم ہونے کی وجہ سے دشمن نہ سمجھیں۔
جانی پہچانی جوڑی سے باہر کا ساکٹ بھی خود بخود باقیات نہیں ہوتا۔ جب کئی TCP ڈیمن کنفیگر ہوں، Access Server ہر ڈیمن کے لیے سننے والے بناتا ہے اور ٹریفک ان کی طرف ری ڈائریکٹ کرتا ہے، اس لیے ان کی تعداد اور پورٹ اقدار اسی کنفیگریشن کی پیروی کرتی ہیں۔
کچھ بند کرنے سے پہلے درجہ بندی کریں
ہر غیر یقینی قطار کے لیے اس ترتیب سے تین سوالوں کے جواب دیں۔
- مالک اور مقصد۔ PID کو کسی یونٹ یا عمل سے ملائیں اور اس سروس کی کنفیگریشن پڑھیں۔ اگر آپ مالک کا نام نہیں بتا سکتے تو آپ ساکٹ کے بارے میں کچھ بھی فیصلہ کرنے کے لیے تیار نہیں۔
- بائنڈ کا دائرہ۔ Loopback نام کی جگہ کے لیے مقامی ہے۔ وائلڈ کارڈ بائنڈ صرف اسی صورت میں قابل رسائی ہے جب روٹنگ، ہوسٹ فلٹرنگ اور بادل کی سطح کے کسی بھی اصول کی اجازت ہو، اس لیے بائنڈ پتہ ضروری ہے مگر کافی نہیں۔ IPv4 اور IPv6 کو الگ فیصلوں کے طور پر جانچیں۔
- شائع شدہ راستہ۔ سروس فارورڈنگ، ڈیمن مخصوص ری ڈائریکٹ، بیرونی پراکسی اور موثر فائر وال پالیسی تلاش کریں۔ یہی وہ قدم ہے جسے لوگ چھوڑ دیتے ہیں، اور یہی بے ضرر نظر آنے والے بیک اینڈ پورٹ کو قابل رسائی انتظامی راستہ بنا دیتا ہے۔
وہی سوال ہوسٹ کے باہر سے مختلف پڑھا جاتا ہے۔ ہوسٹ فائر وال اصول کے بغیر پورٹ کو بھی بادل کا سیکیورٹی گروپ بند کر سکتا ہے، اور اجازت دینے والے ہوسٹ اصول والا پورٹ ناقابل رسائی ہو سکتا ہے کیونکہ وہاں کچھ راستہ نہیں بنتا۔ فہرست کا نتیجہ لکھنے سے پہلے دونوں سرے دیکھیں۔
جہاں شائع شدہ راستہ ساکٹ فہرست سے مختلف ہے
Access Server کی اپنی دستاویزات وہ صورت ڈھانپتی ہیں جو سب سے زیادہ الجھن پیدا کرتی ہے: جب کئی TCP ڈیمن چل رہے ہوں، سامنے والا پورٹ ڈیمن مخصوص پورٹس کی طرف فارورڈ کرتا ہے، اور نظر آنے والی ترتیب ساکٹ فہرست سے میل کھانا بند کر دیتی ہے۔ ویب انٹرفیس فلٹرنگ کی ٹیوٹوریل ان اصولوں اور یہ کہ صرف واضح پورٹ کے لیے لکھا گیا فلٹر ری ڈائریکٹ شدہ راستہ مکمل طور پر کیسے چوک سکتا ہے، کی وضاحت کرتی ہے۔
کلسٹر کنٹرول دوسری جگہ ہے جہاں ورژن اہم ہے۔ 3.0 اور بعد میں یہ 943 شیئر کرتا ہے؛ پرانی کلسٹر کنفیگریشنز 945 استعمال کرتی تھیں۔ ورژن جانچے بغیر ان میں سے ایک کھولنا یا بلاک کرنا ایک صاف نظر آنے والی مگر غلط فہرست بناتا ہے۔
لہٰذا باہر سے نظر آنے والی سطح تین چیزوں کا اتحاد ہے: سننے والے ساکٹ، انہیں دوبارہ شائع کرنے والے فارورڈنگ اصول، اور ہوسٹ کے سامنے نیٹ ورک کنٹرول۔ کوئی بھی فہرست جو صرف پہلی چیز درج کرتی ہے نامکمل ہے، اور کوئی بھی تبدیلی جو صرف پہلی چیز کو مدنظر رکھتی ہے یا راستہ کھلا چھوڑ دے گی یا سروس کاٹ دے گی۔
کسی بھی تبدیلی کے بعد تصدیق کریں
معاون کنفیگریشن مالک کے ذریعے سننے والے کی ترتیبات بدلیں اور ایسا کرتے وقت ریکوری کنسول کھلی رکھیں۔ دور دراز ہوسٹ پر ویب انٹرفیس تک انتظامی رسائی کھونا اس VPN کے ذریعے بحال نہیں ہوتا جو آپ نے ابھی غیر فعال کیا۔
پھر وہ چار چیزیں تصدیق کریں جن کی تعیناتی کو عام طور پر ضرورت ہوتی ہے: VPN کلائنٹ جڑتا ہے، کلائنٹ پورٹل لوڈ ہوتا ہے، انتظامی رسائی کام کرتی ہے، اور اگر آپ ایک سے زیادہ نوڈ چلاتے ہیں تو کلسٹر مواصلات اب بھی کام کرتی ہیں۔ صرف-VPN ٹیسٹ پورٹل خراب ہونے پر بھی آرام سے پاس ہو جاتا ہے۔
ہر سروس کے لیے اجازت شدہ راستہ لکھ کر ختم کریں: کون سا ساکٹ، کون سا بائنڈ، کون سا فارورڈنگ اصول، کون سا نیٹ ورک کنٹرول۔ وہی دستاویز مفید سیکیورٹی آؤٹ پٹ ہے۔ کم از کم ساکٹ تعداد نہیں، اور نہ ہی وہ اجتماعی ری سیٹ جو ایسے سننے والوں کو بند کرتا ہے جن کی شناخت کسی نے مکمل نہیں کی۔