ubuntuusers.de

Hallo Allerseits,

verzeiht mir den kryptischen Titel, mir ist nichts passenderes eingefallen. Ich habe folgende Situation:

Auf einem Server ist isc-dhcp-server, Bind9 und KVM installiert. In einer VM möchte ich lxd Container betreiben. Um die Container im Netzwerk erreichbar zu machen habe ich eine ip route und iptables nat erstellt:

1
2
3
4
5

ip route add 10.0.6.0/24 via 192.168.0.16 dev eth1

$IPTABLES -t nat -A PREROUTING  -d 192.168.0.16  -j NETMAP --to 10.0.6.0/24
$IPTABLES -t nat -A POSTROUTING -o eth1   -d 10.0.6.0/24  -j SNAT --to-source 192.168.0.1
$IPTABLES -t nat -A POSTROUTING -o eth1   -d 10.0.6.0/24  -j SNAT --to-source 192.168.0.16

Mir wäre eine Netzwerkbrücke für die Container lieber gewesen, aber das habe ich leider nicht hinbekommen.

Nun würe ich gerne in Bind9 eine Wildcard Domain für die Container einrichten. Wie kann ich hier nun dem Container Host mitteilen, dass er die Adressen des Bind9 Servers richtig zuteilt? Kann man das irgendwie automatisieren?

Natürlich könnte ich in Bind9 jeden Container mit IP verlinken, aber das würde ich gerne vermeiden.

Grüße

Jonathan

jb-alvarado schrieb:

1 2 3 4 5

ip route add 10.0.6.0/24 via 192.168.0.16 dev eth1 $IPTABLES -t nat -A PREROUTING -d 192.168.0.16 -j NETMAP --to 10.0.6.0/24 $IPTABLES -t nat -A POSTROUTING -o eth1 -d 10.0.6.0/24 -j SNAT --to-source 192.168.0.1 $IPTABLES -t nat -A POSTROUTING -o eth1 -d 10.0.6.0/24 -j SNAT --to-source 192.168.0.16

Die letzte Regel wird niemals greifen, da iptables eine First-Match-Firewall ist.

Mir wäre eine Netzwerkbrücke für die Container lieber gewesen, aber das habe ich leider nicht hinbekommen.

Warum fragst du nicht danach, wenn die das lieber wäre?^^

Nun würe ich gerne in Bind9 eine Wildcard Domain für die Container einrichten. Wie kann ich hier nun dem Container Host mitteilen, dass er die Adressen des Bind9 Servers richtig zuteilt? Kann man das irgendwie automatisieren? Natürlich könnte ich in Bind9 jeden Container mit IP verlinken, aber das würde ich gerne vermeiden.

Hier ist erklärt, wie man isc-dhcp und bind verbindet, sodass automatische DNS-Updates erfolgen. Man kann auch händisch was stricken, mit nsupdate.

misterunknown schrieb:

Die letzte Regel wird niemals greifen, da iptables eine First-Match-Firewall ist.

Ich manage die Firewall mit FW Builder und der erstellt automatisch die letzte Regel zusätzlich. Mal schauen ob ich das noch lösen kann - wobei so ja grundsätzlich mal alles funktioniert wie es soll.

Warum fragst du nicht danach, wenn die das lieber wäre?^^

Habe schon an einer anderen Stelle gefragt ( http://askubuntu.com/questions/770252/network-bridge-inside-vm-for-lxd/770338#770338 ) und keine Antwort bekommen.

Hier ist erklärt, wie man isc-dhcp und bind verbindet, sodass automatische DNS-Updates erfolgen. Man kann auch händisch was stricken, mit nsupdate.

Ich kenne die Anleitung und dhcp / bind9 agieren auch in der Weise, allerdings bekommen die Container ja keine IPs von dem dhcp zugewiesen, daher auch mein Problem.

jb-alvarado schrieb:

Habe schon an einer anderen Stelle gefragt ( http://askubuntu.com/questions/770252/network-bridge-inside-vm-for-lxd/770338#770338 ) und keine Antwort bekommen.

Ok. Also ich würde das nochmal probieren. In deiner Frage bei askubuntu hast du beispielsweise "bridge-ports" statt "bridge_ports" geschrieben. Zudem gibt es "bridge-ifaces" nicht.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
   bridge_ports eth0
   bridge_stp off
   bridge_fd 0
   up ifconfig eth0 up
   down ifconfig eth0 down

Und dann mal per "brctl show" gucken, ob es passt.

Ich kenne die Anleitung und dhcp / bind9 agieren auch in der Weise, allerdings bekommen die Container ja keine IPs von dem dhcp zugewiesen, daher auch mein Problem.

Wenn du die IPs eh statisch vergibst, kannst du doch auch im bind die Namen statisch konfigurieren, oder versteh ich das falsch?

Man sollte doch noch mal schauen, von wo man kopiert ☺. Ok habe es noch mal so angepasst, wie du es geschrieben hast, aber geht leider wieder nicht.

brctl show gibt das aus:

bridge name	bridge id		STP enabled	interfaces
br0		8000.5254008fde71	no		eth0
							vethDNHJUU
							vethT76SUQ

lxd habe ich auch mit

sudo dpkg-reconfigure -p medium lxd 

neu konfiguriert, aber die Container bekommen keine IPs. Habe auch irgendwo mal gelesen, dass in einer VM die bridge nicht richtig funktioniert, leider weiß ich nicht mehr wo...

Die IPs vergebe ich nicht statisch, das hast du falsch verstanden.

jb-alvarado schrieb:

brctl show gibt das aus:

bridge name	bridge id		STP enabled	interfaces
br0		8000.5254008fde71	no		eth0
							vethDNHJUU
							vethT76SUQ

Das sieht eigentlich schonmal gut aus. Bekommt der Host eine korrekte IP per DHCP?

lxd habe ich auch mit

sudo dpkg-reconfigure -p medium lxd 

neu konfiguriert, aber die Container bekommen keine IPs. Habe auch irgendwo mal gelesen, dass in einer VM die bridge nicht richtig funktioniert, leider weiß ich nicht mehr wo...

Wie sieht deine Container-Definition aus? Zeige mal:

1

grep "lxc.network.link" /var/lib/lxc/*/config

Die IPs vergebe ich nicht statisch, das hast du falsch verstanden.

Woher bekommen die Container dann ihre IP? Momentan machst du ja nur folgendes: Du mappst die IP 192.168.0.16 auf das Netz 10.0.6.0/24 und routest dieses Netz über das Gateway 192.168.0.16 (eth1. Außerdem source-nattest du alle Verbindungen nach 10.0.6.0/24 auf die Quell-Adresse 192.168.0.1, bzw. 192.168.0.16 (allerdings greift immer die erste Regel mangels weiterer Einschränkungen). Mir ist noch schleierhaft, wie das genau funktioniert, aber ich bin auch kein Experte.

Noch eine Idee: Wo lauscht eigentlich der DHCP-Server? Der sollte IMHO mit an die Bridge gehangen werden.

Der Host bekommt seine IP vom isc-dhcp-server, allerdings per fixed-address:

host ubuntu-16 {
        hardware ethernet 52:54:00:8f:de:71;
        fixed-address 192.168.0.16;
}

Ist das ein Problem?

Ich verwende lxd und dort habe ich die Container Definitionen noch nicht gefunden. die Datei /etc/default/lxd-bridge schaut so aus:

# Whether to setup a new bridge or use an existing one
USE_LXD_BRIDGE="false"

# Bridge name
# This is still used even if USE_LXD_BRIDGE is set to false
# set to an empty value to fully disable
LXD_BRIDGE="br0"

# Update the "default" LXD profile
UPDATE_PROFILE="true"

# Path to an extra dnsmasq configuration file
LXD_CONFILE=""

# DNS domain for the bridge
LXD_DOMAIN="lxd"
[...]

Das routing und natting sollte eigentlich keine Rolle mehr spielen, jetzt müssten die Container ja ihre IP über die Bridge bekommen. Wenn die Bridge richtig läuft brauche ich keine extra route bzw. NAT, weil die dhcp Anfragen dann durch die Bridge gehen.

jb-alvarado schrieb:

Der Host bekommt seine IP vom isc-dhcp-server, allerdings per fixed-address:

host ubuntu-16 {
        hardware ethernet 52:54:00:8f:de:71;
        fixed-address 192.168.0.16;
}

Ist das ein Problem?

Nein. Die Frage ist nur, an welchem Interface der DHCP-Server lauscht. An der Bridge oder an eth0? Wie sagt am Host:

1
2

ip addr show
ip link show

Ich verwende lxd und dort habe ich die Container Definitionen noch nicht gefunden.

lxd ist nur ein Hypervisor, der unter der Haube lxc verwendet (siehe auch). Wo die Definitionen stehen, kann ich dir nicht sagen, aber hier steht was davon, dass man die Einstellungen mit

1

lxc profile edit default

ändern kann.

Das routing und natting sollte eigentlich keine Rolle mehr spielen, jetzt müssten die Container ja ihre IP über die Bridge bekommen. Wenn die Bridge richtig läuft brauche ich keine extra route bzw. NAT, weil die dhcp Anfragen dann durch die Bridge gehen.

Naja, du mappst immer noch alle Anfragen an 192.168.0.16 in der 10er-Netz. Ich würde alle Regeln und Routen, die du nicht mehr brauchst, entfernen.

misterunknown schrieb:

Nein. Die Frage ist nur, an welchem Interface der DHCP-Server lauscht. An der Bridge oder an eth0? Wie sagt am Host:

Das macht mich selbst gerade etwas stutzig: eigentlich lauscht der DHCP Server auf eth1, eth0.12, eth0.13. Die VM in der die Container hängt allerdings in KVM an eth0 mit einer Bridge. Funktioniert auch soweit. Der Container Host bekommt seine IP.

1
2
3
4
5
6
7
8

<interface type='direct'>
      <mac address='52:54:00:8f:de:71'/>
      <source dev='eth0' mode='bridge'/>
      <target dev='macvtap3'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
 </interface>

Möglich dass hier der Hund begraben liegt?!

root@router:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 40:16:7e:a4:8d:a2 brd ff:ff:ff:ff:ff:ff
4: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP mode DEFAULT group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
5: eth0.11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP mode DEFAULT group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
6: eth0.12@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
7: eth0.13@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none
9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether a2:25:e6:7e:0c:ae brd ff:ff:ff:ff:ff:ff
10: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN mode DEFAULT group default qlen 32
    link/ether e6:35:c2:ec:ae:c4 brd ff:ff:ff:ff:ff:ff
12: macvtap1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:86:30:48 brd ff:ff:ff:ff:ff:ff
13: macvtap2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:e2:7f:a5 brd ff:ff:ff:ff:ff:ff
15: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:ab:6a:ad brd ff:ff:ff:ff:ff:ff
16: macvtap3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:8f:de:71 brd ff:ff:ff:ff:ff:ff
root@router:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 40:16:7e:a4:8d:a2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
4: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
    inet 188.192.90.92/24 brd 188.192.90.255 scope global eth0.10
       valid_lft forever preferred_lft forever
5: eth0.11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.101/24 brd 192.168.10.255 scope global eth0.11
       valid_lft forever preferred_lft forever
6: eth0.12@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0.12
       valid_lft forever preferred_lft forever
7: eth0.13@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 08:62:66:4c:14:29 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global eth0.13
       valid_lft forever preferred_lft forever
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether a2:25:e6:7e:0c:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
10: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN group default qlen 32
    link/ether e6:35:c2:ec:ae:c4 brd ff:ff:ff:ff:ff:ff
12: macvtap1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:86:30:48 brd ff:ff:ff:ff:ff:ff
13: macvtap2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:e2:7f:a5 brd ff:ff:ff:ff:ff:ff
15: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:ab:6a:ad brd ff:ff:ff:ff:ff:ff
16: macvtap3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:8f:de:71 brd ff:ff:ff:ff:ff:ff

lxd ist nur ein Hypervisor, der unter der Haube lxc verwendet (siehe auch). Wo die Definitionen stehen, kann ich dir nicht sagen, aber hier steht was davon, dass man die Einstellungen mit

1	lxc profile edit default

ändern kann.

Hatte ich schon kontrolliert, sollte passen:

name: default
config: {}
description: Default LXD profile
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: br0
    type: nic

Naja, du mappst immer noch alle Anfragen an 192.168.0.16 in der 10er-Netz. Ich würde alle Regeln und Routen, die du nicht mehr brauchst, entfernen.

habe ich jetzt raus genommen.

jb-alvarado schrieb:

Nein. Die Frage ist nur, an welchem Interface der DHCP-Server lauscht. An der Bridge oder an eth0? Wie sagt am Host:

Das macht mich selbst gerade etwas stutzig: eigentlich lauscht der DHCP Server auf eth1, eth0.12, eth0.13. Die VM in der die Container hängt allerdings in KVM an eth0 mit einer Bridge. Funktioniert auch soweit. Der Container Host bekommt seine IP.

Wie hast du denn deine Bridge genannt? Ein Interface namens "br0" gibt es nämlich bei dir soweit ich sehen kann nicht.

Das erledigt KVM, das erstellt diese macvtap* Interface.

Anscheint ist das auch nicht so leicht. habe auf einigen Seiten gelesen, dass man eine promiscuous mode aktivieren muss.

http://serverfault.com/questions/759381/how-to-make-lxd-containers-accessible-to-the-lan

Habe ich mal versucht, aber geht dennoch nicht.

jb-alvarado schrieb:

Das erledigt KVM, das erstellt diese macvtap* Interface.

Nö. Diese Interfaces werden AFAIS als so eine Art Alias-Interface an eth0 geknöpert. Das heißt: LXD erstellt keine Bridge. Vielleicht kann man konfigurieren, dass LXD das übernimmt, dazu kenne ich mich zu wenig aus, aber ich würde erstmal den händischen Weg gehen.

Anscheint ist das auch nicht so leicht. habe auf einigen Seiten gelesen, dass man eine promiscuous mode aktivieren muss.

ifconfig eth0 promisc

Ich gehe jetzt erst mal wieder zurück zu der Lösung die ging, mit dem routing und trage mir die IPs eben manuell in Bind ein.

Vielleicht schreib ich mir dafür auch noch ein Script...

Edit: die korrekte NAT Regel ist übrigens:

iptables -t nat -A POSTROUTING -o eth1 -d 10.0.6.0/24 -j SNAT --to-source 192.168.0.1 

Ich antworte noch mal hier, vielleicht ist das noch mal für jemand nützlich.

Also die NAT Regel war nötig, weil alles auf einem Rechner läuft: Firewall, DHCP, DNS und KVM. Die Firewall ist da etwas durcheinander gekommen und hatte dann Pakete verworfen. Wollte ich von einem lokalen Rechner aus per ssh auf einen Container zugreifen ging das über drei Routen: router → lxd-host → container. Die Container selbst haben allerdings nur zwei Routen verwendet um das Antwortpaket zurück zu schicken: lxd-host → lokaler Rechner.

Habe es jetzt aber hinbekommen die Container ins lokale Netz zu holen. Und zwar habe ich auf dem Router ein Bridge Interface erstellt und der VM gesagt sie soll das Bridge Interface nutzen. Die Bridge die KVM mitbringt ist dafür wohl ungeeignet.