کیوں nc -uz یہ ثابت نہیں کر سکتا کہ OpenVPN سرور تیار ہے

چلانا nc -uz ایک OpenVPN سرور کے خلاف تقریباً کچھ نہیں ناپتا، اور OpenBSD کی کتاب اپنی تنبیہات میں یہی کہتی ہے: اس موڈ میں UDP اسکین کامیابی کی اطلاع دیتے ہیں، چاہے کوئی چیز سن رہی ہو یا نہ ہو۔ ایگزٹ حیثیت دور کی حالت نہیں بلکہ مقامی بھیجنے کی عکاسی کرتی ہے، اس لیے اس پر بھروسا کرنے والا نگران عمل کی میز کے قابلِ اعتماد دکھنے تک مردہ سرور کو صحت مند کے طور پر نشان زد رکھتا ہے۔ اسے بدلنے کا آغاز یہ طے کرنے سے ہوتا ہے کہ جانچ کو کس سوال کا جواب دینا چاہیے، کیونکہ عمل، سامع، توثیق اور اطلاق کی رسائی چار مختلف مشاہدے ہیں۔ جو جانچ ان میں سے ایک کا نام لے وہ مفید ہے؛ جو جانچ چاروں کی طرف اشارہ کرے وہ بوجھ ہے۔

UDP جانچ کیا دیکھ سکتی ہے اور کیا نہیں

nc -uz ایک ڈیٹا گرام بھیج کر باہر نکل جاتا ہے، اور جو حیثیت لوٹاتا ہے وہ مقامی بھیجنے کی وضاحت کرتی ہے۔ بند پورٹ ICMP port unreachable کے ساتھ جواب دے سکتا ہے، لیکن اس اسکین موڈ کا درج شدہ رویہ اسے ناکامی میں نہیں بدلتا، اور فلٹر شدہ پورٹ کوئی جواب نہیں دیتا۔ اس لیے خاموشی اور کامیابی کال کرنے والے کے لیے ایک ہی معنی رکھتے ہیں۔

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

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

تین کال کرنے والے، تین مختلف سوالات

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

یہ ایک ہی جانچ نہیں ہیں، اور ایک جانچ ایمانداری سے تینوں کو ڈھانپ نہیں سکتی۔ پہلے کال کرنے والا چنیں، پھر ثبوت۔

جانچ کو موجودہ مثال سے بنائیں

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

اسے جان بوجھ کر توڑیں اور جانچ دیکھیں

جانچ تب ہی قابلِ بھروسا ہوتی ہے جب آپ نے اسے ناکام ہوتے دیکھا ہو۔ سرور روکیں، جانچ چلائیں اور متوقع نتیجے کی تصدیق کریں۔ پھر اسے دوبارہ شروع کریں اور تصدیق کریں کہ جانچ بغیر کسی دوسری تبدیلی کے بحال ہو جاتی ہے۔

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

بلاک کو سطر بہ سطر پڑھیں۔ netcat کمانڈ exit=0 چھاپتی ہے جبکہ کچھ بھی بندھا ہوا نہیں، اور ایک ہی سطر میں پوری مشکل یہی ہے۔ پہلا ss کچھ نہیں چھاپتا، دوبارہ آغاز کامیاب ہوتا ہے، اور دوسرا ss پھر سامع دکھاتا ہے۔ اگر آپ کی جانچ روکے ہوئے سرور کے خلاف پاس ہوتی ہے، تو وہ مقامی اسٹیک ناپ رہی ہے اور کچھ نہیں۔

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

حالت کی سطر کو کیا کہنا چاہیے

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

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

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