Актуализацията на 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 и разрешаването на имена са двата теста, към които хората се обръщат първо, и двата отговарят на въпроси, които никой не е задал. Отговорът echo използва различен протокол от връзката с хранилището, а успешното търсене спира при разрешаването на имена, без да тества изтеглянето. И двете могат да минат, докато реалната транзакция се проваля, и двете могат да се провалят по причини, несвързани с пътя.
Прочетете пътя, който управителят действително следва
Прегледайте конфигурираните изходни 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 сървъра са две отделни проверки и изключването на която и да е от тях кара грешка да изчезне, докато променя какво хостът ще приеме. Прихващащото прокси е решение за доверие на собственика на мрежата, а не причина да изключите проверката локално, а идентификационните данни на хранилището не принадлежат в споделената диагностика, защото подробният журнал е най-лесното място за изтичането им.
Приемете промяната с контролирано извличане на метаданни, последвано от една одобрена транзакция на пакет, и след това тествайте какво се случва, когато тунелът падне. Път за поддръжка, който тихо се разширява по време на прекъсване, е по-лош от такъв, който се проваля затворен, и резултатът трябва да бъде път за актуализации с посочен собственик и ограничен обхват.