Comments 6
Интересная статья. А как такой функционал применяться в деле?
Один из вариантов использования, описанный в статье, это сетевая изоляция процессов) Решать, кто может им отправлять пакеты, и кому они могут.
Построение сложных локальный виртуальных инфраструктур. Не только на контейнерах но и на полноценных виртуальных машинах.
Позволяет локально сэмулировать сложную инфраструктуру. Можно для опытов. Можно для обкатки каких-то решений. Можно а качестве тестовой среды. Можно в качестве дополнительного уровня сетевой безопасности и гарантии от случайного объединения сетевых сервисов.
Ну, и можно применять для изолирования сетевых сервисов, если по какой-то причине не хочется делать физическую инфраструктуру. Например, так можно сделать внешний интерфейс, DMZ зону и внутренние сервисы на одной физической машине и при этом сохранить очень хороший уровень изолированности и безопасности даже в случае каких-то ошибок конфигурации. Например в если нужно как-то хитро объединить удаленные офисы и сервисы в одной физической машины и при этом как-то гарантировать безопасность и изолированность. То есть у вас удаленные сотрудники, есть удаленные офисы, отдельная сеть бухгалтерских сервисов, какие-то сети, куда куда вообще никого пускать нельзя, и есть какие-то базовые сервисы, которые где-то жены брать доступны, а где-то нет. И по какой-то причине вы всю эту красоту хотите реализовать на одном компьютере. Можно на обычной маршрутизации всё это сконфигурировать и через firewall огородить, но велики риски, что из-за неправильной конфигурации или в случае, если в какой-то момент инициализация настроек пойдёт неправильно, какой-то сервис окажется доступен на всех интерфейсах или ещё что-то такое. А если неймспейсы и виртуальные бриджи прикрутить, то степень изоляции будет такой, что однажды сконфигурированное оно потом ни при каких реальных ошибках никаким образом не соединиться - примерно как если бы это была реальная физическая сетевая инфраструктура и несколько хостов. Странная будет конфигурация, но надёжная.
Спасибо за столь развернутый ответ )
Можно еще добавить про SDN https://community.fs.com/ru/article/what-is-software-defined-networking-sdn.html
P.s. Кстати, SDN уже есть в Proxmox VE.
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
Создаём виртуальную сеть, как это делает Docker