Как стать автором
Обновить

Комментарии 6

Интересная статья. А как такой функционал применяться в деле?

Один из вариантов использования, описанный в статье, это сетевая изоляция процессов) Решать, кто может им отправлять пакеты, и кому они могут.

Построение сложных локальный виртуальных инфраструктур. Не только на контейнерах но и на полноценных виртуальных машинах.

Позволяет локально сэмулировать сложную инфраструктуру. Можно для опытов. Можно для обкатки каких-то решений. Можно а качестве тестовой среды. Можно в качестве дополнительного уровня сетевой безопасности и гарантии от случайного объединения сетевых сервисов.

Ну, и можно применять для изолирования сетевых сервисов, если по какой-то причине не хочется делать физическую инфраструктуру. Например, так можно сделать внешний интерфейс, DMZ зону и внутренние сервисы на одной физической машине и при этом сохранить очень хороший уровень изолированности и безопасности даже в случае каких-то ошибок конфигурации. Например в если нужно как-то хитро объединить удаленные офисы и сервисы в одной физической машины и при этом как-то гарантировать безопасность и изолированность. То есть у вас удаленные сотрудники, есть удаленные офисы, отдельная сеть бухгалтерских сервисов, какие-то сети, куда куда вообще никого пускать нельзя, и есть какие-то базовые сервисы, которые где-то жены брать доступны, а где-то нет. И по какой-то причине вы всю эту красоту хотите реализовать на одном компьютере. Можно на обычной маршрутизации всё это сконфигурировать и через firewall огородить, но велики риски, что из-за неправильной конфигурации или в случае, если в какой-то момент инициализация настроек пойдёт неправильно, какой-то сервис окажется доступен на всех интерфейсах или ещё что-то такое. А если неймспейсы и виртуальные бриджи прикрутить, то степень изоляции будет такой, что однажды сконфигурированное оно потом ни при каких реальных ошибках никаким образом не соединиться - примерно как если бы это была реальная физическая сетевая инфраструктура и несколько хостов. Странная будет конфигурация, но надёжная.

net.ipv4.conf..route_localnet – route_localnet=1 в каких случаях используют?

Если необходимо чтобы 192.168.0.15:79 не мог стучаться по tcp до 192.168.0.15:80-8080 куда надо рыть?(речь о серверах запущенных в докере)

Просто сервера могут стучаться друг до друга, если захочу закрыть возможность им стучаться до друг друга куда рыть надо?

Сервера запускаются в докере под NAT.

route_localnet=1 разрешает маршрутизацию пакетов, адресованных loopback интерфейсу (127.0.0.0/8). Например, в статье это используется для того, чтобы была возможность перенаправлять пакеты с 127.0.0.1:8000 на 10.100.0.2:8000.

iptables -t nat -A OUTPUT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 8000 -j DNAT --to-destination 10.100.0.2:8000

По поводу запрета стучаться одним контейнерам в другие. Во-первых, нужно убедиться, что они находятся в разных docker сетях. Во-вторых, добавить правила в firewall, запрещающие получение пакетов на хосте с bridge интерфейса (или со всех адресов подсети этого интерфейса) нужной вам докер сети по портам 80-8080. Пример:

iptables -I INPUT -s 172.29.0.0/16 -m tcp -p tcp --dport 80:8080 -j DROP

UPD: так как контейнеры за NAT, достаточно указать адрес маршрутизатора, то-есть адрес их bridge интерфейса. Обновлённый пример:

iptables -I INPUT -s 172.29.0.1 -m tcp -p tcp --dport 80:8080 -j DROP

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации