Netzwerk für Container LXD / OpenVZ mit eigener IP auf Netcup Root Server KVM

  • Hallo,


    ich benutze seit kurzem LXD Container und bin soweit sehr, sehr zufrieden. Die Dokumentation (english) ist hervorragend und die Kommandozeilenbedienung IMHO sehr einfach. Bei Netcup habe ich einen Root-Server (KVM) und eine zusätzliche IPv4 nur für den Container bestellt. Da LXD derzeit am besten unter Ubuntu 15.10 Wily läuft (lxd-stable repo einbinden nicht vergessen), musste ich noch ein Wily-Image hochladen. Nachdem ich im VCP die IPv4 dem Server zugeordnet habe, bin ich einfach dieser Anleitung hier gefolgt:


    KVM mit Nutzung aller IPs - the easy way – Hetzner DokuWiki


    Ich bin der Anleitung nicht direkt gefolgt. Statt zusätzlich eine Bridge anzulegen, habe ich das Netzwer-Interface auf dem Host durch die Bridge ersetzt, also iface ens3 usw auskommentiert. Die Anleitung kann man trotzdem so umsetzen. Ich habe statt einem statischen Setup für den Host DHCP genommen. Da funktioniert auch mit der Bridge. Außer: Weil ich kein anderes interface mehr habe, habe ich auf dem Host statt "bridge_ports none" lieber "bridge_ports ens3" angegeben. Da sollte man sich daran halten, welche Schnittstelle, also z.B. eth0, ens3, usw. vorher dort eingetragen ist.


    "The easy way" stimmt. Ich persönlich finde LXD viel einfacher als KVM, weil man sich um noch weniger kümmern muss. Die Container können eigene Firewalls laufen lassen. Man muss nur die entsprechenden Module (iptables, z.B.) auf dem Host laden, weil die Container selbst keine Module nachladen dürfen. Und so kann man Container bequem mit eigener IPv4 als vollständige Server laufen lassen.


    Für den LXD-Container muss man noch ein Profil anlegen, damit der Container sich an die neue Bridge hängt. Im default-Profil hängt sich LXD an lxbr0 und bekommt eine 10.0.3.x zugeteilt.


    Hier noch ein paar Links zu LXD:


    Linux Containers - LXD - Getting started - command line


    lxd/image-handling.md at master · lxc/lxd · GitHub


    lxd/command-line-user-experience.md at master · lxc/lxd · GitHub


    lxd/configuration.md at master · lxc/lxd · GitHub


    Es sieht schwerer aus, als es ist. Es gibt ganz wenig zu konfigurieren.


    So sieht meine /etc/network/interfaces auf dem wily Host aus:


    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).


    source /etc/network/interfaces.d/*


    # The loopback network interface
    auto lo
    iface lo inet loopback


    # The primary network interface
    #auto ens3
    #iface ens3 inet dhcp


    auto br0
    iface br0 inet dhcp
    bridge_ports ens3
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    up route add -host 37.120.x.x/32 dev br0


    Das habe ich bei meiner /etc/sysctl.conf auf dem wily Host hinzugefügt (Anmerkug: ipv6-Setup fehlt noch woanders, ist aber hier schon hinterlegt):


    net.ipv4.ip_forward=1
    net.ipv6.conf.all.forwarding= 1
    net.ipv6.conf.br0.forwarding = 1
    net.ipv6.conf.default.forwarding = 1
    net.ipv4.conf.all.send_redirects = 0


    Testweise habe ich als Gast ebenfalls Ubuntu 15.10 Wily angelegt. Es laufen aber auch Debian und CentOS problemlos.


    Mein /etc/network/interfaces auf dem Gast:


    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).


    # The loopback network interface
    auto lo
    iface lo inet loopback


    #auto eth0
    #iface eth0 inet dhcp


    auto eth0
    iface eth0 inet static
    address 37.120.x.x
    netmask 255.255.255.255
    # gateway und pointopeoint sind die address vom Host oben
    gateway 37.120.x.x
    pointopoint 37.120.x.x
    dns-nameservers 46.38.225.230 8.8.8.8


    Das Gast-Profil habe ich so angelegt:


    lxc profile create GUEST


    lxc profile edit GUEST


    ### This is a yaml representation of the profile.
    ### Any line starting with a '# will be ignored.
    ###
    ### A profile consists of a set of configuration items followed by a set of
    ### devices.
    ###
    ### An example would look like:
    ### name: onenic
    ### config:
    ### raw.lxc: lxc.aa_profile=unconfined
    ### devices:
    ### eth0:
    ### nictype: bridged
    ### parent: lxcbr0
    ### type: nic
    ###
    ### Note that the name is shown but cannot be changed


    name: GUEST
    config: {}
    devices:
    eth0:
    nictype: bridged
    parent: br0
    # 'parent' ist hier der Name der
    # Bridge aus /etc/network/interfaces vom Host
    type: nic


    Ich denke, dass LXD mit Ubuntu 16.04 Xenial Xerus starke Verbreitung finden wird. Die o.g. Anleitung sollte auch für xenial funktionieren.


    Anmerkung: Ich habe bei Netcup mehrfach angefragt und wurde freundlich ermutigt Container auf dem Root-Server anzulegen. :thumbup: :thumbup: Seitens Netcup gibt es also keine Einwände. Viel Spaß beim Containern. :D

  • Falls jemand die Konfiguration in Bezug auf ipv6 vervollständigen will, immer her damit. Und wie geschrieben müsste OpenVZ sehr ähnlich aussehen. Proxmox ist von OpenVZ zu LXC gewechselt.

  • Hallo Zusammen!


    ich bin auch an Linux Containern mit LXD/LXC interessiert und habe ein Web-Panel dafür entwickelt.


    Hat jemand evtl. Interesse, dieses zu testen oder zu nutzen? Ich hoste damit mehrere WordPress-Installationen innerhalb eines Netcup-Root-Servers (KVM) mittels LXD/LXC und verwender das Filesystem ZFS, um Copy-On-Write und schnelle Snapshots usw. zu haben.


    Wer Interesse an Test / Zusammenarbeit oder einfach auch nur "Austausch" etc hat, bitte per PM bei mir melden, ich möchte das demnächst (als opensource) veröffentlichen..


    Viele Grüße,
    -Ingo Baab


    PS: Ich bin auch aus Karlsruhe (bzw. Ettlingen) und wäre an "Interessierten" im weitersten Sinne (zum Erfahrungsaustausch) interessiert..

  • Hallo,


    hat es eigentlich jemand mal hinbekommen die IPv6 Adressen aus dem /64 direkt an die Container zu verteilen?


    Ich scheitere dran, dass die IPv6 Adressen von extern erreichbar sind. Der LXD Host kann ohne Probleme den Container pingen und umgekehrt, aber leider kommt von extern kein Traffic durch.



    Viele Grüße
    Volker

  • hat es eigentlich jemand mal hinbekommen die IPv6 Adressen aus dem /64 direkt an die Container zu verteilen?


    Könnte es an NDP scheitern? Häng Dich mal mit "tcpdump -n -l -v -i eth0 icmp6" dran und beobachte, ob auf die Neighbor Solicitations überhaupt ein Neighbor Advertisement von Deiner VM folgt.


    Ich weiß nicht, wie das bei LXD oder OpenVZ gehandhabt wird, aber vielleicht braucht man da auch etwas wie ndppd oder wenigstens ndp_proxy. Das standardmäßig enthaltene /64 ist nämlich nicht geroutet!



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Folgendes gibt das tcpdump aus, wenn ich versuche von extern eine SSH-Verbindung auf den Container (anonymisiert als 2a03:4000:A:B::C) aufzubauen:


    Code
    23:27:17.496502 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:17.496858 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]
    23:27:18.495848 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:18.496153 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]
    23:27:19.528440 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:19.528573 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]



    Das sieht für mich wie das richtige Frage/Antwortspiel vom NDP aus.

  • Ja, sieht soweit korrekt aus. Du könntest noch icmp6 gegen ip6 tauschen und schauen, was sonst alles ankommt oder beantwortet wird.


    Ansonsten klinke ich mich hier aber wieder aus. Mit dem Netzwerk von LXD/OpenVZ habe ich noch keine Erfahrung gesammelt.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Danke für die Denkanstöße



    Durch das tcpdump bin ich drauf gekommen dass das KVM wirklich nur mit der ens3 MAC-Adresse redet. Die Container hängen wie oben besprochen an der Bridge von ens3. Vom Container aus wird IPv4 auf die Haupt-IP der VM geroutet, damit die Pakete mit der MAC vom ens3 Device zum Router geschickt werden. So weit so klar.


    Im Bezug auf IPv6 heisst das: die proxy ndp Einstellungen vom Linux Kernel helfen hier nicht weiter. Die Container können zwar auf die Frage welche MAC Adresse zu einer IPv6-Adresse gehören antworten. Die kommen aber von der Container MAC und erreichen damit den Router gar nicht.


    Ohne den ndppd kommt man an der Stelle dann also nicht weiter. Das schöne ist, dass die aktuelle ndppd Version in Ubuntu 16.04 eine neue Option static hat. Darüber können dann für Einzel IPv6 (/128) oder auch kleine Netze die NDP Anfragen mit der ens3 MAC beantwortet werden, ohne dass das komplette Subnetz mit allen IPs aufgelöst werden kann. Das könnte ja die internen Tabellen sprengen.


    Wenn man den ndppd verwendet muss man aber trotzdem noch proxy ndp im Kernel für alle Devices erlauben. Ich habe nicht verstanden wieso, aber nur mit der Option klappt es.


    Generell habe ich noch nicht verstanden ob mit der Methode irgendwelche Pakete doppelt im Container ankommen können. Auf jeden Fall war ich mit der Erreichbaren Datenrate im Container ganz zufrieden.


    Und wo ich noch drüber gestolpert bin: in ufw muss man natürlich die Default Regeln für die FORWARD Queue auf ACCEPT stellen, sonst geht auch kein Traffic durch.


    Insgesamt funktioniert nun LXD prima in dem Root-Server. Ich werde nun die Container mit meinen Diensten aufsetzen und dann mal weiter sehen wie der Root-Server so läuft.