Вашият 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, а прокси, което shell-ът познава, може да е невидимо за услуга, стартирана при зареждане с друга среда.

Документацията на HTTP транспорта в APT обхваща прокси настройките на средата и специфичните за APT, включително избори за отделни хостове, и нейният HTTPS транспорт има собствени настройки за проверка. Пътят на браузъра и пътят на мениджъра на пакети са отделни пътища, дори на една и съща машина.

Отбележете към кои семейства се разрешават източниците. Правило, което позволява само IPv4, ще продължи да се проваля на хост, чиито източници предпочитат AAAA запис, и грешката изглежда периодична, защото зависи кой отговор пристига пръв.

Изберете един път за поддръжка и се придържайте към него

Съществуват три защитими опции: трафик за поддръжка през тунела, през управлявано прокси за актуализации или през тясно пряко изключение. Изберете една съзнателно и се погрижете resolver-ът да е съгласен, защото разделение, в което имената се разрешават в една посока, а връзките отиват в друга, създава повреди, които никой не може да обясни.

Каквото и да изберете, то не бива да се превръща в неограничена резервна възможност. Ако директният изходящ трафик е забранен, когато тунелът е спрян, изключение за поддръжка, което тихо позволява всичко, е промяна в политиката, маскирана като поправка. Дръжте собствения край на тунела и нуждите от bootstrap в отделна категория от достъпа до хранилища, защото те сочат към различни дестинации и се провалят по различни начини, така че едно изключение не може да покрие другото.

Проверявайте, без да отслабвате контролите

Приложете обхвата чрез защитната стена, която вече притежава политиката, вместо да добавяте втори мениджър, защото едно ръководство го е използвало. След това стартирайте опресняване на метаданните и една истинска транзакция с пакети при поддържаната политика, и четете изхода, а не само кода за изход.

Успешният транспорт не е разрешение да се облекчи проверката. Удостоверяването на архива и идентичността на TLS сървъра са отделни гаранции, и изключването на което и да е от тях, за да се заглуши грешка, променя това, на което се доверявате, а не това, което можете да достигнете.

Завършете с умишлено тестване на случая без тунел. Да знаете как се държи шлюзът без своя тунел е част от проекта, да го откриете по време на прекъсване не е. Спрете тунела, стартирайте опресняването на метаданните и потвърдете, че хостът се проваля по начина, който сте предвидили, вместо тихо да се върне към отворен път. Дръжте идентификационните данни за хранилищата и проксито извън споделената диагностика и оставете бележка кой отговаря за пътя за актуализация.