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 راځي، د سند د ګوتو نښه پین ده، او د تونل په تړل کېدو غونډه پرېښودل کېږي۔ که له دې یو هم نه وي، اتومات کول د لاسي بهیر د تکرارولو پر ځای په کوکي باور پراخ کړی دی۔