Работа с контейнерами многим кажется волшебством, пришло время
разобраться как работает сеть контейнеров. Мы покажем на примерах,
что это совсем не сложно. Помните, что контейнеры - всего лишь
изолированные процессы Linux.
В этой статье мы ответим на следующие вопросы:
-
Как виртуализировать сетевые ресурсы, чтобы контейнеры думали,
что у каждого из них есть выделенный сетевой стек?
-
Как превратить контейнеры в дружелюбных соседей, не дать им
мешать друг другу и научить хорошо общаться?
-
Как настроить сетевой доступ из контейнера во внешний мир
(например, в Интернет)?
-
Как получить доступ к контейнерам, работающим на сервере, из
внешнего мира (публикация портов)?
Отвечая на эти вопросы, мы настроим сеть контейнеров с нуля,
используя стандартные инструменты Linux. В результате станет
очевидно, что сеть контейнеров - это не что иное, как простая
комбинация хорошо известных возможностей Linux:
-
Network namespaces
-
Virtual Ethernet devices (veth)
-
Virtual network switches (bridge)
-
IP маршрутизация и преобразование сетевых адресов (NAT)
Нам потребуется немного сетевой магии и никакого кода ...
С чего начать?
Все примеры в статье были сделаны на виртуальной машине CentOS
8. Но вы можете выбрать тот дистрибутив, который вам нравится.
Создадим виртуальную машину с помощью Vagrant и подключимся к
ней по SSH:
$ vagrant init centos/8$ vagrant up$ vagrant ssh[vagrant@localhost ~]$ uname -aLinux localhost.localdomain 4.18.0-147.3.1.el8_1.x86_64
Мы не будем использовать какое-либо популярное решение для
контейнеризации (например, docker или podman). Вместо этого мы
сосредоточимся на основных концепциях и воспользуемся минимальным
набором инструментов для достижения наших учебных целей.
Изоляция контейнеров с помощью Network namespaces
Что составляет сетевой стек Linux? Ну, очевидно, набор сетевых
устройств. Что еще? Набор правил маршрутизации. И не забываем про
настройку netfilter, создадим необходимые правила iptables.
Напишем небольшой скрипт inspect-net-stack.sh:
#!/usr/bin/env bashecho "> Network devices"ip linkecho -e "\n> Route table"ip routeecho -e "\n> Iptables rules"iptables --list-rules
Но прежде, чем запускать его, давайте внесём изменения в правила
iptables, чтобы идентифицировать их в дальнейшем:
$ sudo iptables -N ROOT_NS
Запускаем скрипт:
$ sudo ./inspect-net-stack.sh> Network devices1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff> Route tabledefault via 10.0.2.2 dev eth0 proto dhcp metric 10010.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100> Iptables rules-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT-N ROOT_NS
Обратите внимание на текущий результат работы скрипта, потому
что мы хотим быть уверены, что каждый из контейнеров, которые мы
собираемся создать в ближайшее время, получит отдельный сетевой
стек.
Мы уже упоминали об одном из Linux namespaces, используемых для
изоляции контейнеров, которое называет сетевое пространство имён
(Network namespace). Если заглянуть в man ip-netns, то
мы прочтём, что Network namespace логически является копией
сетевого стека со своими собственными маршрутами, правилами
брандмауэра и сетевыми устройствами. Мы не будем затрагивать другие
Linux namespaces в этой статье и ограничимся только областью
видимости сетевого стека.
Для создания Network namespace нам достаточно утилиты
ip, которая входим в популярный пакет
iproute2. Создадим новое сетевое пространство
имён:
$ sudo ip netns add netns0$ ip netnsnetns0
Новое сетевое пространство имён создано, но как начать его
использовать? Воспользуемся командой Linux под названием
nsenter. Она осуществляет вход в одно или несколько
указанных пространств имен, а затем выполняет в нём указанную
программу:
$ sudo nsenter --net=/var/run/netns/netns0 bash# The newly created bash process lives in netns0$ sudo ./inspect-net-stack.sh> Network devices1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00> Route table> Iptables rules-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT
Приведённый выше пример показывает, что процесс bash, работающий
внутри пространства имён netns0, видит совершенно
другой сетевой стек. Отсутствуют правила маршрутизации, и правила
iptables, есть только один loopback interface. Все идет по
плану...
Подключаем контейнер к хосту через virtual Ethernet devices
(veth)
Выделенный сетевой стек будет бесполезен, если к нему
отсутствует доступ. К счастью, Linux предоставляет подходящее
средство для этого - virtual Ethernet devices (veth)! Согласно man
veth, veth-device - это виртуальные устройства
Ethernet. Они работают как туннели между сетевыми пространствами
имён для создания моста к физическому сетевому устройству в другом
пространстве имён, а также могут использоваться как автономные
сетевые устройства.
Виртуальные Ethernet устройства всегда работают парами. Создадим
их прямо сейчас:
$ sudo ip link add veth0 type veth peer name ceth0
С помощью этой единственной команды мы только что создали пару
взаимосвязанных виртуальных Ethernet устройств. Имена
veth0 и ceth0 были выбраны
произвольно:
$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff5: ceth0@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff6: veth0@ceth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff
И veth0, и ceth0 после создания
находятся в сетевом стеке хоста (также называемом Root Network
namespace). Чтобы связать корневое пространство имён с
пространством имён netns0, нам нужно сохранить одно из
устройств в корневом пространстве имён и переместить другое в
netns0:
$ sudo ip link set ceth0 netns netns0# List all the devices to make sure one of them disappeared from the root stack$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff6: veth0@if5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff link-netns netns0
Как только мы включаем устройства и назначаем правильные
IP-адреса, любой пакет, происходящий на одном из них, немедленно
появляется на его одноранговом устройстве, соединяющем два
пространства имён. Начнем с корневого пространства имён:
$ sudo ip link set veth0 up$ sudo ip addr add 172.18.0.11/16 dev veth0
Продолжим сnetns0:
$ sudo nsenter --net=/var/run/netns/netns0$ ip link set lo up # whoops$ ip link set ceth0 up$ ip addr add 172.18.0.10/16 dev ceth0$ ip link1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:005: ceth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff link-netnsid 0
Проверяем подключение:
# From netns0, ping root's veth0$ ping -c 2 172.18.0.11PING 172.18.0.11 (172.18.0.11) 56(84) bytes of data.64 bytes from 172.18.0.11: icmp_seq=1 ttl=64 time=0.038 ms64 bytes from 172.18.0.11: icmp_seq=2 ttl=64 time=0.040 ms--- 172.18.0.11 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 58msrtt min/avg/max/mdev = 0.038/0.039/0.040/0.001 ms# Leave netns0$ exit# From root namespace, ping ceth0$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.073 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.046 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 3msrtt min/avg/max/mdev = 0.046/0.059/0.073/0.015 ms
Обратите внимание, если мы попытаемся проверить доступность
любых других адресов из пространства имен netns0, у нас ничего не
получится:
# Inside root namespace$ ip addr show dev eth02: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0 valid_lft 84057sec preferred_lft 84057sec inet6 fe80::5054:ff:fee3:2777/64 scope link valid_lft forever preferred_lft forever# Remember this 10.0.2.15$ sudo nsenter --net=/var/run/netns/netns0# Try host's eth0$ ping 10.0.2.15connect: Network is unreachable# Try something from the Internet$ ping 8.8.8.8connect: Network is unreachable
Для таких пакетов в таблице маршрутизации netns0
просто нет маршрута. В настоящий момент существует единственный
маршрут до сети 172.18.0.0/16:
# From netns0 namespace:$ ip route172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10
В Linux есть несколько способов заполнения таблицы
маршрутизации. Один из них - извлечение маршрутов из подключенных
напрямую сетевых интерфейсов. Помните, что таблица маршрутизации в
netns0 была пустой сразу после создания пространства
имен. Но затем мы добавили туда устройство ceth0 и
присвоили ему IP-адрес 172.18.0.10/16. Поскольку мы
использовали не простой IP-адрес, а комбинацию адреса и сетевой
маски, сетевому стеку удалось извлечь из него информацию о
маршрутизации. Каждый пакет, предназначенный для сети
172.18.0.0/16, будет отправлен через устройство
ceth0. Но все остальные пакеты будут отброшены. Точно
так же есть новый маршрут в корневом пространстве имен:
# From root namespace:$ ip route# ... omitted lines ...172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11
На этом этапе мы ответили на первый вопрос. Теперь мы
знаем, как изолировать, виртуализировать и подключать сетевые стеки
Linux.
Объединение контейнеров с помощью virtual network switch
(bridge)
Вся идея контейнеризации сводится к эффективному совместному
использованию ресурсов. То есть мы крайне редко запускаем на хосте
единственный контейнер. Вместо этого стараемся запустить как можно
больше изолированных процессов на одном хосте. Итак, чтобы
произошло, если бы мы разместили несколько контейнеров на одном
хосте, следуя описанному выше подходу? Добавим второй
контейнер:
# From root namespace$ sudo ip netns add netns1$ sudo ip link add veth1 type veth peer name ceth1$ sudo ip link set ceth1 netns netns1$ sudo ip link set veth1 up$ sudo ip addr add 172.18.0.21/16 dev veth1$ sudo nsenter --net=/var/run/netns/netns1$ ip link set lo up$ ip link set ceth1 up$ ip addr add 172.18.0.20/16 dev ceth1
Проверим доступность:
# From netns1 we cannot reach the root namespace!$ ping -c 2 172.18.0.21PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data.From 172.18.0.20 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.20 icmp_seq=2 Destination Host Unreachable--- 172.18.0.21 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 55mspipe 2# But there is a route!$ ip route172.18.0.0/16 dev ceth1 proto kernel scope link src 172.18.0.20# Leaving netns1$ exit# From root namespace we cannot reach the netns1$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 172.18.0.11 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.11 icmp_seq=2 Destination Host Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 23mspipe 2# From netns0 we CAN reach veth1$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 172.18.0.21PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data.64 bytes from 172.18.0.21: icmp_seq=1 ttl=64 time=0.037 ms64 bytes from 172.18.0.21: icmp_seq=2 ttl=64 time=0.046 ms--- 172.18.0.21 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 33msrtt min/avg/max/mdev = 0.037/0.041/0.046/0.007 ms# But we still cannot reach netns1$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 172.18.0.10 icmp_seq=1 Destination Host UnreachableFrom 172.18.0.10 icmp_seq=2 Destination Host Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 63mspipe 2
Что-то пошло не так... По какой-то причине мы не можем
подключиться из netns1 к root namespace.
А из root namespace мы не можем подключиться к netns1.
Однако, поскольку оба контейнера находятся в одной IP-сети
172.18.0.0/16, есть доступ к veth1 хоста
из контейнера netns0. Интересно...
Возможно, мы столкнулись с конфликтом маршрутов. Давайте
проверим таблицу маршрутизации в root namespace:
$ ip route# ... omitted lines ...172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21
После добавления второй пары veth в таблице
маршрутизации root namespace появился новый маршрут
172.18.0.0/16 dev veth1 proto kernel scope link src
172.18.0.21, но маршрут до этой подсети уже существовал!
Когда второй контейнер пытается проверить связь с устройством
veth1, используется первый маршрут и мы видим ошибку
подключения. Если бы мы удалили первый маршрут sudo ip route
delete 172.18.0.0/16 dev veth0 proto kernel scope link src
172.18.0.11 и перепроверили подключение, то увидели бы
обратную ситуацию, то есть подключение netns1 будет
восстановлено, но netns0 останется в подвешенном
состоянии.
Пожалуй, если бы мы выбрали другую подсеть для
netns1, все бы заработало. Однако наличие нескольких
контейнеров в одной подсети является допустимым вариантом
применения. Попробуем разобраться ...
Рассмотрим Linux Bridge - еще один виртуализированный сетевой
объект! Linux Bridge ведёт себя как коммутатор. Он пересылает
пакеты между подключенными к нему интерфейсами. А поскольку это
коммутатор, то он работает на уровне L2 (то есть Ethernet).
Чтобы предыдущие этапы нашего эксперимента в дальнейшем не
вносили путаницы, удалим существующие сетевые пространства
имён:
$ sudo ip netns delete netns0$ sudo ip netns delete netns1# But if you still have some leftovers...$ sudo ip link delete veth0$ sudo ip link delete ceth0$ sudo ip link delete veth1$ sudo ip link delete ceth1
Заново создаём два контейнера. Обратите внимание, мы не
назначаем IP-адреса новым устройствам veth0 и
veth1:
$ sudo ip netns add netns0$ sudo ip link add veth0 type veth peer name ceth0$ sudo ip link set veth0 up$ sudo ip link set ceth0 netns netns0$ sudo nsenter --net=/var/run/netns/netns0$ ip link set lo up$ ip link set ceth0 up$ ip addr add 172.18.0.10/16 dev ceth0$ exit$ sudo ip netns add netns1$ sudo ip link add veth1 type veth peer name ceth1$ sudo ip link set veth1 up$ sudo ip link set ceth1 netns netns1$ sudo nsenter --net=/var/run/netns/netns1$ ip link set lo up$ ip link set ceth1 up$ ip addr add 172.18.0.20/16 dev ceth1$ exit
Убедимся, что на хосте нет новых маршрутов:
$ ip routedefault via 10.0.2.2 dev eth0 proto dhcp metric 10010.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100
И, наконец, создадим bridge интерфейс:
$ sudo ip link add br0 type bridge$ sudo ip link set br0 up
Теперь подключим к нему veth0 и
veth1:
$ sudo ip link set veth0 master br0$ sudo ip link set veth1 master br0
... и проверим возможность подключения между контейнерами:
$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.259 ms64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.051 ms--- 172.18.0.20 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 0.051/0.155/0.259/0.104 ms
$ sudo nsenter --net=/var/run/netns/netns1$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.037 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.089 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 36msrtt min/avg/max/mdev = 0.037/0.063/0.089/0.026 ms
Прекрасно! Все отлично работает. При этом мы даже не настраивали
интерфейсы veth0 и veth1. Мы назначили
только два IP-адреса интерфейсам ceth0 и ceth1. Но поскольку они
оба находятся в одном сегменте Ethernet (подключены к виртуальному
коммутатору), существует возможность подключения на уровне L2:
$ sudo nsenter --net=/var/run/netns/netns0$ ip neigh172.18.0.20 dev ceth0 lladdr 6e:9c:ae:02:60:de STALE$ exit$ sudo nsenter --net=/var/run/netns/netns1$ ip neigh172.18.0.10 dev ceth1 lladdr 66:f3:8c:75:09:29 STALE$ exit
Поздравляем, мы узнали, как превратить контейнеры в
дружественных соседей, избежать проблем и сохранить сетевую
связность.
Настраиваем сетевой доступ из контейнера во внешний мир (IP
routing and masquerading)
Сейчас контейнеры могут подключаться друг к другу. Но будут ли
удачны подключения к хосту, то есть к корневому пространству
имён?
$ sudo nsenter --net=/var/run/netns/netns0$ ping 10.0.2.15 # eth0 addressconnect: Network is unreachable
Интерфейс eth0 не доступен. Всё очевидно, в netns0
отсутствует маршрут для этого подключения:
$ ip route172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10
Корневое пространство имён также не может взаимодействовать с
контейнерами:
# Use exit to leave netns0 first:$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.From 213.51.1.123 icmp_seq=1 Destination Net UnreachableFrom 213.51.1.123 icmp_seq=2 Destination Net Unreachable--- 172.18.0.10 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.From 213.51.1.123 icmp_seq=1 Destination Net UnreachableFrom 213.51.1.123 icmp_seq=2 Destination Net Unreachable--- 172.18.0.20 ping statistics ---2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms
Чтобы установить связь между корневым пространством имён и
пространством имён контейнера, нам нужно назначить IP-адрес
сетевому интерфейсу моста:
$ sudo ip addr add 172.18.0.1/16 dev br0
Теперь после того, как мы назначили IP-адрес интерфейсу моста,
мы получили маршрут в таблице маршрутизации хоста:
$ ip route# ... omitted lines ...172.18.0.0/16 dev br0 proto kernel scope link src 172.18.0.1$ ping -c 2 172.18.0.10PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data.64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.036 ms64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.049 ms--- 172.18.0.10 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 11msrtt min/avg/max/mdev = 0.036/0.042/0.049/0.009 ms$ ping -c 2 172.18.0.20PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data.64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.059 ms64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.056 ms--- 172.18.0.20 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 4msrtt min/avg/max/mdev = 0.056/0.057/0.059/0.007 ms
Контейнер, вероятно, также получил возможность пинговать
интерфейс моста, но они все ещё не могут связаться с хостом
eth0. Нам нужно добавить маршрут по умолчанию для
контейнеров:
$ sudo nsenter --net=/var/run/netns/netns0$ ip route add default via 172.18.0.1$ ping -c 2 10.0.2.15PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data.64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.036 ms64 bytes from 10.0.2.15: icmp_seq=2 ttl=64 time=0.053 ms--- 10.0.2.15 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 14msrtt min/avg/max/mdev = 0.036/0.044/0.053/0.010 ms# And repeat the change for netns1
Теперь наш хост является маршрутизатором, а интерфейс моста стал
шлюзом по умолчанию для контейнеров.
Отлично, нам удалось добиться сетевой связности контейнеров с
корневым пространством имён. Теперь давайте попробуем подключить их
к внешнему миру. По умолчанию переадресация пакетов (ip packet
forwarding), то есть функциональность маршрутизатора в Linux
отключена. Нам нужно её включить
# In the root namespacesudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
Теперь самое интересное - проверка подключения:
$ sudo nsenter --net=/var/run/netns/netns0$ ping 8.8.8.8# hangs indefinitely long for me...
Всё равно не работает. Мы что-то упустили? Если бы контейнер
отправлял пакеты во внешний мир, сервер-получатель не смог бы
отправлять пакеты обратно в контейнер, потому что IP-адрес
контейнера является частным и правила маршрутизации для этого
конкретного IP-адреса известны только в локальной сети. К тому же
многие контейнеры в мире имеют один и тот же частный IP-адрес
172.18.0.10. Решение этой проблемы называется
преобразованием сетевых адресов
(NAT). Принцип работы, следующий - перед отправкой во
внешнюю сеть пакеты, отправленные контейнерами, заменяют свои
исходные IP-адреса (source IP addesses) на адрес внешнего
интерфейса хоста. Хост также будет отслеживать все существующие
сопоставления (mapping) и по прибытии будет восстанавливать
IP-адреса перед пересылкой пакетов обратно в контейнеры. Звучит
сложно, но у меня для вас хорошие новости! Нам нужна всего одна
команда, чтобы добиться требуемого результата:
$ sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE
Команда довольно проста. Мы добавляем новое правило в таблицу
nat цепочки POSTROUTING с просьбой
выполнить MASQUERADE всех исходящих пакетов из сети
172.18.0.0/16, но не через интерфейс моста.
Проверьте подключение:
$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=43.2 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=36.8 ms--- 8.8.8.8 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 36.815/40.008/43.202/3.199 ms
$ sudo nsenter --net=/var/run/netns/netns0$ ping -c 2 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=43.2 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=36.8 ms--- 8.8.8.8 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 36.815/40.008/43.202/3.199 ms
Помните, что политика iptables по умолчанию -
ACCEPT для каждой цепочки, она может быть довольно
опасной в реальных условиях:
sudo iptables -S-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT
В качестве хорошего примера Docker вместо этого ограничивает все
по умолчанию, а затем разрешает только для известных маршрутов:
$ sudo iptables -t filter --list-rules-P INPUT ACCEPT-P FORWARD DROP-P OUTPUT ACCEPT-N DOCKER-N DOCKER-ISOLATION-STAGE-1-N DOCKER-ISOLATION-STAGE-2-N DOCKER-USER-A FORWARD -j DOCKER-USER-A FORWARD -j DOCKER-ISOLATION-STAGE-1-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT-A FORWARD -o docker0 -j DOCKER-A FORWARD -i docker0 ! -o docker0 -j ACCEPT-A FORWARD -i docker0 -o docker0 -j ACCEPT-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5000 -j ACCEPT-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2-A DOCKER-ISOLATION-STAGE-1 -j RETURN-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP-A DOCKER-ISOLATION-STAGE-2 -j RETURN-A DOCKER-USER -j RETURN$ sudo iptables -t nat --list-rules-P PREROUTING ACCEPT-P INPUT ACCEPT-P POSTROUTING ACCEPT-P OUTPUT ACCEPT-N DOCKER-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 5000 -j MASQUERADE-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER-A DOCKER -i docker0 -j RETURN-A DOCKER ! -i docker0 -p tcp -m tcp --dport 5005 -j DNAT --to-destination 172.17.0.2:5000$ sudo iptables -t mangle --list-rules-P PREROUTING ACCEPT-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT-P POSTROUTING ACCEPT$ sudo iptables -t raw --list-rules-P PREROUTING ACCEPT-P OUTPUT ACCEPT
Настроим сетевой доступ из внешнего мира в контейнеры (port
publishing)
Публикация портов контейнеров для некоторых (или всех)
интерфейсов хоста - популярная практика. Но что на самом деле
означает публикация порта?
Представьте, что у нас есть сервис, работающий внутри
контейнера:
$ sudo nsenter --net=/var/run/netns/netns0$ python3 -m http.server --bind 172.18.0.10 5000
Если мы попытаемся отправить HTTP-запрос этому сервису с хоста,
все будет работать (ну, есть связь между корневым пространством
имён и всеми интерфейсами контейнера, почему бы и нет?):
# From root namespace$ curl 172.18.0.10:5000<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"># ... omitted lines ...
Однако, если бы мы получили доступ к этому серверу из внешнего
мира, какой IP-адрес мы бы использовали? Единственный IP-адрес,
который мы можем знать, - это адрес внешнего интерфейса хоста
eth0:
$ curl 10.0.2.15:5000curl: (7) Failed to connect to 10.0.2.15 port 5000: Connection refused
Таким образом, нам нужно найти способ перенаправить все пакеты,
поступающие на порт 5000 интерфейса eth0 хоста, на
адрес172.18.0.10:5000. Или, другими словами, нам нужно
опубликовать порт 5000 контейнера на интерфейсе eth0
хоста.
# External trafficsudo iptables -t nat -A PREROUTING -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000# Local traffic (since it doesn't pass the PREROUTING chain)sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000
Кроме того, нам нужно включить
iptables intercepting traffic over bridged networks
(перехватывать трафик bridged
networks):
sudo modprobe br_netfilter
Время проверить!
curl 10.0.2.15:5000<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"># ... omitted lines ...
Разбираемся в работе Docker network drivers
Но что же вам сделать теперь со всеми этими бесполезными
знаниями? Например, мы могли бы попытаться разобраться в некоторых
сетевых режимах Docker!
Начнем с режима --network host. Попробуйте сравнить
вывод следующих команд ip link и sudo docker run
-it --rm --network host alpine ip link. Сюрприз, они
совпадут! Таким образом host mode Docker
просто не использует изоляцию сетевого пространства имён и
контейнеры работают в корневом сетевом пространстве имён и
совместно используют сетевой стек с хост-системой.
Следующий режим, который нужно проверить, - это --network
none. Вывод команды sudo docker run -it --rm --network
none alpine ip link показывает только один сетевой интерфейс
обратной loopback. Это очень похоже на наши наблюдения за только
что созданным сетевым пространством имен. То есть до того момента,
когда мы добавляли какие-либо veth устройства.
И последнее, но не менее важное: режим --network
bridge (по умолчанию), это именно то, что мы пытались
воспроизвести в этой статье.
Сети и rootless контейнеры
Одной из приятных особенностей диспетчера контейнеров
podman является его ориентация на rootless контейнеры.
Однако, как вы, вероятно, заметили, в этой статье мы использовали
много эскалаций sudo и без root-прав настроить сеть невозможно. При
настройке сетей rootful контейнеров
Podman очень близок к Docker. Но когда дело доходит до
rootless контейнеров, Podman полагается на проект
slirp4netns:
Начиная с Linux 3.8, непривилегированные пользователи могут
создавать network_namespaces (7) вместе с user_namespaces (7).
Однако непривилегированные сетевые пространства имен оказались не
очень полезными, потому что для создания пар veth (4) в
пространствах имен хоста и сети по-прежнему требуются привилегии
root (иначе доступ в Интернету будет отсутствовать).
slirp4netns позволяет получить доступ из сетевое пространства
имен в Интернет непривилегированным пользователям, подключая
устройство TAP в сетевом пространстве имен к стеку TCP/IP usermode
(slirp).
Сеть rootless контейнера
весьма ограничена: технически сам контейнер не имеет
IP-адреса, потому что без привилегий root невозможно настроить
сетевое устройство. Более того, проверка связи (ping) из rootless
контейнера не работает, поскольку в нем отсутствует функция
безопасности CAP_NET_RAW, которая необходима для работы команды
ping.
Заключение
Рассмотренный в этой статье подход к организации сети
контейнеров является лишь одним из возможных (ну, пожалуй, наиболее
широко используемым). Есть еще много других способов, реализованных
через официальные или сторонние плагины, но все они сильно зависят
от
средств
виртуализации сети Linux. Таким образом, контейнеризацию
по праву можно рассматривать как технологию виртуализации.
19.04.2021 20:16:49 |
Автор: 
Категории: 
