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

Завяршыце наўмыснай праверкай выпадку без тунэля. Ведаць, як паводзіць сябе шлюз без свайго тунэля, — частка праекта; даведацца гэта падчас збою — не. Апусціце тунэль, выканайце абнаўленне метаданых і пераканайцеся, што хост збіваецца задуманым чынам, а не ціха адкочваецца на адкрыты шлях. Трымайце ўліковыя даныя сховішчаў і проксі па-за агульнай дыягностыкай і пакіньце нататку, хто адказвае за шлях абнаўлення.