د 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 یعنې یوازې کوکي بدله کړئ. بېله ګوتهنښه یعنې د سرور سند په رښتیا بدل شوی، نو په قصد سره یې بیا پین کړئ او ولیکئ چا تصویب کړ.
د ټایپ کولو پرځای توکي تولید کړئ
ConnMan د NetworkManager برخلاف د 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 حالت چلوي او یوازې د کوکي کرښه بیا لیکي. اسناد له سکریپټ څخه بهر او یوازې هغه حساب لپاره لوستل کېدونکي وساتئ چې هغه چلوي، او بیا لیکل اتومي کړئ ترڅو ناکامه چلونې نیمه لیکل شوی فایل پرېنږدي.
که تازه کول هر څو ساعتونو کې اړین وي، وقفه ولیکئ. دا د ګیټوې د سیشن تګلارې ځانګړنه ده، او دا ټاکي چې تازه کول اتومات شي که اوږد سیشن وغوښتل شي.