به‌روزرسانی دروازهٔ VPN شکست می‌خورد: پیش از باز کردن خروجی، مرحله را بخوانید
به‌روزرسانی ناموفق یک مرحله را نام می‌برد، نه یک درگاه گمشده. پیام را به صاحبش نسبت دهید، مسیر پروکسی را بخوانید و سپس آگاهانه سیاست نگهداری را تعیین کنید.
امتناع از نصب به‌روزرسانی‌های امنیتی فقط یک هفتهٔ بد با تبدیل شدن به مشکل فرد دیگری فاصله دارد، و دروازه‌ای که مشتریان را می‌پذیرد آسان‌ترین جایی است که این عادت در آن شکل می‌گیرد. علت معمول یک مسیر گمشده نیست بلکه یک تصمیم گمشده است: هیچ‌کس نگفت خودِ میزبان چگونه باید وقتی ارسال مشتریان عمداً باریک است به یک مخزن برسد. این تصمیم باید صریح گرفته شود و باید باریک‌تر از خاموش کردن سیاست خروجی برای یک بعدازظهر باشد.
چهار مرحله، چهار صاحب متفاوت
شکست به‌روزرسانی یک مرحلهٔ نام‌دار است، چه پیام بگوید چه نگوید، و هر مرحله به صاحب متفاوتی تعلق دارد. نامی که حل نمی‌شود پرسشی برای حل‌کننده است. اتصالی که مهلتش تمام می‌شود پرسشی برای انتقال، پروکسی یا طرف دور است. خطای هویت TLS پرسشی دربارهٔ اعتماد است، و فراداده‌های مخزن ردشده پرسشی دربارهٔ امضا هستند. چهار مرحله، چهار صاحب، و یک قاعدهٔ درگاه همیشه فقط به یکی از آن‌ها پاسخ می‌دهد.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
پینگ و تجزیهٔ نام دو آزمونی هستند که مردم اول به آن‌ها متوسل می‌شوند، و هر دو به پرسش‌هایی پاسخ می‌دهند که کسی نپرسیده است. پاسخ بازتاب از پروتکل متفاوتی نسبت به اتصال مخزن استفاده می‌کند، و جست‌وجوی موفق در تجزیهٔ نام متوقف می‌شود بدون آزمودن واکشی. هر دو می‌توانند موفق شوند در حالی که معاملهٔ واقعی شکست می‌خورد، و هر دو می‌توانند به دلایلی نامرتبط با مسیر شکست بخورند.
مسیری را بخوانید که مدیر واقعاً طی می‌کند
URIهای مبدأ پیکربندی‌شده و چیدمان واقعی پروکسی را بررسی کنید، به‌جای اینکه یکی از آن دو را فرض بگیرید. قاعده‌ای که برای HTTP ساده نوشته شده وقتی مخزن HTTPS سخن می‌گوید اصلاح نیست، و سازمانی که پروکسی را الزامی می‌کند مسیر را از پیش انتخاب کرده است. مدیران بسته به متغیرهای محیطی و پیکربندی خودشان احترام می‌گذارند، و تنظیمات مخصوص میزبان می‌تواند یک تنظیم جهانی را نادیده بگیرد. آنچه یک مرورگر تعاملی انجام می‌دهد لزوماً همان چیزی نیست که مدیر انجام می‌دهد.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyمستندات انتقال APT توضیح می‌دهد کدام تنظیمات برای کدام طرح‌وارهٔ URI اعمال می‌شوند و انتخاب‌های مخصوص میزبان چگونه نوشته می‌شوند. خروجی فرمان‌ها را همراه تیکت نگه دارید، زیرا مشکل پروکسی را از مسیر گمشده سریع‌تر از هر تعداد نتیجهٔ پینگ جدا می‌کند. مقصد، درگاه و پروتکل دقیقی را که مدیر می‌آزماید بنویسید، و تغییر دیوار آتش را بر همان سابقه استوار کنید نه بر نشانی آینه‌ای حدسی که در چند ماه کهنه می‌شود.
یک سیاست نگهداری انتخاب کنید، نه یک استثنا
سه سیاست قابل دفاع است: نگهداشت از طریق تونل، نگهداشت از طریق پروکسی به‌روزرسانی مدیریت‌شده، یا نگهداشت از طریق مسیری مستقیم با مجوز باریک. هر یک چیدمان حل‌کننده‌ای متناسب با خود می‌طلبد. آنچه قابل دفاع نیست استثنایی است که هر بار که تونل می‌افتد بی‌صدا به مسیری پشتیبان و نامحدود تبدیل می‌شود.
سیاست انتخاب‌شده را همراه با یک صاحب بنویسید، زیرا اپراتور بعدی قاعده را پیدا می‌کند نه استدلال پشت آن را. مجوز را از طریق دیوار آتش موجود و صاحب شبکه اعمال کنید، نه با پاک کردن قواعد یا افزودن مدیر سیاست دومی برای یک میزبان. خانواده‌های نشانی و نقاط پایانی سرویسی را که مبدأ واقعی استفاده می‌کند پوشش دهید، و فهرست را وقتی مخزن جابه‌جا می‌شود بازبینی کنید.
بدون تضعیف اعتماد بررسی کنید
انتقال موفق اجازهٔ سست کردن بررسی نیست: احراز اصالت آرشیو و هویت سرور TLS دو بررسی جداگانه‌اند، و غیرفعال کردن هر کدام خطا را محو می‌کند در حالی که تغییر می‌دهد میزبان چه چیزی را خواهد پذیرفت. پروکسی شنودکننده تصمیم اعتماد صاحب شبکه است نه دلیلی برای خاموش کردن بررسی به‌صورت محلی، و اعتبارنامه‌های مخزن جایشان در تشخیص‌های مشترک نیست، زیرا گزارش مفصل آسان‌ترین جای نشت آن‌هاست.
تغییر را با واکشی کنترل‌شدهٔ فراداده و سپس یک تراکنش بستهٔ تأییدشده بپذیرید، سپس بیازمایید وقتی تونل می‌افتد چه رخ می‌دهد. مسیر نگهداری که در زمان قطعی بی‌صدا گسترده‌تر می‌شود بدتر از مسیری است که بسته شکست می‌خورد، و نتیجه باید یک مسیر به‌روزرسانی با صاحب نام‌دار و دامنهٔ محدود باشد.