ConnMan OpenConnect کوکی کی میعاد ختم، سرٹیفکیٹ کا مسئلہ نہیں
لاگ میں دو خرابیاں ایک جیسی دکھتی ہیں۔ پن شدہ فنگر پرنٹ کا سیشن کوکی سے موازنہ کریں، میعاد ختم شدہ فیلڈ تازہ کریں، پھر ڈیمون دوبارہ شروع کریں۔
ConnMan ایک دوپہر کام کرتا ہے اور پھر انکار کر دیتا ہے، اور جرنل کی سطر سرٹیفکیٹ کی تصدیق کا ذکر کرتی ہے۔ وہ سطر لوگوں کو ایسے CA بنڈلوں کی طرف بھیجتی ہے جو کبھی خراب نہیں ہوئے۔ دو مختلف خرابیاں تقریباً ایک ہی شکل کی ناکامی پیدا کرتی ہیں: سیشن کوکی کی میعاد ختم ہو جاتی ہے، یا سرور کا سرٹیفکیٹ واقعی بدل گیا ہے۔ انہیں تقریباً ایک منٹ میں الگ کیا جا سکتا ہے، اور ان میں سے صرف ایک کا فنگر پرنٹ سے تعلق ہے۔
دو خرابیاں، ایک الجھی ہوئی لاگ سطر
یہ دو مشاہدات پر الگ ہوتی ہیں، اور کسی کو دوبارہ پڑھنے کی ضرورت نہیں۔ پہلا یہ کہ ناکامی کب شروع ہوئی: میعاد ختم شدہ کوکی گھنٹوں یا دنوں کے کام کے بعد آتی ہے، اور بدلا ہوا سرٹیفکیٹ گیٹ وے کی تبدیلی کے فوراً بعد آتا ہے۔
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-pin deliberately, then restart |
ایک منٹ کا امتحان نیچے دیا گیا authenticate رن ہے۔ اس کے FINGERPRINT کا فائل میں موجود OpenConnect.ServerCert سے موازنہ کریں۔ یکساں فنگر پرنٹ اور مختلف COOKIE کا مطلب صرف کوکی بدلنا ہے۔ مختلف فنگر پرنٹ کا مطلب سرور کا سرٹیفکیٹ واقعی بدل گیا ہے، اس لیے اسے دانستہ طور پر دوبارہ پن کریں اور درج کریں کہ کس نے منظوری دی۔
ٹائپ کرنے کے بجائے مواد پیدا کریں
NetworkManager کے برعکس، ConnMan میں OpenConnect پروفائل کے لیے درآمد کا کوئی مرحلہ نہیں۔ یہ پروویژننگ فائل پڑھتا ہے جس کی اقدار پہلے سے بنانی پڑتی ہیں، اور انہیں بنانے کا معاون طریقہ OpenConnect کا authenticate موڈ ہے۔
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comآؤٹ پٹ چار اقدار چھاپتا ہے: POST، COOKIE، HOST اور FINGERPRINT۔ sha256: سابقے والا فنگر پرنٹ سرور پن ہے۔ کوکی سیشن کا نمونہ ہے جس کی عمر گیٹ وے طے کرتا ہے۔ انہیں مختلف قسم کے راز سمجھیں: ان کی میعاد مختلف شیڈول پر ختم ہوتی ہے، اور صرف ایک کے بدلنے کی توقع ہے۔
فائل دونوں رکھتی ہے، اور وہ مختلف طریقے سے پرانے ہوتے ہیں
پروویژننگ فائل /var/lib/connman-vpn/ کے تحت رہتی ہے اور ہر کنکشن کے لیے اسے VPN ڈیمون پڑھتا ہے، ٹرے ایپلیٹ نہیں۔ کنکشن کا نام عالمی حصے میں اور پروٹوکول کی تفصیلات فراہم کنندہ کے حصے میں رکھیں۔
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...وہی ہوسٹ نام استعمال کریں جو پورٹل واقعی پیش کرتا ہے۔ ننگا IP پتہ سرٹیفکیٹ کی جانچ پاس کر سکتا ہے اور پھر بھی ناکام ہو سکتا ہے، کیونکہ آلہ مجازی ہوسٹ پر روٹ کرتا ہے اور نام کی توقع رکھتا ہے۔
systemctl status connman-vpn --no-pager # is the daemon even installed and running
sudo systemctl restart connman-vpn # after the file edit
journalctl -u connman-vpn --since '1 hour ago' # after the connection attemptجرنل واقعی کیا دکھاتا ہے
ٹرے ٹول ٹپ نہیں بتائے گی کہ آپ کو کون سی خرابی ہے۔ جرنل بتائے گا، اگر آپ پہلی خوفزدہ کرنے والی سطر کے بجائے ترتیب پڑھیں۔ پرانی کوکی عام طور پر ظاہر کرتی ہے کہ TLS گفت و شنید مکمل ہوئی اور اس کے بعد HTTP پرت نے انکار کیا؛ اسی لیے سرٹیفکیٹ کے بارے میں الفاظ کسی اجازت کی ناکامی کے ساتھ کھڑے ہوتے ہیں۔
نئی authenticate رن کا فائل کی اقدار سے موازنہ کریں۔ اگر فنگر پرنٹ مطابق ہو اور صرف کوکی مختلف ہو، تو اعتماد کی ترتیبات کو چھوئے بغیر آپ کا جواب آپ کے پاس ہے۔
میعاد ختم شدہ فیلڈ تازہ کریں
authenticate کمانڈ دہرائیں، OpenConnect.Cookie بدلیں، اور ڈیمون دوبارہ شروع کریں۔ فنگر پرنٹ کو چھوڑ دیں جب تک نئی آؤٹ پٹ مختلف قدر نہ دکھائے؛ اس صورت میں سرور کا سرٹیفکیٹ واقعی بدل دیا گیا ہے اور دوبارہ پن کرنا ایسا فیصلہ ہے جسے کسی کو درج کرنا چاہیے، غلطی کے پیغام سے چپکانا نہیں۔
تازہ کرنے کو خودکار بنانا معقول ہے: ایک چھوٹی اسکرپٹ معیاری ان پٹ سے پاس ورڈ پڑھتی ہے، authenticate موڈ چلاتی ہے اور صرف کوکی کی سطر دوبارہ لکھتی ہے۔ اسناد کو اسکرپٹ سے باہر رکھیں اور صرف اسی اکاؤنٹ کے لیے پڑھنے کے قابل بنائیں جو اسے چلاتا ہے، اور دوبارہ لکھنے کو جوہری بنائیں تاکہ ناکام رن آدھی لکھی فائل نہ چھوڑے۔
اگر تازہ کرنے کی ضرورت ہر چند گھنٹوں میں ہو، وقفہ لکھ لیں۔ یہ گیٹ وے کی سیشن پالیسی کی خصوصیت ہے، اور یہ طے کرتی ہے کہ تازہ کرنے کو خودکار بنایا جائے یا طویل سیشن مانگا جائے۔