OpenVPN push-peer-info: رسائی دیے بغیر کلائنٹس کو لیبل کریں

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

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

متغیر سیٹ کریں اور راستہ فعال کریں

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

سرور ہک سے فیلڈ پڑھیں

سرور کی جانب، موصولہ ہم مرتبہ معلومات کی تصدیق کی جاتی ہے اور اسے کنکشن ورک فلو کے ماحول میں ڈالا جاتا ہے، اور یہی اسے آپ کی جانب سے کسی پروٹوکول کام کے بغیر ہک سے پڑھنے کے قابل بناتا ہے۔ سرور کو کنٹرول چینل تجزیہ کرنے یا آپ کے لیے کچھ محفوظ کرنے کی ضرورت نہیں؛ کنکشن قائم ہوتے وقت قدر صرف موجود ہوتی ہے۔ تصدیق شدہ نام کے پاس لیبل درج کرنے والی کم از کم client-connect اسکرپٹ ایسی دکھتی ہے۔

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

لاگ تجزیہ کرنے کے بجائے ماحول کے ذریعے متغیر پڑھیں، اور اسے ہمیشہ طے شدہ قدر دیں۔ ${UV_DEPLOY:-unset} ایسے کلائنٹس کے لیے اسکرپٹ چلتی رکھتی ہے جو فیلڈ کبھی نہیں بھیجتے، جو مرحلہ وار تعیناتی کے دوران معمول کی حالت ہے۔ نام تلاش کرنے کے لیے پورا ماحول لاگ میں نہ بہائیں؛ اس میں لیبل سے کہیں زیادہ کچھ ہے، جن میں وہ قدریں بھی شامل ہیں جو آپ محفوظ کرنے کا ارادہ نہیں رکھتے تھے۔

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

جانچیں کہ اصل میں کیا آیا

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

کنکشن کے لیے سرور لاگ بھی جانچیں۔ ہم مرتبہ معلومات وہاں ظاہر ہو سکتی ہیں، جو ڈیبگنگ کے لیے آسان ہے اور قدروں کو بورنگ رکھنے کی وجہ ہے: لوگوں کے نام نہیں، ٹکٹ نمبر نہیں، ایسی کوئی چیز نہیں جو لاگ پڑھنے والا دیکھے تو آپ کو برا لگے۔

لیبل کو دعویٰ سمجھیں، شناخت نہیں

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

اسے صاف طریقے سے واپس کریں

خصوصیت ہٹانا دو حذف کرنا اور ایک تصدیق ہے۔ کلائنٹ پروفائل سے setenv اور push-peer-info لکیریں ہٹائیں، پھر سرور پر ہک اور اس کا لاگ ہدف ہٹائیں یا غیر فعال کریں۔

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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