Вашему 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-сервера — отдельные гарантии, и отключение любой из них, чтобы заглушить ошибку, меняет то, чему вы доверяете, а не то, чего можете достичь.

Завершите намеренной проверкой случая без туннеля. Знать, как ведёт себя шлюз без своего туннеля, — часть проекта; узнать это во время сбоя — нет. Опустите туннель, выполните обновление метаданных и убедитесь, что хост сбоит задуманным образом, а не тихо откатывается на открытый путь. Держите учётные данные репозиториев и прокси вне общих диагностик и оставьте заметку, кто отвечает за путь обновления.