Почему firewalld разрешает общедоступный трафик на мои частные порты, привязанные к контейнерам Docker?

Я пытаюсь реализовать довольно простой брандмауэр в Fedora, где общедоступный Интернет может получить доступ к SSH, HTTP, HTTPS и Cockpit, но больше ничего. Между тем, серверы запускают микросервисы через Docker, которые могут общаться друг с другом через порты 8000-8999.

Я настроил это на новой установке Fedora Server с помощью следующих команд:

брандмауэр-cmd --zone=public --add-service=cockpit
брандмауэр-cmd --zone=public --add-service=http
брандмауэр-cmd --zone=public --add-service=https

брандмауэр-cmd --zone=internal --add-source=192.168.1.65
брандмауэр-cmd --zone=internal --add-source=192.168.1.66

брандмауэр-cmd --zone=internal --add-port=8000-8999/tcp

firewall-cmd --runtime-to-permanent

Когда я проверяю свою конфигурацию с помощью --список-все, вроде все правильно:

> firewall-cmd --list-all --zone=internal
внутренний (активный)
  цель: по умолчанию
  icmp-инверсия блока: нет
  интерфейсы:
  источники: 192.168.1.65 192.168.1.66
  службы: dhcpv6-клиент ssh
  порты: 8000-8999/tcp
  протоколы:
  вперед: нет
  маскарад: нет
  форвард-порты:
  исходные порты:
  icmp-блоки:
  богатые правила:

> firewall-cmd --list-all --zone=public
публичный (активный)
  цель: по умолчанию
  icmp-инверсия блока: нет
  интерфейсы: enp2s0
  источники:
  сервисы: кабина dhcpv6-клиент http https ssh
  порты:
  протоколы:
  вперед: нет
  маскарад: нет
  форвард-порты:
  исходные порты:
  icmp-блоки:
  богатые правила:

Однако, когда я проверяю это, я могу ударить http://192.168.1.65:8080. Я могу попасть с машины в той же внутренней сети (192.168.128.128), а также публичный запрос с внешней машины. Поскольку ни один из них не был указан в внутреннийх источники, я предполагал, что firewalld не пропустит запросы.

у меня автоматическая настройка докер зона с докер0 интерфейс, но удаление этого, похоже, не меняет мою способность обращаться к внутреннему порту.

Почему я могу успешно запросить :8080 из источников, не указанных в внутренний?

Что ж, получается, что проблема связана с тем, что я использую Docker для своих внутренних портов. Чтобы упростить процесс взаимодействия контейнеров с миром и друг с другом, Docker принял решение взять на себя большой контроль над вашими брандмауэрами/сетями. Это означает, что если вы не хотите, чтобы ваши контейнеры были общедоступными И вам нужно контролировать общий доступ через брандмауэр на том же компьютере, что и ваш демон Docker, вам нужно настроить свои брандмауэры немного по-другому. У Docker есть официальная документация о том, как это сделать.. В принципе, у вас есть следующие варианты:

• Настройте отдельную машину только для вашего брандмауэра. Это, вероятно, было бы самым простым, поскольку Docker и ваш брандмауэр не должны были бы совместно использовать ресурсы.
• Добавьте свой iptables правила к DOCKER-ПОЛЬЗОВАТЕЛЬ цепь (это скорее ответ для iptables пользователи; я не уверен, как получить брандмауэр повторить этот подход)
• Отключите все это, установив iptables=ложь в конфигурации службы Docker. (этот пост в блоге обсуждаем этот вариант)

Я также нашел сообщение что я подумал, было хорошей вариацией на тему DOCKER-ПОЛЬЗОВАТЕЛЬ цепной вариант. По сути, вы создаете iptables.conf файл, который вы можете загрузить без флеша, используя iptables-восстановить -n. К сожалению, это iptables решение, а не брандмауэр решение.

Одна из сложных частей диагностики этой проблемы заключалась в том, что я запускал сценарий для изменения брандмауэра в соответствии с тем, что мне нужно, и это работало до тех пор, пока я не перезапускал машину или не запускал демон Docker. Докер перезаписывает iptables config при запуске.