Почти разобрался с lxc.net.0.veth.mode = router, но есть вопрос к sysctl proxy_arp=1

но без IP в конфиге он просто не запускается с ошибкой сети.

Наглый гон! Всю жизнь работало и сейчас работает

lxc-4.0.5

lxc.uts.name = c2
lxc.net.1.type = veth
lxc.net.1.flags = up
lxc.net.1.mtu  = 1500
lxc.net.1.name = eth0
lxc.net.1.veth.pair=c2.eth0
lxc.net.1.hwaddr = 00:01:43:49:79:bf
lxc.net.1.local.hwaddr = 00:01:43:49:79:0f

То, что нет девайса указанного в veth.pair пока не запущен контейнер - да, есть такое. А какие проблемы?

через скрипты lxc.net.X.script.{up,down} они не решаются?

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

А какие проблемы?

Эмм…Никаких, кроме той, что пинг идёт из контейнера только до хоста. А дальше не идёт, потому что proxy_arp на veth не настроено, потому что когда его настраивали контейнер не был запущен и veth’а не было.

Хочешь со стороны хоста постоянный интерфейс - сделай отдельный мост.

Я без документации люблюсь две недели с режимом router, чтобы поднять мост?

Кстати, в твоей конфе я не вижу lxc.net.1.veth.mode = router. Или lxc.net.1.link к мосту не вижу. Через какой физический интерфейс c2.eth0 выходит? А… «Все прекрасно запускается.» А пингуется из сети по адресам локалки? У меня lxc.net.0.ipv4.address = 10.10.10.234/24 не сеть контейнеров, 10.10.10.0/24 это моя локалка.

через скрипты lxc.net.X.script.{up,down} они не решаются?

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

Или подождать документацию, режим router появился в июле 2019-го, LXC 3.2.1, должны уже скоро закончить, я думаю…

PS Я возможно плохо донёс свою мысль, мне нужны контейнеры с IP локалки, без моста, используя режим «router», появившийся два года назад в LXC 3.2.1.

С up скриптом всё работает. Но это не нормально. Кмк lxc.net.0.l2proxy = 1 должен включать net.ipv4.conf.test4veth.proxy_arp=1. Мне всё равно каким костылём, хоть как я sysctl пускай запускает, лишь бы я этой хрени не видел. Тем более абсолютный путь в скрипте с фиксированным именем контейнера это дичь. В default.conf такое не засунешь, а lxc при этом может подставлять имя запускаемого контейнера, но хрен.

Нахрена тебе «lxc.net.0.l2proxy = 1» в режиме router ? Ты же хочешь роутить.

veth - это p2p прикидывающаяся сетью. Нафига на ней proxy_arp если это отдельная сеть?

Кстати, в твоей конфе я не вижу lxc.net.1.veth.mode = router. Или lxc.net.1.link к мосту не вижу. Через какой физический интерфейс c2.eth0 выходит? А… «Все прекрасно запускается.» А пингуется из сети по адресам локалки?

Если нет lxc.net.Х.link то veth.mode = router. Я пока не понял необходимости настройки veth.mode

c2.eth0 - это интерфейс для связи с контейнером.

Все нормально пингуется если есть маршрут в эту подсеть или используется NAT.

Часть путей есть в виде переменных окружения типа ${LXC_ROOTFS_MOUNT} ${LXC_ROOTFS_PATH}

Нахрена тебе «lxc.net.0.l2proxy = 1» в режиме router ?

Я человек простой, вижу конфиг - сразу пихаю себе.

LXC 3.2.1 has been released https://discuss.linuxcontainers.org/t/lxc-3-2-1-has-been-released/5322 Networking: Add router veth mode

lxc.net.0.type = veth
lxc.net.0.veth.mode = router
lxc.net.0.link = eth0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 192.168.1.x/32
lxc.net.0.ipv6.address = 2a02:xxx:xxx:1::x/128
lxc.net.0.ipv4.gateway = auto
lxc.net.0.ipv6.gateway = auto
lxc.net.0.link = host-eth0
lxc.net.0.l2proxy = 1

Я правда не читал ни разу, что там снизу написано, торопился очень, «поехали, потом заведёшся».

Containers can optionally have IPs accessible on local LAN at layer 2 using the existing l2proxy and link settings.

Если нет lxc.net.Х.link то veth.mode = router

Неть.

veth: a virtual ethernet pair device is created with one side assigned to the container and the other side on the host. lxc.net.[i].veth.mode specifies the mode the veth parent will use on the host. The accepted modes are bridge and router. The mode defaults to bridge if not specified.

https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html

Все нормально пингуется если есть маршрут в эту подсеть или используется NAT.

Если? В режиме router маршрут рисуется автоматом при запуске контейнера.

~ ip route
default via 10.10.10.2 dev eth0
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.10
10.10.10.234 dev test4veth scope link

veth - это p2p прикидывающаяся сетью

Тут нихрена не понял, не надо меня путать, я сам запутаюсь, с моими-то познаниями. veth это интерфейс, а не сеть. При чём тут одноранговая сеть p2p не понял. Для общения с контейнером нам надо или мост veth<->host_eth0 или veth должен уметь быть интерфейсом (mode=router?). Вот эта цитата мне не понятна:

Additionally Proxy ARP and Proxy NDP entries are added on the host side veth interface for the gateway IPs defined in the container to allow the container to reach the host.

И как я своим умишком понимаю без layer 2 и forward ничего работать не будет.

Controls whether layer 2 IP neighbour proxy entries will be added to the lxc.net.[i].link interface for the IP addresses of the container. Can be set to 0 or 1. Defaults to 0. When used with IPv4 addresses, the following sysctl values need to be set: net.ipv4.conf.[link].forwarding=1

Это то из чего я строю свои выводы. И это даже работает.

Информация - мои заключения - мой конфиг - работает - похоже lxc баг забывает включать proxy_arp.

Информация - твои заключения - «Если нет lxc.net.Х.link то veth.mode = router» - «The mode defaults to bridge if not specified.» - не должно работать в режиме router.

У veth не может быть режима router/bridge.

veth - труба. У него 2 конца. Но прикидывается при этом классической сетью. так что внутри контейнера можно использовать не один, а несколько адресов.

Я для таких контейнеров выделяю отдельную сеть, которая по адресам не пересекается со всеми имеющимися в сети.

Анонсирую маршрут в эту сеть, после чего - честно маршрутизирую пакеты.

Если не анонсировать маршрут в сеть, то нужно озаботиться NAT-ом.

Ты хочешь выдать 1 адрес из локалки контейнеру, но не делать при этом мост.

Да это можно, но нафига?

Тебе трафик нужно фильровать? Дык он и в мосте замечательно фильтруется средствами iptables/nftables.

Зачем себе усложнять жизнь? Там дальше начинаются хитрости и грабли с proxy_arp, arp_filter, arp_accetp, arp_ignore, rp_filter.

Да, в таком режиме со стороны хоста на veth не нужен ip-адрес, т.к. машина уже подключена в сеть.

Выдача контейнеру адреса через DHCP внутри контейнера в такой конфигурации невозможна, т.к. lxc должен знать на какой адрес отвечать через arp и какой машрут прописывать на хосте.

Если? В режиме router маршрут рисуется автоматом при запуске контейнера.

Он создает только прямой маршрут. Дальше нужно обеспечить работу arp, иначе контейнер не сможет подключиться к другим машинам сети.

Остальным машинам сети для ответа/передаче данных контейнеру тоже нужен его mac-адрес, но т.к. контейнер маршрутизируется, то arp-броадкасты он не получит и чтобы эта конструкция заработала нужно, чтоб хост отвечал на аrp-запросы к адресу контейнера своим mac-адресом (это и есть proxy_arp).

Городить такой огород можно только для изучения ip.

Если veth.mode=router + l2proxy=1 умеет делать это сама, то хорошо.

Ты хочешь выдать 1 адрес из локалки контейнеру, но не делать при этом мост.

Да это можно, но нафига?

Чтобы было как в Virtual Box. Он же может привязать виртуалку к физическому интерфейсу. Я хочу, чтобы никто не догадался, что seafile, xeoma, samba, observer и syncthing контейнеры, а не физические машины.

Зачем себе усложнять жизнь?

Усложнять себе жизнь - это пытаться выставить «наружу», в локалку, изолированные вещи. Маршруты, iptables. Но есть возможность сделать это без геморроя, почему не использовать?

Если veth.mode=router + l2proxy=1 умеет делать это сама, то хорошо.

Ну по логике должно уметь, у нас есть link, l2proxy и mode=router, давай, лепи, мне пофиг что там внутри будет наворочено, я хочу как в VBox. А хрен, не работает искаропки.

Надо нырять глубже, рисовать картинку с уровнями 2-3 osi. Я думал херак и в продакшн. Не взлетело. Ну как не взлетело, работает даже, а я не знаю почему. Знаний не хватает. Надо всё по полочкам разложить.

Чтобы было как в Virtual Box. Он же может привязать виртуалку к физическому интерфейсу. Я хочу, чтобы никто не догадался, что seafile, xeoma, samba, observer и syncthing контейнеры, а не физические машины.

c proxy_arp соседи догадаются по одинаковым мас-адресам :)

Надо нырять глубже, рисовать картинку с уровнями 2-3 osi. Я думал херак и в продакшн. Не взлетело. Ну как не взлетело, работает даже, а я не знаю почему. Знаний не хватает. Надо всё по полочкам разложить.

Вот именно. Нарисуй картинку. Поймешь, что твоя хотелка подходит только в случае одного контейнера и нежелания подключать хост через мост.

А если у тебя есть сеть c vlan, то поймешь, что стандартный мост нужно выбросить и поставить openvswitch :)