OpenConnect باید څومره وخت د پرې شوې VPN سره بیا هڅه وکړي؟

--reconnect-timeout یوې تنګې پوښتنې ته ځواب وایي: د تونل له لوېدو وروسته دا کېلنټ پروسه څومره وخت هڅه کوي تر څو چې تسلیم شي او ووځي۔ د OpenConnect لارښود پاڼه دا انتخاب د ورکې شوې اړیکې یا د ځواب ورکولو له بنده شوي شريک وروسته بیا هڅو لپاره د 300 ثانیو مستند ډیفالټ سره ثبتوي، او دا شمېره د یوې روانې کېلنټ لپاره پای ټکی دی، نه دا ثبوت چې VPN د لاسرسي وړ پاتې کېږي۔ دا د پروسې ژوندي ساتلو تګلاره هم نه ده، او د ګډوډۍ ډېره برخه همدلته پیلېږي۔

ګډوډي زیاتېږي کله چې پر سر یو دوهم میکانیزم کېني۔ هغه څارونکی چې کېلنټ بیا پیلوي، هغه ازموونکی چې ګېټوې ته پنګ کوي، او د بیا هڅې جوړه شوې کړکۍ ټول کولی شي یوې ناکامۍ ته ځواب ووایي، او بیا پېښه درې د وخت کرښې جوړوي چې هیڅوک یې نشي سره سمولای۔

د بیا نښلېدو کړکۍ واقعاً څه محدودوي

تصور وکړئ چې د لاسرسي شبکه څو ثانیو لپاره ورکېږي۔ کېلنټ د اړیکې پرې کېدل ویني، یا د مړ شريک ځوابونه اورېدل بندوي، او هغه حالت چې کولی شي ساتي او د غونډې بیا جوړول پیلوي۔ هڅې تر هغه دوام کوي چې ګېټوې بیا ومني یا کړکۍ ختمه شي، او ختمه شوې کړکۍ په غیر صفر وتلو پای ته رسېږي۔ هماغه وتل، نه د وخت حد ارزښت، هغه ځای دی چې د ژوند دورې مالکیت هغه چا ته ځي چې پروسه څاري۔

کړکۍ د دې په اړه هېڅ نه وایي چې ازموونکی څو ځله ګړندي کېږي، او نه کولی شي تصدیق وغځوي۔ که ګېټوې غونډه لغوه کړې وي، یا حساب اوس نوی دوهم فاکتور غواړي، نور انتظار زړه غونډه بیا معتبره نه کوي۔ بیا هڅه یوازې هغه وخت بریالۍ کېږي چې لار بېرته راشي، ګېټوې غونډه لا پېژني، او غوښتل شوې اعتبارنامه د کارېدو وړ پاتې شي، نو دا شمېره د ژوند مودې وقفې نه، بلکې د پای ټکي په توګه ولولئ۔

کړکۍ د دې هم کنټرول نه کوي چې اپلیکیشنونه د هغې په جریان کې څه کوي۔ د پلیټ فارم او د ناکامۍ د لرېوالي له مخې، کېلنټ ممکن د لارو په نصب حالت کې یا د هغوی له لرې کېدو وروسته بیا ونښلي۔ همدې لپاره د خنډ په منځ کې صادره غوښتنه د ژر ناکامېدو پر ځای تر وخت حد پورې ځوړندې پاتې کېږي۔

د څارونکي بیا پیلول او د کېلنټ بیا هڅې دوه طبقې دي

پرېږدئ چې روانه کېلنټ خپله کړکۍ ولګوي، او د خدمت مدیر دې وتلو ته ځواب ووایي۔ د systemd لاندې د بیا پیل تګلارې سره مخکښ کېلنټ سم هماغه وېش راکوي: محدودې مودې لپاره هڅې، بیا یوه د بیا پیل پریکړه۔ پایله یوه واحده د وخت کرښه ده چې وروسته هم بیا جوړولای شئ۔

د شا په مخ کې کېلنټ او یو خپلواک پوښتونکی چې کله انټرفېس نه ویني بله کاپي پیلوي، هماغه غلط الګو ده۔ بیا دواړه پروسې د یوې وسیلې نوډ، لارو او د حل کوونکي تنظیماتو لپاره سیالي کوي۔ که واقعاً ډیمون غواړئ، انتخاب په هغه کمانډ لاین کې کېږدئ چې کېلنټ واقعاً پرې پیلېږي:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

په دې کرښه کې دوه توکي وزن لري۔ --background پروسه جلا کوي، نو pid فایل پر هغې یوازینی باوري لاستی کېږي، او وخت حد یوازې تر هغه لګول کېږي چې هماغه پروسه ژوندې وي؛ هغه څارونکی چې ووژني یې، د دوام لپاره بودیجه نه پرېږدي۔

قصدي نښلېدنې خپل سیګنال ته اړتیا لري۔ پلان شوې وقفه او ریښتینی خنډ د ساده کتونکي لپاره یو شان ښکاري، دواړه «نښلول شوی نه دی» لوستل کېږي۔ وقفه د څارونکي د بندولو عملیې یا د هغه نښې له لارې چلوئ چې پوښ یې پوهېږي، تر څو قصدي بندښت هغه بیا پیل ونه پاروي چې هیچا نه دی غوښتی۔

د سپارلو مخه نیول چې د بیا هڅې له کړۍ سره سیالي ونه کړي

بې څارنې رغېدنه د هغو اعتبارنامو پورې تړلې ده چې پرته له حاضر کس نوي کېږي۔ یو کیلي بند چې یوازې د متقابل ډیسکټاپ غونډې دننه پرانیستل کېږي، یا یو ټوکن چې تل ټایپ شوی کوډ غواړي، لارې ته په بېرته راتلو کېلنټ په تصدیق مرحله کې بندوي۔ دا کاري بهیر د کړکۍ اوږدولو دمخه سم کړئ، ځکه اوږده کړکۍ یوازې هماغې بندې شوې غوښتنې ته د ناکامۍ نور وخت ورکوي۔

د سرور تصدیق د غوښتنو د کمولو لپاره نرمول نه ښايي۔ هماغه پین یا د باور لنگر چې ګېټوې تصدیقوي، اتوماتیک بیا نښلېدنه خوندي کوي، او د سند پوښتنې د مخنیوي لپاره یې بندول یو لیدل کېدونکی خنډ په نالیدل کېدونکي خنډ بدلوي۔ تصدیق شوې هویت وساتئ او پر ځای یې غوښتنه سمه کړئ؛ هغه کېلنټ چې له هر ګېټوې سره نښلېدو ته تیار وي، له هغه څخه بدتر دی چې ودرېږي او انتظار کوي۔

د انټرفېس شتون هم د روغتیا نښه نه ده۔ د تونل وسیله کولی شي له شا نه مړه غونډه ولري، او پیلوونکې پروسه کولی شي پرته له هېڅ تونل وي۔ له دې کتنو هېڅ یوه هم ریښتینې غوښتنې ته نه شي ټینګېدلای۔ روغتیا باید له هغه څه راشي چې کاروونکي ته اړینه ده، لکه هغه غوښتنه چې د تونل له لارې پېژندل شوې داخلي خدمت ته ځي۔

د خنډ په جریان او وروسته څه تصدیق کړئ

څلور پېښې د جلا ازموینو په توګه وچلوئ: له کړکۍ لنډه وقفه، تر هغې اوږد خنډ، د تصدیق ناکامي او قصدي بندښت۔ هر یو باید په بېل او وړاندوینې وړ حالت کې پای ته ورسیږي، او د لومړیو دوو ترمنځ پوله د ارزښت د ټاکلو ټول دلیل دی۔

کنټرولونه د باندې خوا ته وساتئ، ځکه د پروسو جدول پخپله ډېر لږ ثبوت کوي۔ وګورئ چې pid د لنډ خنډ په اوږدو کې ثابت پاتې کېږي، بیا تایید کړئ چې له اوږد وروسته لاړ او یو ځل بدل شو:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

د لنډ خنډ په جریان کې تایید کړئ چې کېلنټ واقعاً بیا هڅه وکړه نه دا چې ژر ووت، او لارې او د حل کوونکي ننوتنې پرته له کاپي بېرته راغلې۔ د اوږد خنډ لپاره پاک وتل او پرته له شکه یو بیا پیل تایید کړئ۔ د تصدیق ناکامۍ لپاره تایید کړئ چې کېلنټ د هغې ګېټوې پر وړاندې نه څرخي چې رد به یې وي۔ یوه ازموینه ورزیاته کړئ چې pid راټولېدونکی نه، بلکې یو ارزښت ته بېرته راځي۔

د قصدي بندښت لپاره د روغتیا URL باید نه لاسرسي وړ پاتې شي او پروسه باید ښکته پاتې شي۔ بیا له اپلیکیشن خوا کړۍ بنده کړئ: هماغه غوښتنه باید تر هغه چې تونل نشته ناکامه شي او د هغې له بېرته راتلو وروسته له هغه سرچینې پتې بریالۍ شي چې ستاسو تګلاره یې تمه لري۔ شنه د تونل نښه ثبوت نه ده، خو بشپړه شوې غوښتنه ثبوت ده۔