پورٹ 1194 پہلے ہی استعمال میں ہے: یہ OpenVPN ساکٹ کس کا ہے؟

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

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

درست بائنڈنگ خرابی پڑھیں

اس خاندان کی دو خرابیوں کے معنی مختلف ہیں، اور انہیں ملانا آپ کو غلط پرت پر بھیجتا ہے۔ «پتہ پہلے ہی استعمال میں ہے» کا مطلب ہے کہ کوئی دوسرا ساکٹ آپ کا مانگا ہوا آخری نقطہ رکھے ہوئے ہے۔ «پتہ دستیاب نہیں» کا مطلب ہے کہ آپ کا مانگا ہوا پتہ اس میزبان پر ابھی موجود نہیں، جو تیاری کا مسئلہ ہے، نقل نہیں۔

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

ساکٹ کی فہرست بنائیں، پورٹ کی نہیں

پورٹ نمبر ادھوری فہرست ہے۔ آخری نقطہ ایک ٹرانسپورٹ، ایک پتہ خاندان، ایک مقامی پتہ اور ایک پورٹ ہے، سب ایک ہی نیٹ ورک نام کی جگہ کے اندر۔ ایک ہی نمبر پر UDP سامع اور TCP سامع مختلف ساکٹ ہیں، اور مختلف نام کی جگہوں میں ایک ہی نمبر پر دو عمل کبھی نہیں ملتے۔

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

معلوم کریں کہ کون سا عمل اس کا مالک ہے

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

ایک مالک، یا دو ڈیزائن شدہ مثالیں

اگر تعیناتی ایک سرور کا ارادہ رکھتی ہے تو ایک زندگی چکر کا مالک رکھیں اور اسے دیکھنے کے لیے دوسری نقل شروع کرنے کی بجائے اس مثال کا جرنل یا ترتیب شدہ لاگ پڑھیں۔ جب کنٹرول شدہ پیش منظر عمل واقعی ضروری ہو تو زیرِ انتظام مثال کو جان بوجھ کر روکیں اور ایسا کرنے سے پہلے ان گاہکوں کا حساب رکھیں جن کی یہ خدمت کر رہی ہے۔

اگر دو مثالیں ارادی ہوں تو انہیں الگ سامع اور باقی سب الگ دیں: پتہ پول، مجازی انٹرفیس، روٹنگ پالیسی اور ترتیب کی ملکیت۔ صرف الگ پورٹ ساکٹ کے سوا کچھ الگ نہیں کرتا، اور دونوں سرور ایک ہی پول اور ایک ہی راستوں کے لیے لڑتے رہیں گے۔

تین شارٹ کٹ قابلِ ذکر ہیں کیونکہ یہ اس خرابی کے بارے میں ہر بحث میں دکھتے ہیں۔ مجرم جیسا لگنے والا کوئی بھی PID نہ ماریں۔ پیغام خاموش کرنے کے لیے ساکٹ اشتراک فعال نہ کریں۔ سرور پروفائل کو گاہک طرز کی غیر مربوط ترتیب میں نہ بدلیں کیونکہ اس سے بائنڈنگ خرابی غائب ہو جاتی ہے؛ سرور اصل تنازع سے زیادہ مشکل تشخیص والے انداز میں ناقابلِ رسائی ہو جاتا ہے۔

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

باقی سب سے پہلے بائنڈنگ کی توثیق کریں

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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