Назад | Перейти на главную страницу

Как сделать контейнеры lxd доступными для локальной сети

Если я использую Virtualbox для запуска виртуальной машины, я могу выбрать «мостовой» в качестве типа сетевого адаптера, и это приведет к тому, что гостевой / виртуальный сетевой адаптер будет подключен к моей физической локальной сети и, следовательно, получит IP-адрес локальной сети от моего маршрутизатора (через DHCP).

Я хочу достичь той же функциональности, но вместо Virtualbox я хочу использовать контейнеры lxc / lxd.

Как я могу этого добиться?

Редактировать 1

Я использую Ubuntu и пробовал следовать этому руководству:

https://insights.ubuntu.com/2015/11/10/converting-eth0-to-br0-and-getting-all-your-lxc-or-lxd-onto-your-lan/

... но это не помогает. Должен ли исходный интерфейс хоста иметь впоследствии IP? Потому что этого не происходит, когда я пытаюсь установить мост вручную.

Редактировать 2

Если это поможет, мой хост lxd / lxc - это виртуальная машина Virtualbox под управлением Ubuntu, настроенная с использованием мостовой сети для моей физической сетевой карты Ethernet.

Редактировать 3

Если я использую tcpdump для мониторинга трафика icmp на интерфейсе моста, физическом / хостовом интерфейсе и контейнерном / виртуальном интерфейсе, только контейнер / виртуальный не получает никакого трафика. У двух других есть.

Редактировать 4

Согласно этому руководству:

http://www.microhowto.info/troubleshooting/troubleshooting_ethernet_bridging_on_linux.html

У меня нет проблем с настройкой моста.

Тем не менее, как упоминалось в «Редактировать 3», интерфейс контейнера не получает трафика. Нужно выяснить, почему, но я не знаю, как ...

Мне кажется, это как-то связано с маршрутами.

У контейнера нет маршрутов, а у хоста есть.

Редактировать 5

Использование tcpdump для мониторинга трафика ARP показывает, что трафик ARP действительно попадает в контейнер / виртуальный интерфейс.

Так что это просто трафик icmp, которого нет.

Редактировать 6

Если я устанавливаю статический IP-адрес в контейнере (через / etc / network / intefaces *), это позволяет мне пинговать контейнер с хоста (который является машиной Virtualbox).

Если я затем изменю конфигурацию сети в Virtualbox, чтобы разрешить беспорядочный трафик, я могу затем пропинговать контейнер с моей физической машины (хост машины Virtualbox). Тем не менее, отсюда я все еще не могу выполнить эхо-запрос за пределами своей физической локальной сети из контейнера.

Последний шаг, если я вручную добавлю маршрут «по умолчанию» в контейнер, например:

route add default gw 192.168.0.1 eth0

это позволяет мне пинговать за пределами физической LAN изнутри контейнера.

Поэтому, если кто-то другой не может предложить объяснение (я подожду, прежде чем опубликовать ответ), я предполагаю, что отсутствие поддержки DHCP в контейнерах (через мост) как-то связано с тем фактом, что lxc / lxd использует netmasq для обработки DHCP. (и DNS).

  1. Если ваш хост LXD на самом деле является виртуальной машиной, убедитесь, что сетевой адаптер виртуальной машины настроен на неразборчивый режим, чтобы трафик контейнера LXD передавался из физической в ​​виртуальную сеть.
  2. Установите статический IP-адрес в контейнере (ах) lxd, потому что DHCP (от вашего физического шлюза), похоже, не работает.

В своем 6-м редактировании я сказал, что мне нужно вручную добавить маршрут по умолчанию в контейнер, но это неправда. Мне нужно было это сделать только потому, что я забыл указать IP-адрес шлюза LAN в /etc/network/interfaces файл. Так что это не проблема LXD, просто не забудьте указать ее.

Вам необходимо создать интерфейс моста, одной из ветвей которого будет интерфейс вашей ОС хоста, а затем подключить к этому мосту контейнеры lxc - таким образом вы получите правильное мостовое соединение.

Часть конфигурации вашего контейнера будет выглядеть так:

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0

Хотя ваша конфигурация моста ОС будет фактически зависеть от дистрибутива.

Что вам в основном нужно, так это контейнеры для использования шлюза по умолчанию, который может перенаправлять трафик в остальную часть вашей сети, и статического маршрута на вашем маршрутизаторе, который может пересылать обратно в эту систему. Это может быть ваш хост lxd (используя IP-переадресация в Linux), или вы можете иметь специальный контейнер для обработки маршрутизации (возможно, запустить брандмауэр, чтобы ограничить доступ к IP / портам контейнера).

Если вы используете мост lxdbr0 по умолчанию и хотите изменить шлюз для контейнеров, вы можете использовать raw.dnsmasq настройки. Обычно для него устанавливается IP-адрес, который вы использовали для хоста lxd при настройке моста, но его можно изменить с помощью dhcp-option=3:

lxc network show lxdbr0
config:
  ipv4.address: 192.168.4.1/24
  ipv6.address: none
  raw.dnsmasq: dhcp-option=3,192.168.4.2
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/ubuntu-test
managed: true

Когда вы затем перезапустите контейнер, вы увидите новый шлюз, используя ip route show.

Как только контейнеры настроены на использование желаемого шлюза по умолчанию, убедитесь, что система настроена на пересылку IP-пакетов. На этом этапе ваши контейнеры должны иметь возможность пинговать другие IP-адреса на этом хосте, но не смогут достичь чего-либо еще в сети. Это связано с тем, что остальная часть сети не имеет маршрутной информации о том, как возвращать пакеты, предназначенные для подсети контейнера.

Если это домашняя сеть за маршрутизатором, вы можете добавить статический маршрут к домашнему маршрутизатору, чтобы сообщить ему, куда отправлять эти пакеты. Если ваш хост lxd использует статический IP-адрес 192.168.0.2, а ваши контейнеры используют подсеть 192.168.4.0/24, тогда вы должны добавить эту подсеть в качестве статического маршрута с IP-адресом хоста .2 в качестве шлюза. Это должно позволить маршрутизировать пакеты между вашими контейнерами и локальной сетью, используя ваш lxd-хост в качестве шлюза между двумя сетями.