LXC bridge interface (VirtualBox Fedora)

Fórumok

Üdv,

Próbálom az LXC-hez a bridge interfészt létrehozni, beállítani (VirtualBox-ban). Az AI sem tudott eddig segíteni. :)
* Fizikai gép (laptop):

  • 192.168.1.103/24
  • átjáró: 192.168.1.254

* VirtualBox (mint hosztgép) Bridge-elt kártyával, Fedora Server:

  • enp0s3: 192.168.1.104/24
  • átjáró: 192.168.1.254
  • br0: 192.168.1.223/24
  • LXC konténer:
    • 192.168.1.225/24
    • átjáró: 192.168.1.254

 

# VBox Fedora Server mint hoszt gép ---------------------------------------------------
# br0 létrehozása:
sudo nmcli connection add type bridge con-name br0 ifname br0
sudo nmcli connection modify br0 ipv4.addresses 192.168.1.223/24 ipv4.method manual
sudo nmcli connection add type bridge-slave ifname enp0s3 master br0
sudo nmcli connection up enp0s3
sudo nmcli connection up br0

# install lxc
sudo dnf install -y lxc lxc-templates libvirt-daemon libvirt-daemon-driver-lxc bridge-utils

# ~# sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 1


# ip a
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:86:56:b8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.104/24 brd 192.168.1.255 scope global noprefixroute enp0s3
       valid_lft forever preferred_lft forever
    inet6 2001:4c4d:1146:9500:64b:5d14:7ba7:e2f1/64 scope global dynamic noprefixroute 
       valid_lft 2966sec preferred_lft 2965sec
    inet6 fe80::7bfd:5f52:eb17:4f11/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:84:e8:cd:91:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.223/24 brd 192.168.1.255 scope global noprefixroute br0
       valid_lft forever preferred_lft forever
    inet6 2001:4c4d:1146:9500:795b:eb59:4c3a:c75d/64 scope global dynamic noprefixroute 
       valid_lft 1164sec preferred_lft 1164sec
    inet6 fe80::e70d:5754:b2a4:9f76/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: vethBhlKp0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:84:e8:cd:91:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0

# ip r
default via 192.168.1.254 dev enp0s3 proto static metric 100 
default via 192.168.1.254 dev br0 proto static metric 425 
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.104 metric 100 
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.223 metric 425

# ------------------------------------------------------------------------------------
# LXC fedora konténer config:
# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = x86_64
# Container specific configuration
lxc.rootfs.path = dir:/var/lib/lxc/fedora/rootfs
lxc.uts.name = fedora
# Network configuration
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 192.168.1.225/24
lxc.net.0.ipv4.gateway = 192.168.1.254
lxc.net.0.hwaddr = 00:16:3e:5c:31:f8

# ip a
2: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:5c:31:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.225/24 brd 0.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe5c:31f8/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

# ip r
default via 192.168.1.254 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.225

 

A konténer nem lát ki:

~# ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
From 192.168.1.225 icmp_seq=1 Destination Host Unreachable

Mit rontok el?

Hozzászólások

Pedig ennek így jónak kéne lennie hálózatilag, úgy nézem. Próbáld meg a köztes állomásokat végigpingetni, illetve mivel Fedora a host, nézd meg, hogy esetleg a FirewallD nem kavar-e be valamit, én le szoktam tiltani ilyenkor amíg hibakeresek. Illetve, nem tudom mi a VBox alatti hostod, de ott is megnézném, hogy van-e tűzfal, nem fog-e meg valamit.

Ami még eszembe jut, hogy pingesd a köztes állomásokat is (VBox VM IP, fizikai gép IP), ne csak a 254-et, illetve tcpdump-pal nézd a VBox illetve a fiizkai hoston is a forgalmat, valaminek ki kell arrafele mennie.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

# ip r
default via 192.168.1.254 dev enp0s3 proto static metric 100 
default via 192.168.1.254 dev br0 proto static metric 425 

Mi alapján van eldöntve mikor melyik a gw ??

ebből kifolyólag, 2 interface (enp0s3 és br0) is ugyanabban a networkben van, ez se szerencsés alapesetben ...

Fedora 41, Thinkpad x280

Host OS: VirtualBox alatt a GUI-val (GUI hiányában CLI-ből) létrehozható szépen a bridge interface. Host gépen nem bántanám nmcli-vel a dolgokat, mert akkor egy csomó mindent kézzel kell állítgatni (ipv4_forward etc).

Virtualboxban futó OS-en: A VM-nek egy darab hálókártyája van, IP/alapértelmezett átjáró nem kell neki, mert azt a bridge interface fogja megkapni miután össze lesz rakva a bridge. A bridge interface-t hozzákell konfigurálni az LXC-hez.

https://fedoraproject.org/wiki/LXC

Utána mehet a konténer a doksiban leírtak szerint.

Hibakeresés host felől az LXC konténerig ping paranccsal pl.

Az első kérdésem, hogy mennyire szerencsés az, hogy egy bridge esetén a bridge-member saját IP címmel rendelkezik? Pláne ugyanabban a network-ben,mint amiben a master interface is van...
A másik kérdésem, hogy az ip_forwarding miért kerül ebben az esetben bekapcsolásra? A bridge a bridge-memberek közötti forwardot intézi, mi több, nem IPv4 szinten, hanem alacsonyabb szinten, így megy át pl az IPX is két bridge-member között. (Ez a security miatt egy jó ideje megváltozott és ilyen esetben is feladódik a csomag a kernel felé, de alapvetően tűzfal alapú szűrés miatt. Ebben az esetben ilyet nem látok.)
A harmadik kérdésem: mit mond a tcpdump? Milyen forgalmat lát?
A negyedik kérdésem: az lxc konténerhez létre hozott virtuális interface merre lakik és mikor kerül be a bridge-be?
 

Megjegyzés: alapvetően csak ötletelek a segítés szándékával, lehet, hogy a virtualbox pár dolgot máshogy csinál - de egy tcpdump kimenet sose haszontalan. :-)

Szerkesztve: 2025. 03. 10., h – 22:04

Korrigáltam 1-2 dolgot, köszönöm:

nmcli connection add type bridge autoconnect yes con-name br0 ifname br0
nmcli connection modify br0 ipv4.addresses 192.168.1.223/24 ipv4.method manual
nmcli connection modify br0 ipv4.gateway 192.168.1.254
nmcli connection modify br0 ipv4.dns 8.8.8.8
nmcli connection modify br0 ipv4.dns-search t.hu
nmcli connection del enp0s3
nmcli connection add type bridge-slave autoconnect yes con-name enp1s0 ifname enp0s3 master br0
sudo nmcli connection up br0

Konténer konfig:

# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = x86_64
# Container specific configuration
lxc.rootfs.path = dir:/var/lib/lxc/fedora/rootfs
lxc.uts.name = fedora
# Network configuration
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 192.168.1.225/24
lxc.net.0.ipv4.gateway = 192.168.1.223
lxc.net.0.hwaddr = 00:16:3e:5c:31:f8

A konténer megy: ping 8.8.8.8 ... OK
De weben nem lát ki, se a curl, se a dnf

Hoszton:

firewall-cmd --zone=FedoraServer --list-all
FedoraServer (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: br0 enp0s3
  sources: 
  services: cockpit dhcpv6-client dns http https ssh
  ports: 80/tcp 443/tcp
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Milyen zónába célszerű tenni a br0-t? Nem is igazán engedi kivenni. Hiába engedem a http,https,dns forgalmat.

A konténerben a curl google.com és a dnf install <akarmi> csak várakozik....

[root@fedora /]# nslookup google.com
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.39.14
Name:   google.com
Address: 2a00:1450:400d:807::200e

[root@fedora /]# curl google.com
curl: (6) Could not resolve host: google.com

:o

Elsőként azt kell eldöntened, hogy akarod-e az alapgépen szűrni a konténer forgalmát. Ha nem, akkor valami ilyesmi kell:
echo "0" > /proc/sys/net/bridge/bridge-nf-call-iptables
Ekkor a bridge-member-ek közötti forgalom nem kerül feladásra a kernelnek, hanem ami bejött az egyik porton, az kiment a másikon és annyi.
Ha ezt nem akarod, akkor ahogy te is látod, engedélyezni kell a forgalmat tűzfal szinten. Az icmp alapértelmezetten engedve szokott lenni - ezért megy a ping -, a többi nem, ezért nem egy a http forgalom. A DNS már érdekesebb, mert ha az nslookup sikeresen lekérdezett egy nevet, akkor hogy ugyanott egy curl azon áll fejre, hogy nem tudja ugyanazt a nevet feloldani, azért minimum érdekes. Ami a lényeg: a konténer IP-t célszerű felvenni a LAN zónába. Mondjuk a firewalld-t kevésbé ismerem, illetve ahogy látom, interface alapokon a FedoraServer zónába felvetted és adtál engedélyt a szükséges szolgáltatásokra.

waydroid -nál ezt raktam össze valamelyik AI-val. Működött.

sudo nmcli connection add type bridge autoconnect yes con-name br0 ifname br0
sudo nmcli connection modify br0 ipv4.method auto
sudo nmcli connection add type ethernet slave-type bridge autoconnect yes con-name br0-slave ifname enp0s31f6 master br0
sudo nmcli connection up br0
sudo nmcli connection up br0-slave

/var/lib/waydroid/lxc/waydroid/config:

# Use a bridged network instead of NAT
lxc.net.0.type = veth
lxc.net.0.link = waylanbr0 
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx  # Should be autogenerated, 00:16:3e is the prefix for virtual MAC's

Ez a config valószínű rossz, ezt módosítanám rajta, de a fentit raktam el megoldásként.
lxc.net.0.link = br0

ezzel működni látszik, de:

* néha a dns, névfeloldás akadozna.
* a konténer kap egy dhcp-s ip címet, nem tudom miért. :o

#!/bin/bash

nmcli connection add type bridge autoconnect yes con-name br0 ifname br0
nmcli connection modify br0 ipv4.addresses 192.168.1.223/24 ipv4.method manual
nmcli connection modify br0 ipv4.gateway 192.168.1.254
nmcli connection modify br0 ipv4.dns 8.8.8.8
nmcli connection modify br0 ipv4.dns-search t.hu
nmcli connection del enp0s3
nmcli connection add type bridge-slave autoconnect yes con-name enp1s0 ifname enp0s3 master br0
sudo nmcli connection up br0
# forward
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# firewalld masq
sudo firewall-cmd --zone=FedoraServer --permanent --add-masquerade
sudo firewall-cmd --zone=FedoraServer --add-service=dns --permanent
sudo firewall-cmd --zone=FedoraServer --add-service=http --permanent
sudo firewall-cmd --zone=FedoraServer --add-service=https --permanent
sudo firewall-cmd --zone=FedoraServer --add-service=dhcp --permanent
sudo firewall-cmd --reload

# dns konténerben
# echo -e "nameserver 8.8.8.8\nnameserver 1.1.1.1\noptions timeout:2 attempts:3" > /etc/resolv.conf

konténerben:

~# ip a

2: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:5c:31:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.225/24 brd 0.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.117/24 metric 1024 brd 192.168.1.255 scope global secondary dynamic eth0
       valid_lft 85683sec preferred_lft 85683sec
    inet6 2001:4c4d:1146:9500:216:3eff:fe5c:31f8/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3159sec preferred_lft 3158sec
    inet6 fe80::216:3eff:fe5c:31f8/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

~# ip r
default via 192.168.1.223 dev eth0 
default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.117 metric 1024 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.225 
192.168.1.254 dev eth0 proto dhcp scope link src 192.168.1.117 metric 1024