OpenConnect چه مدت باید اتصال VPN قطع‌شده را دوباره امتحان کند؟

--reconnect-timeout به یک پرسش باریک پاسخ می‌دهد: پس از افتادن تونل، این فرایند کارخواه چه مدت به تلاش ادامه می‌دهد تا اینکه تسلیم شود و خارج شود. صفحه راهنمای OpenConnect این گزینه را با پیش‌فرض مستند 300 ثانیه برای تلاش‌های دوباره‌ای که پس از گم شدن پیوند یا همتایی که پاسخ‌دهی را متوقف کرده می‌آیند ثبت می‌کند، و این عدد یک مهلت برای یک کارخواه در حال اجراست، نه مدرکی بر دسترس‌پذیر ماندن VPN. همچنین سیاستی برای زنده نگه داشتن فرایند نیست، و بیشتر سردرگمی از همین‌جا شروع می‌شود.

سردرگمی زمانی دوچندان می‌شود که سازوکار دومی روی آن بنشیند. یک ناظر که کارخواه را دوباره راه‌اندازی می‌کند، یک کاوشگر که دروازه را پینگ می‌کند، و پنجره تلاش دوباره توکار همگی می‌توانند به یک خرابی واکنش نشان دهند، و آنگاه رخداد سه خط زمانی می‌سازد که هیچ‌کس نمی‌تواند آن‌ها را هماهنگ کند.

پنجره اتصال مجدد در واقع چه چیزی را محدود می‌کند

تصور کنید شبکه دسترسی چند ثانیه ناپدید می‌شود. کارخواه قطع پیوند را می‌بیند، یا شنیدن پاسخ‌های همتای مرده را متوقف می‌کند، و ضمن نگه داشتن هر وضعیتی که می‌تواند، بازسازی نشست را آغاز می‌کند. تلاش‌ها تا زمانی که دروازه دوباره بپذیرد یا پنجره تمام شود ادامه می‌یابند، و پنجره‌ای که تمام شود با خروجی غیرصفر پایان می‌یابد. همان خروجی، نه مقدار مهلت، جایی است که مالکیت چرخه عمر به هر کس که بر فرایند نظارت می‌کند منتقل می‌شود.

پنجره هیچ چیزی درباره اینکه کاوشگر هر چند وقت یک بار اجرا می‌شود نمی‌گوید، و نمی‌تواند احراز هویت را تمدید کند. اگر دروازه نشست را باطل کرده باشد، یا حساب اکنون عامل دوم تازه‌ای بخواهد، انتظار بیشتر نشست قدیمی را دوباره معتبر نمی‌کند. تلاش دوباره تنها زمانی موفق می‌شود که مسیر بازگردد، دروازه هنوز نشست را بشناسد، و اعتبارنامه‌هایی که می‌خواهد قابل استفاده بمانند، پس عدد را به‌عنوان مهلت بخوانید نه بازه زنده‌بودن.

پنجره همچنین تعیین نمی‌کند که برنامه‌ها در طول آن چه می‌کنند. بسته به سکو و به اینکه خرابی تا کجا پیش رفته باشد، کارخواه ممکن است با مسیرهایی که هنوز نصب‌اند یا پس از برداشته شدن آن‌ها دوباره متصل شود. به همین دلیل درخواستی که در میانه قطعی صادر می‌شود معمولاً تا پایان مهلت معلق می‌ماند، به‌جای آنکه سریع شکست بخورد.

راه‌اندازی دوباره ناظر و تلاش دوباره کارخواه دو لایه‌اند

بگذارید کارخواه در حال اجرا پنجره خودش را خرج کند، و بگذارید مدیر سرویس به خروجی واکنش نشان دهد. کارخواهی در پیش‌زمینه زیر systemd با سیاست راه‌اندازی دوباره دقیقاً همین تقسیم را می‌دهد: تلاش برای دوره‌ای محدود، سپس یک تصمیم راه‌اندازی دوباره. نتیجه یک خط زمانی واحد است که بعداً هم می‌توانید بازسازی کنید.

کارخواهی در پس‌زمینه به‌همراه یک پرسشگر مستقل که وقتی رابطی نمی‌بیند نسخه دیگری را راه می‌اندازد، همان الگویی است که خراب می‌شود. آنگاه هر دو فرایند بر سر همان گره دستگاه، مسیرها و تنظیمات resolver رقابت می‌کنند. اگر واقعاً دیمن می‌خواهید، گزینه را روی همان خط فرمانی بگذارید که کارخواه واقعاً با آن آغاز می‌شود:

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)"

در طول وقفه کوتاه تأیید کنید که کارخواه واقعاً دوباره تلاش کرده است نه اینکه زودتر خارج شده باشد، و اینکه مسیرها و ورودی‌های resolver بدون تکرار بازگشته‌اند. برای قطعی طولانی‌تر، خروجی پاک و دقیقاً یک راه‌اندازی دوباره پس از آن را تأیید کنید. برای شکست احراز هویت، تأیید کنید که کارخواه در برابر دروازه‌ای که همچنان ردش می‌کند نمی‌چرخد. بررسی‌ای بیفزایید که pid به یک مقدار واحد بازمی‌گردد نه اینکه انباشته شود.

برای توقف عمدی، نشانی سلامت باید دسترس‌ناپذیر بماند و فرایند پایین بماند. سپس حلقه را از سمت برنامه ببندید: همان درخواست باید تا وقتی تونل نیست شکست بخورد و پس از بازگشت آن کامیاب شود، از نشانی مبدأیی که سیاست شما انتظار دارد. یک نماد تونل سبز مدرک نیست، اما درخواست کامل‌شده مدرک است.