VPN دوباره وصل شد، اما نشست برنامه همچنان شکست می‌خورد

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

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

چه چیزی از اتصال دوباره جان سالم به در می‌برد و چه چیزی نه

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

برخی کارخواه‌ها قلابی می‌افزایند که هنگام اتصال دوباره اتصال‌های کهنه را رها می‌کند، و بیشترشان نمی‌کنند. رفتار اینجا بسته به کارخواه، سکو و نسخه متفاوت است.

طرف دور شما را هم فراموش کرده است

انتهای دور وضعیت خودش را نگه می‌دارد: یک نشست TLS، یک بلوک کنترل TCP، و شاید یک ورودی نقشه‌برداری که نشانی و درگاه شما را به جریان گره می‌زند. یک دستگاه ترجمه در طول مسیر می‌تواند آن نقشه‌برداری را در فاصلهٔ قطع شدن منقضی کند حتی وقتی تونل به‌سرعت دوباره برقرار می‌شود. وقتی نقشه‌برداری از میان برود، بسته‌ها برای جریانی می‌رسند که سرور دیگر آن را نمی‌شناسد، و پاسخ می‌تواند یک reset باشد که کارخواه هرگز نشانش نمی‌دهد. برنامه‌ها این را به‌عنوان گیر کردن گزارش می‌دهند نه خطا، چون هنوز منتظر سوکتی هستند که هرگز پاسخ نخواهد داد.

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

درخواست تازه همان آزمونی است که آنها را جدا می‌کند

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

در طول آزمون هر بلوک ترافیک مستقیم را سر جایش نگه دارید. درخواستی که از یک مسیر جایگزین تصادفی موفق شود چیزی دربارهٔ تونل ثابت نمی‌کند.

با یک اتصال تازه تأیید کنید، نه با اتصال قدیمی

دستورهای زیر سوکت‌هایی را که هنوز باز هستند نشان می‌دهند، یک درخواست تازه آغاز می‌کنند و بررسی می‌کنند که آیا جدول نشست‌ها هنوز ورودی‌ای برای جریان دارد. اولین را پیش و پس از اتصال دوباره اجرا کنید تا تفاوت دیده شود. میزبان و درگاه را با سرویس خودتان جایگزین کنید.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

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

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