دروازهٔ VPN شما هنوز به راهی برای نصب به‌روزرسانی‌ها نیاز دارد
دروازهٔ قفل‌شده باز هم باید به مخزن‌هایش برسد. دریابید کدام مرحله شکست خورده است، سپس دقیقاً همان مسیر را مجاز کنید نه اینکه ترافیک خروجی را باز کنید.
تونل برای همه کسانی که پشت آن هستند کار می‌کند، دروازه ترافیک آنان را عبور می‌دهد، و با این حال خود دستگاه نمی‌تواند به‌روزرسانی امنیتی نصب کند. این شکل معمول مسئله است: اجازهٔ عبور به کلاینت‌ها داده شد و اتصال‌های خروجی خود دروازه هرگز در برنامه گنجانده نشد. مدیر بسته سوکت‌های خودش را باز می‌کند، از دروازه، به سمت مخزنی که احتمالاً هیچ‌جا در سیاست دیوار آتش نامش را نبرده‌اید.
قفل کردن دروازه درست است. قفل کردن آن چنان محکم که دریافت وصله‌ها را متوقف کند تصمیم دیگری است، و معمولاً تصادفی.
خروجی محلی عبور کلاینت نیست
قواعد عبور بسته‌هایی را کنترل می‌کنند که از جای دیگری می‌رسند و از دروازه خارج می‌شوند. ترافیک به‌روزرسانی خود دروازه هرگز با آن‌ها مطابقت ندارد؛ به‌صورت محلی تولید می‌شود و مسیر خروج را طی می‌کند. همین تفاوت خرابی‌ای را توضیح می‌دهد که در حالی که دسترسی کلاینت‌ها بی‌عیب کار می‌کند، غیرممکن به نظر می‌رسد.
همچنین شکافی در سیاست را توضیح می‌دهد که از آزمون‌ها جان سالم به در می‌برد، چون بررسی سریع از لپ‌تاپی پشت تونل ثابت می‌کند زنجیرهٔ عبور کار می‌کند و هیچ چیزی دربارهٔ اتصال‌های خود میزبان نمی‌گوید. دروازه را دو موضوع در نظر بگیرید: مسیریابی با زنجیرهٔ عبور و میزبانی با زنجیرهٔ خروج. هر دو به یک نظر نیاز دارند و معمولاً فقط یکی از آن‌ها نوشته می‌شود.
مرحله‌ای را که شکست خورد نام ببرید
خطاهای به‌روزرسانی مرزهای متفاوتی را نام می‌برند، و چنگ زدن به قاعدهٔ درگاه پیش از خواندن اینکه کدام شکست خورد یک بعدازظهر را هدر می‌دهد. نام مخزنی که حل نمی‌شود پرسش resolver است، نه پرسش انتقال.
getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true updateوقفه پس از یک جستجوی موفق پرسش را به انتقال می‌برد: مدیر بسته در واقع کدام نشانی، کدام درگاه و کدام پراکسی پیکربندی‌شده را امتحان کرد. خطای بررسی TLS چیز سوم و کاملاً دیگری است، و یعنی اتصال به‌اندازهٔ کافی خوب کار کرد تا مذاکره کند. شکایت دربارهٔ احراز هویت آرشیو مرحلهٔ چهارم است، و به فراداده‌های امضاشده مربوط است نه به دسترس‌پذیری. چهار مرحله، چهار تعمیر متفاوت، و ping همیشه تنها یک پروتکل را توصیف می‌کند که هیچ مدیر بسته‌ای از آن استفاده نمی‌کند.
پیش از افزودن قاعده فهرست منابع را بخوانید
URIهای واقعی منابع و پیکربندی مؤثر پراکسی را فهرست کنید، نه آن‌هایی که به یاد دارید. قاعده‌ای که برای HTTP ساده نوشته شده وقتی منبع HTTPS است بی‌فایده است، و پراکسی‌ای که پوسته می‌شناسد ممکن است برای سرویسی که هنگام راه‌اندازی با محیطی دیگر اجرا می‌شود نامرئی باشد.
مستندات انتقال HTTP در APT تنظیمات پراکسی محیطی و مخصوص APT را پوشش می‌دهد، از جمله انتخاب‌ها برای هر میزبان، و انتقال HTTPS آن تنظیمات بررسی خودش را دارد. مسیری که مرورگر طی می‌کند و مسیری که مدیر بسته طی می‌کند دو مسیر جداگانه‌اند، حتی روی یک دستگاه.
توجه کنید که منابع به کدام خانواده‌های نشانی حل می‌شوند. قاعده‌ای که فقط IPv4 را مجاز می‌کند روی میزبانی که منابعش رکورد AAAA را ترجیح می‌دهند همچنان شکست می‌خورد، و خطا متناوب به نظر می‌رسد چون به این بستگی دارد که کدام پاسخ اول برسد.
یک مسیر نگهداری انتخاب کنید و به آن پایبند بمانید
سه گزینهٔ قابل دفاع وجود دارد: ترافیک نگهداری از طریق تونل، از طریق پراکسی به‌روزرسانی مدیریت‌شده، یا از طریق استثنای مستقیم باریک. یکی را آگاهانه انتخاب کنید و کاری کنید resolver با آن موافق باشد، چون شکافی که در آن نام‌ها به یک سو حل می‌شوند و اتصال‌ها به سوی دیگر می‌روند خرابی‌هایی می‌سازد که هیچ‌کس نمی‌تواند توضیح دهد.
هر چه انتخاب کنید، نباید به یک راه بازگشت نامحدود تبدیل شود. اگر ترافیک خروجی مستقیم هنگام قطع تونل ممنوع باشد، استثنای نگهداری‌ای که بی‌صدا همه‌چیز را مجاز می‌کند تغییری در سیاست است که لباس تعمیر پوشیده. نقطهٔ پایانی خود تونل و نیازهای bootstrap را در دسته‌ای جدا از دسترسی به مخزن نگه دارید، چون به مقصدهای متفاوتی اشاره می‌کنند و به شکل‌های متفاوتی شکست می‌خورند، بنابراین یک استثنا نمی‌تواند دیگری را بپوشاند.
بدون تضعیف بررسی‌ها تأیید کنید
دامنه را از طریق همان دیوار آتشی اعمال کنید که از قبل صاحب سیاست است، نه با افزودن مدیر دومی چون یک راهنما از آن استفاده کرده. سپس یک تازه‌سازی فراداده و یک تراکنش واقعی بسته را زیر سیاست نگه‌داشته‌شده اجرا کنید، و خروجی را بخوانید نه فقط وضعیت خروج.
انتقال موفق اجازهٔ سست کردن بررسی نیست. احراز هویت آرشیو و هویت سرور TLS دو تضمین جداگانه‌اند، و غیرفعال کردن هر یک از آن‌ها برای خاموش کردن یک خطا چیزی را که به آن اعتماد دارید تغییر می‌دهد، نه چیزی را که می‌توانید به آن برسید.
با آزمودن عامدانهٔ حالت بدون تونل پایان دهید. دانستن اینکه دروازه بدون تونلش چگونه رفتار می‌کند بخشی از طراحی است، کشف آن در هنگام قطعی نیست. تونل را پایین بیاورید، تازه‌سازی فراداده را اجرا کنید و تأیید کنید که میزبان به شکل موردنظر شکست می‌خورد نه اینکه بی‌صدا به مسیری باز برگردد. اعتبارنامه‌های مخزن و پراکسی را بیرون از تشخیص‌های مشترک نگه دارید و یادداشتی بگذارید که مشخص کند مسیر به‌روزرسانی از آن کیست.