OpenConnect لاگ اِن کوکی کو ٹنل میں کیسے بدلتا ہے؟

OpenConnect دو الگ تبادلوں کو ایک مختصر العمر قدر سے جوڑتا ہے: ویب لاگ اِن اور VPN ٹنل۔ پہلا تبادلہ عام HTTPS ہے: اسناد، ایک SAML سفر یا ٹوکن گیٹ وے کی طرف جاتے ہیں، اور جواب تصدیقی کوکی لاتا ہے۔ دوسرا تبادلہ وہی کوکی اسی گیٹ وے کے سامنے اس ثبوت کے طور پر پیش کرتا ہے کہ ویب مرحلہ پہلے ہو چکا ہے، اور تب ہی ٹنل اوپر آتا ہے۔

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

کلائنٹ اور گیٹ وے باری باری کیا تبادلہ کرتے ہیں

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

دوسرا مرحلہ اسی کوکی کے ساتھ گیٹ وے کے VPN اختتامی نقطے کو بھیجی گئی CONNECT درخواست ہے۔ گیٹ وے اسے جانچتا ہے، پتہ تفویض کرتا ہے، اور کلائنٹ TLS پر CSTP شروع کرتا ہے، سیشن موجود ہونے پر DTLS ایک اختیاری تیز رفتار ڈیٹا راستہ بنتا ہے۔ صرف اسی موقع پر ٹنل کے پیرامیٹر، راستے، DNS ترتیبات اور سیشن کی ٹریفک کلیدیں قائم ہوتی ہیں۔ کوکی نے کلائنٹ کو دروازے سے گزارا؛ اس نے کچھ بھی خفیہ نہیں کیا۔

یہی ترتیب بتاتی ہے کہ openconnect --authenticate کیوں موجود ہے۔ اسے چلائیں، یہ ویب مرحلہ کرتا ہے، COOKIE، HOST، CONNECT_URL اور FINGERPRINT جیسے شیل متغیرات کا چھوٹا بلاک چھاپتا ہے، اور پھر کوئی ٹنل بننے سے پہلے باہر نکل جاتا ہے۔ بعد میں ایک ریپر اسکرپٹ ان قدروں کے ساتھ اصل کنکشن شروع کر سکتی ہے، اور ہیڈ لیس یا دو کنٹینر تعیناتی کو یہی تقسیم درکار ہے۔

کوکی سیشن کی حامل ہے، کلید نہیں

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

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

کوکی کو دیگر اسناد کا عالمگیر متبادل نہ سمجھیں۔ SAML دعوی، براؤزر کا پاس ورڈ اور کسی دوسری سروس کی جاری کردہ کوکی مختلف سامعین والی مختلف چیزیں ہیں، اور ایک کو دوسرے کے خانے میں چپکانا عام طور پر گیٹ وے پر ناکام ہوتا ہے یا زیادہ برا یہ کہ غلط اعتماد کی حد کے خلاف کامیاب ہو جاتا ہے۔

نقل چھوڑے بغیر کوکی حوالے کرنا

Linux پر سب سے محفوظ میکانی حوالگی معیاری اِن پٹ ہے۔ --cookie-on-stdin قدر stdin سے پڑھتا ہے، اس لیے کوکی کبھی عمل کے دلائل کی فہرست میں ظاہر نہیں ہوتی، جہاں کوئی بھی مقامی صارف اسے ps سے پڑھ سکتا ہے۔ ایک عمل میں تصدیق کر کے دوسرے میں ٹنل کو خوراک دینے والی پائپ لائن قدر کو فائل یا ماحولیاتی متغیر کی بجائے پائپ میں رکھتی ہے۔

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

استحقاق کی حد بھی جان بوجھ کر رکھیں۔ شناخت فراہم کنندہ سے بات کرنے والا اور ممکنہ طور پر براؤزر کھولنے والا عمل اسی صارف کے طور پر چلنا چاہیے جس کا یہ لاگ اِن ہے۔ راستے، DNS اور ٹنل آلہ ترتیب دینے والے عمل کو زیادہ استحقاق درکار ہو سکتا ہے۔ root کی ملکیت والے ٹنل کے لیے کوکی دستیاب کرانے کے لیے پورا براؤزر root کے طور پر چلانا غلط سودا ہے، اور جدید OpenConnect ترتیبات اس قدر کو اس حد سے صریحاً منتقل کر سکتی ہیں۔

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

دوسرے مرحلے میں تصدیق اور میعاد ختم ہونا

دوسرے مرحلے کو اب بھی سرور کی تصدیق کرنی ہے۔ --authenticate جو FINGERPRINT چھاپتا ہے وہ pin-sha256: شکل میں سرٹیفکیٹ پن ہے، اور اسے --servercert کے ساتھ ٹنل کال کو دینا جانچ کو اسی گیٹ وے پر لنگر انداز رکھتا ہے جس کے سامنے آپ نے تصدیق کی۔ اسکرپٹ آسان بنانے کے لیے سرٹیفکیٹ جانچ بند کرنا اس بات کا واحد ثبوت ہٹا دیتا ہے کہ کوکی مطلوبہ ہوسٹ کو دی جا رہی ہے۔

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

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