VPN در میانه صفحه قطع شد: آیا درخواست‌های پس‌زمینه هنوز بیرون می‌روند؟
صفحه‌ای که باز رها شده پس از مردن تونل به نظرسنجی، اتصال دوباره و همگام‌سازی ادامه می‌دهد. ببینید کدام تلاش‌ها هنوز بیرون می‌روند و چگونه آن را اثبات کنید.
زبانه هنوز داشبورد پیش از مردن تونل را نشان می‌دهد. اعداد وضعیت یخ می‌زنند، یک چرخنده کوچک همچنان می‌چرخد، و نوار نشانی هنوز برنامه‌ای را دارد که یک ساعت پیش باز کردید. پس از قطع، چیزی را لمس نکردید، با این حال ممکن است صفحه هنوز طبق برنامه خودش تلاش کند به سرور خود برسد. این همان بخشی است که مردم از دست می‌دهند: صفحه‌ای که فقط دیده می‌شود و صفحه‌ای که هنوز درخواست می‌فرستد از بیرون یکسان به نظر می‌رسند، و فقط یکی از آن‌ها در گزارش شبکه دیده می‌شود.
کاری که صفحه بدون شما شروع می‌کند
چهار سازوکار یک سند بارگذاری‌شده را مشغول نگه می‌دارد. یک زمان‌سنج تکراری می‌تواند هر چند ثانیه یک بار فراخوانی وضعیت را دوباره اجرا کند. یک fetch می‌تواند هنگامی که زبانه پس از بازگشت شما دوباره دیده می‌شود فعال شود. یک کانال زنده ساخته‌شده بر WebSocket یا رویدادهای ارسالی سرور می‌تواند طبق برنامه عقب‌نشینی خودش تلاش کند دوباره متصل شود. یک service worker که سایت ثبت کرده است می‌تواند حتی وقتی هیچ زبانه‌ای پیش روی شما نیست، برای همگام‌سازی صف‌شده بیدار شود.
هیچ‌کدام به کلیک نیاز ندارند، و هیچ‌کدام سند را دوباره بارگذاری نمی‌کنند. نوار نشانی، موقعیت پیمایش و مقادیر نمایش‌داده‌شده همه در جای خود می‌مانند. تنها چیزی که تغییر می‌کند سمت شبکه است: هر تلاش جدید تصمیمی تازه است که در لحظه‌ای که آغاز می‌شود گرفته می‌شود.
این تفاوت مهم است چون صفحه دیده‌شده به‌صورت محلی ذخیره شده است. پیکسل‌هایی که قبلاً کشیده شده‌اند چیزی درباره موفقیت درخواست بعدی نمی‌گویند. یک نمودار یخ‌زده با چرخنده ظاهر معمول صفحه‌ای است که درخواست‌هایش اکنون شکست می‌خورند. خواندن صفحه به شما می‌گوید سرور چند دقیقه پیش چه گفت، نه اینکه مرورگر اکنون چه می‌کند.
چرا بارگذاری پیشین صفحه مسیری را نگه نمی‌دارد
هیچ چیزی در بارگذاری صفحه سند را به تونل نمی‌بندد. مسیریابی برای هر بسته، در زمان ارسال، از جدولی که هنگام خروج بسته وجود دارد حل می‌شود. وقتی رابط تونل ناپدید می‌شود، آن جست‌وجو دیگر با مسیر تونل مطابقت ندارد. یا به آداپتور فیزیکی می‌افتد یا هیچ چیز پیدا نمی‌کند، بسته به اینکه کلاینت چه چیزی پشت سر گذاشته است.
فراخوانی‌های تکرارشونده وظایف زمان‌بندی‌شده معمولی هستند. بخش زمان‌سنج‌های استاندارد HTML توضیح می‌دهد چگونه در صف قرار می‌گیرند و بازه را به عنوان حداقل تأخیر می‌بیند نه وعده ریتم دقیق، بنابراین یک زبانه پس‌زمینه می‌تواند بسیار کمتر از آنچه کدش می‌خواهد نظرسنجی کند. تلاش کمتر با هیچ تلاشی یکسان نیست، و آوردن یک زبانه به جلو لحظه رایجی برای هجوم آن‌هاست.
سیاست خرابی کجا فرود می‌آید
بلوک کلاینت هنگام تلاش برای اتصال ارزیابی می‌شود، نه هنگام واکشی صفحه. اگر دسترسی معمولی هنوز مجاز باشد، تلاش دوباره می‌تواند از پیوند فیزیکی به‌صورت آشکار بیرون برود. اگر سیاست آن ترافیک را تا بازگشت تونل نگه دارد، تلاش در زمان اتصال شکست می‌خورد و صفحه خطایی نشان می‌دهد که ممکن است چند ثانیه بعد دوباره تلاش کند.
دو جزئیات تعیین می‌کند کدام‌یک را می‌گیرید. اولی دامنه اجرایی است که کلاینت پشتیبانی می‌کند: بلوک کل دستگاه، بلوکی محدود به آداپتور تونل، یا مجموعه‌ای از قواعد با استثناها. دومی این است که آیا مقصد درون استثنایی قرار می‌گیرد که قبلاً برای چاپگر محلی، درگاه اسیر یا سرویس پخش افزوده‌اید.
رمزگذاری در سطح برنامه هیچ‌یک از این‌ها را تغییر نمی‌دهد. HTTPS بایت‌های میان مرورگر و سرور را محافظت می‌کند؛ چیزی درباره اینکه کدام رابط آن‌ها را حمل می‌کند نمی‌گوید. صفحه می‌تواند کاملاً رمزگذاری‌شده باشد و باز هم از مسیر اشتباه بیرون برود، و این دقیقاً همان چیزی است که یک بلوک باریک اجازه می‌دهد.
یک بررسی کنترل‌شده با صفحه‌ای یک‌بارمصرف
از میزبان تحت کنترل خودتان و صفحه‌ای استفاده کنید که کاری جز فراخوانی آن نمی‌کند، تا هیچ داده واقعی در میان نباشد. از یک ترمینال، مسیر را پیش و پس از قطع نمونه‌برداری کنید:
curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/pingآن را با تونل بالا اجرا کنید، سپس تونل را پایین بیاورید و دوباره اجرا کنید. پاسخ از یک نشانی عمومی در حالی که تونل پایین است به شما می‌گوید مسیر مستقیم باز است. پایان مهلت یا اتصال ردشده به شما می‌گوید سیاست نگه داشته است. پس از اتصال دوباره کلاینت یک بار دیگر تکرار کنید تا ببینید مسیر تونل بازمی‌گردد، نه اینکه فرض کنید چنین شده.
در مرورگر، پنل شبکه دو پرسش را جدا می‌کند. به Fetch/XHR فیلتر کنید، سپس ستون آغازگر را بخوانید: ورودی که یک زمان‌سنج یا اسکریپت آغاز کرده و پیش از آن هیچ ناوبری ثبت نشده، تلاشی پس‌زمینه است نه بارگذاری دوباره. زمان شروع آن را با لحظه‌ای که تونل قطع شد مقایسه کنید. اگر ورودی هنوز در انتظار است در حالی که تونل رفته، درخواست منتظر مسیری است که دیگر وجود ندارد.
شواهد سمت سرور از هر چیزی که مرورگر نشان می‌دهد قوی‌تر است. گزارش درخواست با برچسب زمانی و نشانی مبدأ اثبات می‌کند بسته رسیده است. ورودی‌های مرورگر می‌توانند کوکی‌ها، توکن‌ها و URLهای کامل را حمل کنند، بنابراین فقط فیلدهایی را نگه دارید که پرسش شما نیاز دارد و بقیه را پیش از چسباندن در هر جا پنهان کنید.
با پاسخ چه کنید
اگر تلاش‌های پس‌زمینه در حالی که تونل پایین است همچنان موفق می‌شوند، بلوک باریک‌تر از آن است که فرض می‌کردید، و آن شکاف ارزش بستن دارد پیش از آنکه برای کار حساس به کلاینت اعتماد کنید. اگر شکست می‌خورند، سیاست کار خود را می‌کند و صفحه یخ‌زده ظاهری است. در هر حال، بستن یک زبانه کنترل کل دستگاه نیست: زبانه‌های دیگر، مرورگرهای دیگر و برنامه‌های دیگر هر یک کار خود را زمان‌بندی می‌کنند.
گام‌های بعدی که ارزش برداشتن دارند: فهرست کنید چه استثناهایی و چرا افزوده‌اید، تأیید کنید کلاینت فقط ترافیک درون دامنه تونل را مسدود می‌کند یا همه ترافیک را، و یک درخواست پس‌زمینه را از ابتدا تا انتها با گزارش سرور باز تماشا کنید. آن سه پاسخ بیشترِ آنچه را پوشش می‌دهد که گزارش «VPN قطع شد و چیزی هنوز متصل است» واقعاً در خود دارد.