Ажурирање VPN приступника не успева: прочитајте фазу пре отварања излаза

Одбијање инсталирања безбедносних ажурирања само је једна лоша недеља удаљено од тога да постанете туђи проблем, а приступник који пушта клијенте најлакше је место за развијање те навике. Уобичајени узрок није рута која недостаје, него одлука која недостаје: нико није рекао како сам хост треба да дође до репозиторијума када је прослеђивање клијената намерно уско. Та одлука мора се донети изричито и мора бити ужа од искључивања излазне политике на једно поподне.

Четири фазе, четири различита власника

Неуспех ажурирања је именована фаза, без обзира на то да ли то порука каже или не, а свака фаза припада другом власнику. Име које се не може разрешити питање је за разрешивач. Веза која истекне питање је за пренос, прокси или удаљени крај. Грешка идентитета TLS питање је поверења, а одбијени метаподаци архиве питање су потписа. Четири фазе, четири власника, а правило порта увек одговара само на једно од њих.

Пинг и разрешавање имена два су теста којима се људи прво служе, и оба одговарају на питања која нико није поставио. Одговор еха користи други протокол од везе према репозиторијуму, а успешна претрага зауставља се на разрешавању имена без тестирања преузимања. Оба могу проћи док стварна трансакција не успева, и оба могу не успети из разлога који немају везе са путем.

Прочитајте пут којим управник заиста иде

Прегледајте конфигурисане изворне URI-је и стварни распоред проксија уместо да претпоставите било шта од тога. Правило написано за обичан HTTP није поправка када репозиторијум говори HTTPS, а организација која захтева прокси већ је одабрала пут. Управници пакета поштују променљиве окружења и сопствену конфигурацију, а поставке специфичне за хост могу надјачати глобалну. Оно што ради интерактивни прегледач не мора бити оно што ради управник.

apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxy

Документација преноса APT-а описује које поставке важе за коју URI шему и како се записују избори специфични за хост. Сачувајте излаз наредби уз тикет јер брже одваја проблем проксија од руте која недостаје него било који број пинг резултата. Запишите тачно одредиште, порт и протокол које управник покушава и пустите да промена заштитног зида почива на том запису место на претпостављеној огледалној адреси која застари у року од неколико месеци.

Изаберите политику одржавања, а не изузетак

Три су политике одбрањиве: одржавати кроз тунел, одржавати кроз управљани прокси за ажурирања или одржавати кроз уско овлашћену директну руту. Свака подразумева одговарајући распоред разрешивача. Оно што није одбрањиво јесте изузетак који тихо постаје неограничени резервни пут сваки пут кад тунел падне.

Запишите изабрану политику са власником јер ће следећи оператер наћи правило, а не образложење иза њега. Примените дозволу кроз постојећи заштитни зид и власника мреже уместо пражњења правила или додавања другог управника политика за један хост. Покријте фамилије адреса и услужне крајње тачке које стварни извор користи и прегледајте списак када се репозиторијум пресели.

Проверавајте без слабљења поверења

Успешан пренос није дозвола за попуштање провере: аутентификација архиве и идентитет TLS сервера две су различите провере, а искључивање било које од њих чини да грешка нестане док мења оно што ће хост прихватити. Пресрећући прокси одлука је о поверењу власника мреже, а не разлог за искључивање провере локално, а акредитиви репозиторијума не припадају заједничкој дијагностици јер је детаљан запис најлакше место за њихово цурење.

Прихватите промену уз контролисано преузимање метаподатака и затим једну одобрену трансакцију пакета, а затим тестирајте шта се дешава када тунел падне. Пут одржавања који се током прекида тихо шири гори је од онога који не успева затворен, а резултат би требало да буде пут ажурирања са именованим власником и ограниченим обимом.