Оновлення 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 |
Ping і розв’язання імен — два тести, до яких люди звертаються першими, і обидва відповідають на питання, яких ніхто не ставив. Відповідь луни використовує інший протокол, ніж з’єднання зі сховищем, а успішний запит зупиняється на розв’язанні імен, не перевіряючи завантаження. Обидва можуть пройти, поки реальна транзакція зривається, і обидва можуть зірватися з причин, не пов’язаних зі шляхом.
Прочитайте шлях, яким менеджер справді йде
Перегляньте налаштовані вихідні URI та фактичну схему проксі, замість того щоб припускати одне з двох. Правило, написане для звичайного HTTP, не є виправленням, коли сховище говорить HTTPS, а організація, що вимагає проксі, вже обрала шлях. Менеджери пакетів поважають змінні середовища та власну конфігурацію, а налаштування, специфічні для хоста, можуть перекрити глобальні. Те, що робить інтерактивний браузер, не обов’язково те, що робить менеджер.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyДокументація транспорту APT описує, які налаштування діють для якої схеми URI і як записуються вибори, специфічні для хоста. Зберігайте вивід команд разом із тикетом, бо він відділяє проблему проксі від відсутнього маршруту швидше, ніж будь-яка кількість результатів ping. Запишіть точні призначення, порт і протокол, які пробує менеджер, і нехай зміна брандмауера спирається на цей запис, а не на вигадану дзеркальну адресу, що застаріє за кілька місяців.
Виберіть політику обслуговування, а не виняток
Три політики можна захистити: обслуговування через тунель, обслуговування через керований проксі оновлень або обслуговування через вузько авторизований прямий маршрут. Кожна передбачає відповідну схему розв’язувача. Те, що незахистиме, — це виняток, який тихо перетворюється на необмежений запасний шлях щоразу, коли тунель падає.
Запишіть вибрану політику разом з власником, бо наступний оператор знайде правило, а не обґрунтування за ним. Застосуйте дозвіл через наявний брандмауер і власника мережі, а не через очищення правил або додавання другого менеджера політик для одного хоста. Охопіть родини адрес і сервісні кінцеві точки, які використовує справжнє джерело, і перегляньте список, коли сховище переїжджає.
Перевіряйте, не послаблюючи довіру
Успішний транспорт — не дозвіл послабити перевірку: автентифікація архіву й ідентичність TLS-сервера — дві різні перевірки, і вимкнення будь-якої з них прибирає помилку, змінюючи те, що хост прийме. Перехоплювальний проксі — це рішення про довіру власника мережі, а не причина вимикати перевірку локально, а облікові дані сховища не місце в спільній діагностиці, бо докладний журнал — найлегше місце для їхнього витоку.
Прийміть зміну за контрольованого отримання метаданих, а потім однієї схваленої транзакції пакета, і після перевірте, що відбувається, коли тунель падає. Шлях обслуговування, який під час збою тихо розширюється, гірший за той, що зривається закритим, і результатом має бути шлях оновлення з названим власником і обмеженим охопленням.