Регистрация Войти
Рейтинг:1
avatar Server

Убедитесь, что трафик Docker для узла в Swarm проходит исключительно через VPN-соединение.

флаг in
Matt Olan

У меня есть два узла в кластере Docker Swarm. Один из этих узлов имеет клиентское соединение OpenVPN с провайдером VPN на интерфейсе. тун0. Мои цели,

  • Любые службы, назначенные этому узлу, используют исключительно VPN-соединение.
  • Отсутствие утечек (например, DNS или другого трафика)
  • Если VPN отключается, весь трафик сбрасывается
  • Разрешить обнаружение сервисов и подключение к другим контейнерам в Swarm

Для DNS я добавил DNS вход в /etc/докер/daemon.json который использует DNS-серверы провайдера VPN, которые доступны только через VPN.

Вот правила iptable, которые я придумал:

iptables -I DOCKER-USER 1 -o tun0 -j ПРИНЯТЬ
iptables -I DOCKER-USER 2 -i tun0 -m conntrack --ctstate СВЯЗАННО, УСТАНОВЛЕНО -j ПРИНЯТЬ
iptables -I DOCKER-USER 3 -j DROP

Результирующий DOCKER-ПОЛЬЗОВАТЕЛЬ цепочка выглядит так:

Сеть DOCKER-USER (1 ссылка)
 pkts bytes target prot opt ​​in out source target
    0 0 ПРИНЯТЬ все -- * tun0 0.0.0.0/0 0.0.0.0/0
    0 0 ПРИНЯТЬ все -- tun0 * 0.0.0.0/0 0.0.0.0/0 ctstate СВЯЗАННО,УСТАНОВЛЕНО
    0 0 УДАЛИТЬ все -- * * 0.0.0.0/0 0.0.0.0/0

Из базовых тестов, таких как бег нслукап и завиток с включенным и выключенным VPN-соединением эти правила, похоже, работают, но у меня очень мало опыта работы с iptables. Это правильный способ сделать это?

183
0 + 0
Рейтинг:1
avatar Server
флаг fr
Cameron

IPtables является линейным и читает правила сверху вниз, пока не достигнет цели ACCEPT, REJECT или DROP, а затем прекращает чтение правил. В вашем случае вы хотите иметь iptables -I DOCKER-USER -j DROP как самое последнее правило в вашей цепочке, иначе каждый пакет будет отброшен. Кроме того, нет необходимости в правиле RETURN в конце, потому что IPtables перестанет читать правила, как только дойдет до правила DROP прямо над ним. Эти правила IPtables с tun0 выглядят нормально, но убедитесь, что у вас также есть эти правила:

iptables -t filter -I INPUT 1 -i tun0 -j DOCKER-USER
iptables -t filter -I ВЫВОД 2 -o tun0 -j DOCKER-USER

Для хорошей практики убедитесь, что вы принимаете весь петлевой трафик, который никогда не достигнет Интернета и не покинет машину:

iptables -t фильтр -I ВВОД 3 -i tun0 -j ПРИНЯТЬ

Давайте рассмотрим ваши требования один за другим:

  1. Любые службы, назначенные этому узлу, используют исключительно VPN-соединение.

Вы бы не использовали IPtables для этого. Запустите эти команды на серверах:

IP-маршрут добавить по умолчанию через ${LOCAL_VPN_IP}

Я думаю, что OpenVPN обычно использует 10.8.0.0/16, поэтому шлюз по умолчанию, вероятно, будет 10.8.0.1 или что-то в этом роде. IProute2 (команда ip) встроен в ядро, как и IPtables.

  1. Отсутствие утечек (например, DNS или другого трафика)

Сначала вы должны перенаправить весь трафик через VPN, поместив это в конфигурацию вашего сервера OpenVPN:

нажмите "перенаправление-шлюз автолокальный"

Это заставляет клиентов направлять весь свой трафик через VPN, даже DNS и тому подобное. Если сервер OpenVPN выйдет из строя, интернет перестанет работать на клиентах.

  1. Если VPN отключается, весь трафик сбрасывается

См. шаг 2

  1. Разрешить обнаружение сервисов и подключение к другим контейнерам в Swarm

Я считаю, что OpenVPN делает это по умолчанию. Я могу выполнить ping/arp от одного клиента к другим клиентам, которые находятся на сервере OpenVPN.Вы определенно должны иметь доступ к службам, которые есть на других клиентах.

Я надеюсь, что это отвечает на ваши вопросы!

0 + 0
флаг in
Matt Olan
Спасибо! Я отредактировал свой вопрос, чтобы быть более ясным. Вот несколько вопросов вдогонку... 1. Правила «INPUT 1» и «OUTPUT 2» направляют трафик через подцепочку DOCKER-USER. Требуются ли они, поскольку Docker автоматически управляет правилами в цепочке FORWARD? 2. В моих первоначальных правилах следует использовать RETURN, чтобы позволить ему пройти через другие подцепи FORWARD, или ACCEPT? 3. Является ли команда `ip route` избыточной? Разве весь трафик не будет перенаправляться через интерфейс tun0 независимо от правил iptables?
0
Ответить
флаг fr
Cameron
1. Да, вы также можете добавить `iptables -t filter -A FORWARD -j DOCKER-USER`. «INPUT» — для трафика, предназначенного для сервера, «OUTPUT» — для трафика, исходящего от сервера, а «FORWARD» — для трафика, который не исходит и не завершается на сервере. Другими словами, «ВПЕРЕД» — это то, что делает ваш маршрутизатор, когда ваш компьютер подключается к google.com. 2. `RETURN` бесполезен, если вы не находитесь в подцепочке и не хотите вернуться в цепочку на уровень выше. 3. `ip route` не является избыточным. `iptables` разрешает или запрещает пакеты, но не сообщает вашему серверу, куда отправлять пакеты. `ip route` делает.
1
Ответить
флаг in
Matt Olan
1. Итак, вы говорите, что я могу использовать `iptables -t filter -A FORWARD -j DOCKER-USER` вместо добавления упомянутых вами правил `INPUT` и `OUTPUT`? 2. «DOCKER-USER» — это управляемая Docker подцепочка «FORWARD», поэтому следует использовать «RETURN» для возврата к цепочке «FORWARD»? 3. Имеет смысл, мне нужно будет подробнее изучить это, поскольку мой текущий маршрут по умолчанию проходит через мой локальный IP-адрес.
0
Ответить
флаг fr
Cameron
1.`INPUT`, `OUTPUT` и `FORWARD` выполняют разные функции, поэтому вам нужно включить все 3, если вы хотите, чтобы весь ваш трафик управлялся через VPN. 2. Если `INPUT`, `OUTPUT` и `FORWARD` отправлены `DOCKER-USER`, цепочка `DOCKER-USER` управляет всем трафиком для всех 3 цепочек, то есть вам не нужно `RETURN ` что-либо в цепочку `FORWARD`, так как цепочка `FORWARD` будет обрабатываться по правилам `DOCKER-USER`.
1
Ответить
флаг in
Matt Olan
Объединив DOCKER-USER в подцепочки INPUT и OUTPUT, не будут ли эти правила применяться ко всему трафику, в том числе для хоста? Кажется, что это сбросит все на мой физический интерфейс eth0, включая подключение к самой VPN, так как это не соответствует правилам ACCEPT.
0
Ответить
флаг in
Matt Olan
Вот документы для Docker iptables в качестве справки. https://docs.docker.com/network/iptables/ Интересная строка: «Docker устанавливает две пользовательские цепочки iptables с именами DOCKER-USER и DOCKER и гарантирует, что входящие пакеты всегда сначала проверяются этими двумя цепочками».
0
Ответить
флаг fr
Cameron
Извините за поздний ответ, я был занят. Итак, я не знал, что Докер создал эти цепочки. Как говорится, вы правы. Насколько я понимаю, DOCKER-USER проверяет только «входящие пакеты». Итак, если вы хотите, чтобы исходящие пакеты проходили только через VPN, вы должны сделать что-то вроде `iptables -t filter -A OUTPUT -o tun0 -j ACCEPT`, а затем `iptables -t filtler -A OUTPUT! -o tun0 -j DROP` или вы также можете просто указать `iptables -t filter -A OUTPUT -j DROP` после правила ACCEPT.
1
Ответить
флаг in
Matt Olan
Спасибо за продолжение! Теперь все цепочки имеют смысл, я их реализую. Что касается IP-маршрута, похоже, что OpenVPN делает это автоматически во время запуска с помощью этих «добавления маршрута 0.0.0.0/1 через REMOVED» и «128.0.0.0/1 через REMOVED». К сожалению, я не смог проверить, установлен ли на сервере OpenVPN параметр «redirect-gateway autolocal». Вы знаете способ подтвердить это?
0
Ответить
флаг fr
Cameron
Вы должны добавить «push «redirect-gateway autolocal»» в файл конфигурации вашего сервера OpenVPN. Таким образом, это подтолкнет клиентов к перенаправлению всего их трафика. Но похоже, что в OpenVPN некоторые настройки должны быть включены по умолчанию. Эти команды маршрутизации должны перенаправлять весь трафик через VPN.
1
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.