DNAT у контейнері VPN: пересилання, а не INPUT

Після DNAT запит до адреси тунелю стає пересиланим трафіком. Звузьте правило пересилання, прочитайте ланцюг Docker і свідомо виберіть зворотний шлях.

Запит приходить з адресою IP тунелю і залишає той самий контейнер з адресою сусідньої служби. Між цими двома моментами DNAT переписав призначення, і пакет перестав бути входом для контейнера VPN. Тепер це пересиланий трафік, який оцінює інше правило. Ця зміна пояснює, чому правило брандмауера, яке виглядає правильним для адреси тунелю, не впливає на перетворене з'єднання.

Простежте пакет після перетворення

Візьміть пул клієнтів 10.90.0.0/24 і адресу тунелю 10.90.0.1. Два контейнери стоять на одному мості: 192.0.2.2 запускає VPN, а 192.0.2.3 запускає застосунок. Клієнт підключається до 10.90.0.1:8080, і правило DNAT у просторі імен контейнера VPN переписує це на реальну адресу й порт застосунку. Потім маршрут надсилає пакет через міст. Ці адреси ілюстративні, це не рецепт розгортання.

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

Дозвіл належить шляху пересилання

Контейнеру VPN потрібне пересилання IP і рішення про пересилання, обмежене пулом клієнтів, адресою застосунку та потрібним портом. Усталеним відповідям потрібен власний дозвіл. Правило, що збігається з початковою адресою тунелю, не збігатиметься після DNAT, бо призначення вже змінилося. Дозвіл INPUT — неправильний гак для трафіку, який більше не адресований цьому хосту.

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

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Ланцюги Docker — не ланцюги вашого контейнера

Правила всередині простору імен контейнера — не правила хоста Docker. Коли трафік переходить з інтерфейсу тунелю на міст, брандмауер мосту на хості може ухвалити інше рішення. За бекенду iptables у Docker документовані ланцюги пересилання й точки зіставлення після DNAT — це місце, де таке рішення з'являється.

Довідка Docker щодо брандмауера описує ці ланцюги й зіставлення після DNAT. Не виправляйте відсутній дозвіл вимкненням керування брандмауером Docker або дозволом кожного ланцюга, бо це прибирає межу, яку ви намагаєтеся використати.

Зробіть зворотний шлях свідомим вибором

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

Перевірте нове дозволене з'єднання зі звичайного клієнта, потім переконайтеся, що не пов'язані порти залишаються закритими. Коли пакет зникає, огляньте простір імен VPN, простір імен застосунку та власний журнал застосунку. Ping до шлюзу мосту не є приймальним тестом служби.

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

Схожі статті