IPv6 DNAT Routing an LXD Container

Ich habe einen RS 1000 mit frisch installiertem Ubuntu 18.04. Auf diesem Server habe ich LXD aktiviert und einen Container mit ubuntu:18.04 gestartet.

Der Container verwendet also das Default Profile mit der standarmässig von LXD verwalteten Bridge (Network) lxdbr0.

+------+---------+----------------------+-----------------------------------------------+
| NAME | STATUS  |         IPV4         |                     IPV6                      |
+------+---------+----------------------+-----------------------------------------------+
| box1 | RUNNING | 10.137.164.17 (eth0) | fd42:58a3:ae0e:71df:216:3eff:fe27:de32 (eth0) |
+------+---------+----------------------+-----------------------------------------------+

So weit ist alles normal und der Container hat nach lxc exec box1 -- bash aus dem Container heraus IPv4 und IPv6 Zugriff auf das Internet.

In der /etc/sysctl.conf habe ich auch die Einträge net.ipv4.ip_forward=1 und net.ipv6.conf.all.forwarding=1 gesetzt und den Server neu gestartet.

Jetzt möchte ich von meinem PC mit ssh über IPv6 auf den Container zugreifen und habe zu diesem Zweck mit ip6tables einfach mal einen PREROUTING DNAT Eintrag erstellt.

sudo ip6tables -t nat -A PREROUTING -d 2a03:4000:xx:yyy::11 -j DNAT --to-destination fd42:58a3:ae0e:71df:216:3eff:fe27:de32

Die in Netplan statisch definierte IPv6 Adresse von ens0 des LXD Hosts ist 2a03:4000:xx:yyy::2/64. Mit dieser Adresse erreiche ich meinen Root Server.

Nachdem ich mit Hilfe von lxc exec im Container einen User angelegt und die /etc/ssh/sshd_config angepasst habe, erwartete ich (nach Neustart des Containers), dass ich über die Adresse 2a03:4000:xx:yyy::11 per ssh auf den Container zugreifen kann, oder diesen mit dieser Adresse anpingen kann. Leider funktioniert das nicht und ich habe keine Ahnung warum.

Wenn ich mit sudo ip addr add 2a03:4000:xx:yyy::11/64 dev ens3 die Adresse auch noch der Schnittstelle im LXD Host hinzufüge, dann funktioniert der Zugriff auf den Container von aussen. Ich halte diese Konstellation allein schon deshalb für falsch, da ich sie auf anderen Servern (nicht bei netcup gehostet) noch nie brauchte.

Ob es nun an solchen Experimenten mit Alias Adressen gelegen hat oder eine andere Ursache hatte weiss ich nicht, aber vor zwei Tagen hatte ich auch das Problem dass IPv6 Pings nach aussen nicht zu allen Destinationen funktioniert hat. Ich wollte das der Vollständigkeit halber noch erwähnen. Inzwischen habe ich den Server neu installiert und dies funktioniert jetzt wieder. Das Routing Problem ist aber weiterhin offen. Es hat sich daran nichts geändert.

oliver.g : Ja, ich mach das normalerweise auch nicht so, ist nur ein Workaround, weil ich mit möglichst wenig Aufwand rasch eine ssh-Verbindung haben wollte. Der Schuss ging aber nach hinten los

Mordor : Danke, alles klar.

Dass das IPv6/64 Subnet nicht an den Server geroutet wird fnde ich jetzt ein bisschen ein Schwachpunkt bei netcup. In der Hoffnung, dass es den erhofften Erfolg bringt, hab ich mal ein zusätzliches IPv6 Subnet bestellt. Ein Failover nur dafür ist mir zu teuer.

Klar kann ich einen ND Proxy konfigurieren, aber ich möchte meine Konfigurationen lieber überall gleich und weniger fehleranfällig haben. Auch wenn ich auf meinem ersten Server bei Netcup höchstens ein oder zwei Container haben werde, so ist mir eine möglichst einheitlich gehaltene einfache Konfiguration wichtig.

Ich frag mich gerade ob das jemals jemand zum laufen gebracht hat. Ich habe jetzt so ziemlich alles durchgespielt, was ich mir denken kann.

Auf meinem Root-Server hab ich ein zusätzliches IPv6/64 Subnetz das geroutet wird. Aber selbst damit hatte ich keinen Erfolg.

Auf meinem vServer habe ich es mit ndppd versucht aber auch damit keinen Erfolg.

Hat jemand funktionierende Beispiele dafür? (beide Szenarien sind gefagt)

Quote from voja

Nur damit ich das richtig verstehe: willst Du einem LXD Container eine IPv6 Adresse aus einem gerouteten Subnetz zuweisen? Welche LXD Version hast Du

Ja genau das möchte ich. Das wäre schon mal etwas Ich verwende Ubuntu 18.04 LTS mit LXD 3.0.3 und Netplan (gilt für Host und Container).

Die Adressen binde ich im Container statisch an eth1. All meine Container haben normalerweise immer die defaultmässige von LXD verwaltete lxdbr0 mit der Schnittstelle eth0. In meinen Konfigurationen hier bei Netcup habe ich diese aber bewusst ausgeschaltet (Profile default nach ipv6 kopiert und lxdbr0 durch lxdbr1 ersetzt, dann das Profile ipv6 dem Container zugewiesen).

Früher, unter Ubuntu 16.04, machte ich das über eine nicht von LXD verwaltete Layer 3 Bridge (virbr0 (brouter) oder wie immer man das nennen mag). Ich machte keine weitere Unterteilung.

Neu unter Ubuntu 18.04 mit Netplan und LXD 3.0.3 mache ich das über eine von LXD verwaltete Bridge. Das ist insgesamt einfacher. Ich weise dabei jeder Bridge ein /80 Netz zu, das gibt mir noch etwas Spielraum, muss aber nicht sein, da ich hier eh nur eine Bridge benutzen werde.

Ich habe jetzt hier bei netcup zwei Server. Einen root Server mit zusätzlichem IPv6/64 Subnetz und einen vServer ohne zusätzlichem Subnet. Ich verstehe jetzt schon die Notation -> 2a03:4000:32:112:8f5:4aff:feb3:b46a nicht ganz. Inwieweit betrifft mich das? Muss ich das auch als Gateway einsetzen oder bleibt fe80::1 mein Gateway? Bei meinem anderen Provider setzte ich im Container die Host-seitige Link Local Adresse der Bridge als Gateway. Der Rest bleibt sich gleich.

Ich versuche mein Vorgehen später oder morgen mal in den Details aufzuzeigen. Aber vielleicht hast du auch schon ein Tipp.

Quote from voja

Wenn das IPv6 Subnetz gerouted ist, legst Du das /64 Netz auf das gewünschte Netzwerkinterface (Bridge).

Die Hostbridge kriegt eine IPv6 Adresse aus dem /64 Netz, das als Gateway für die Container dient. Die IPv6 für die Container kannst Du dann jeweils im Container festlegen.

Ok, danke. Ich dache mir, dass es so ist, aber es hat irgendwie nicht funktioniert. Ping bis zur Bridge geht, aber nicht zum Container und es geht auch nichts aus dem Container raus. Ich starte morgen nochmals von vorne mit einer frischen Installation.

ok, danke euch allen. Ich denke da muss der Support ran.

Bei einem Ping von extern kommt in sudo tcpdump -i ens3 -x icmp6 und dergleichen an der Schnittstelle am "Host" nichts an was das zusätzliche Subnet betrifft. "Neighbour solicitations" für das nicht geroutete IPv6 Subnet kommen an. Ping vom Host zum Container geht, ssh ebenfalls. Firewall hab ich zu dem Zeitpunkt keine.

Ich überlege und versuche mal ob ich über das Rettungssystem noch Erkenntnisse gewinnen kann, falls nicht werde ich mal den Support bemühen.

Aber vorerst wünsche ich allen noch einen Guten Rutsch und alles Gute im neuen Jahr!

Antwort vom Support, nachdem ich die Situation mit den LXC/LXD Containern nochmals detailliert beschrieben habe und gezeigt habe, dass auch im Rettungssystem vom/zum zusätzlich bestellten IPv6 Subnet kein externer Verkehr möglich ist. Zudem habe ich geschrieben, dass der Server bis zum 7.1.2019 jederzeit und ohne Vorwarnung jederzeit abgestellt werden darf um das Problem zu analysieren.

"Natürlich wird das von uns zur Verfügung gestellte IPv6 Netz geroutet. Bitte gehen Sie nach folgender Anleitung vor um eine IPv6 Adresse zu konfigurieren https://www.netcup-wiki.de/wiki/Zus%c3%a4tzliche_IP_Adresse_konfigurieren#IPv6%7C

Was das System interne Routing angeht haben wir keine Möglichkeit irdgendwas zu überprüfen, da wir keinen Zugriff auf den Server haben.

Wir können aber versichern, dass das Standard Subnetz geroutet wird."

Natürlich bin ich der Anleitung gefolgt. Ich habe das zwar nicht explizit gesagt, aber umschrieben.

Es tut mir leid. Wenn sich der netcup Support nicht ein bisschen mehr Mühe gibt, dann bin ich hier definitiv beim falschen Anbieter. Mein Setup läuft bei meinem bisherigen Provider sowohl auf einem dedizierten Server als auch auf einem VPS und ist von mir in weniger als 30 Minuten aufgesetzt.

Ich habe alle Produkte bei netcup gekündigt.