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

Завершіть навмисним тестуванням випадку без тунелю. Знати, як поводиться шлюз без свого тунелю, — частина проєкту, дізнатися це під час збою — ні. Вимкніть тунель, виконайте оновлення метаданих і підтвердьте, що хост зазнає невдачі в задуманий спосіб, а не тихо повертається на відкритий шлях. Тримайте облікові дані сховищ і проксі поза спільною діагностикою та залиште нотатку, хто відповідає за шлях оновлення.