Публікація портів Docker і джерела VPN: два збіги, які ви пропускаєте

Правило каже дозвольте адресу VPN-сервера до опублікованої служби, а з’єднання все одно скидається. Такий результат звичайний, і це не помилка Docker. Два окремі збіги хибні: джерело, яке ви записали, може не бути джерелом, яке отримує хост, а порт, який ви записали, може не бути портом, який бачить фільтр. Щоб виправити обидва, треба дивитися на шлях пакета, а не на схему служби.

Міф: дозвольте VPN-сервер і готово

Маршрутизований VPN може зберігати адресу клієнтського тунелю аж до хоста Docker. Шлюз, що виконує трансляцію джерела, може замінити цю адресу своєю. Обидві схеми законні, і вони дають різні джерела для однієї дії користувача.

Отже, фраза IP-адреса VPN-сервера описує припущення, а не спостереження. Поки ви не знаєте, яка з двох схем перед вами, правило залишається здогадом.

Джерело: пул клієнтів чи транслювальний шлюз

Перевірте чотири речі по порядку. По-перше, пул адрес клієнтів, наприклад 10.90.0.0/24. По-друге, чи транслює шлюз цей пул до того, як він досягне хоста. По-третє, яке джерело хост справді спостерігає для одного нового з’єднання. По-четверте, чи розрізняє автентифікація застосунку окремих користувачів, адже спільна трансльована адреса цього не може.

Якщо пул зберігається, правило, що збігається лише з публічною адресою шлюзу, пропускає кожного клієнта. Якщо шлюз транслює навмисно, дозвіл трансльованої адреси впускає кожного користувача за нею, що може бути прийнятним для служби з власним входом і неприйнятним для всього іншого.

Порт: DNAT змінює число, з яким ви збігаєтеся

За звичайної публікації через міст Linux із Docker iptables відображення хоста з 8443 на порт контейнера 443 транслюється до запуску фільтра пересилання. Пакет надходить до фільтра з портом призначення 443. Правило, що збігається з 8443 у цей момент, ніколи не спрацьовує, хоча клієнт ввів саме 8443.

Опублікований порт досі існує у відстеженні з’єднань, тому початкове призначення можна зіставити там, коли це справді потрібно.

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

Ланцюг: DOCKER-USER, а не INPUT

Посібник Docker з iptables розміщує політику пересилання користувача в ланцюзі DOCKER-USER, який оцінюється перед власними правилами пересилання Docker. Правило, скопійоване зі служби хоста в ланцюг INPUT, фільтрує трафік, адресований хосту, а не трафік, пересланий у контейнер. Ця помилка дає правило, яке виглядає правильним і не впливає на шлях контейнера.

Тримайте діапазон джерела, чинний порт призначення, протокол і вхідний інтерфейс разом в одному правилі. Дозвіл лише за джерелом для кожного пересланого призначення ширший за дозвіл однієї опублікованої служби.

Перевіряйте новими з’єднаннями

Перевірте обидва напрямки новими з’єднаннями: один дозволений клієнт VPN і одне джерело, яке має залишитися забороненим. Наявний стан з’єднання може підтримувати сеанс живим після зміни політики, тому старе з’єднання нічого не доводить щодо нового правила. Потім перевірте шлях відповіді, бо контейнер усе ще має маршрутизувати назад до джерела, яке він бачить.

Порядок ланцюгів і поведінку трансляції портів за цими перевірками описано в посібнику Docker з iptables. Прочитайте його, перш ніж копіювати рецепт, і підтвердьте, який backend використовує встановлений Docker, бо backend nftables інтегрує політику інакше.