Teil des IPv6-Subnetzes für LXC Container verwenden

  • Hallo zusammen,


    ich versuche seit einiger Weile mit einem Teil der zur Verfügung gestellten IPv6-Adressen LXC-Container direkt zu adressieren. Bisher eher mit mäßigem Erfolg.

    Basis der Aktion war dieser Artikel sowie die dort verlinkten Beiträge: https://youngryan.com/2019/02/…-lxd-containers-on-a-vps/


    Hostsystem ist Ubuntu 18.04


    Mit Ubuntu 18.04 im container kann ich aktuell eine IPv6 aus dem zugewiesenen Pool beziehen, jedoch geht kein traffic durch.


    Mein Subnetz ist 2a03:xxx:xxx:1bd::/64 und für LXC möchte ich 2a03:xxx:xxx:1bd:feed:beef::/112 zuweisen.

    Da ich nicht genau weiß ich noch hinschauen soll versuche ich an dieser Stelle so viele Informationen wie möglich bereitzustellen um der Sache auf den Grund zu gehen. Falls etwas fehlt, reiche ich gerne nach.


    Vielleicht hat jemand eine Idee.


    Viele Grüße






    Code
    1. cat /etc/ndppd.conf
    2. proxy eth0 {
    3. rule 2a03:4000:xxx:xxx:feed:beef::/112 {
    4. iface lxdbr0
    5. router no
    6. auto
    7. }
    8. }


    Code
    1. #ip -6 route show (Host-System)
    2. 2a03:xxx:xxx:1bd::1 dev eth0 proto kernel metric 256 pref medium
    3. 2a03:xxx:xxx:1bd:24f6:1eff:fec8:8715 dev eth0 proto kernel metric 256 pref medium
    4. 2a03:xxx:xxx:1bd:feed:beef::/112 dev lxdbr0 proto kernel metric 256 pref medium
    5. fe80::/64 dev eth0 proto kernel metric 256 pref medium
    6. fe80::/64 dev lxdbr0 proto kernel metric 256 pref medium
    7. default via fe80::1 dev eth0 proto static metric 1024 pref medium
    Code
    1. #ip -6 route show (Gast-System)
    2. 2a03:xxx:xxx:1bd:feed:beef:0:1450 dev eth0 proto kernel metric 256 pref medium
    3. 2a03:xxx:xxx:1bd:feed:beef::/112 dev eth0 proto ra metric 100 pref medium
    4. fe80::/64 dev eth0 proto kernel metric 256 pref medium
    5. default via fe80::602c:55ff:fe94:7c14 dev eth0 proto ra metric 100 mtu 1500 pref medium
  • Wurde auf 0 geändet und geladen, keine Veränderung.

    ndppd lief tatsächlich nicht, weil sich auto und iface gegenseitig auschließen. Wurde korrigiert.

    lxd neu gestartet, aber keine Veränderung.

    Die Namensauflösung funktioniert, aber alles darüber hinausgehende nicht.

  • Ich sehe im ersten Betreitrag das zweimal das gleich Gateway beim Hostsystem genutzt wird, nicht gut.
    Gateway bei lxdbr0 entfernen, weil es eine Brücke ist und dort keine Routing notwendig ist.

    Das könnte evtl der Fehler sein.

  • Ich sehe im ersten Betreitrag das zweimal das gleich Gateway beim Hostsystem genutzt wird, nicht gut.
    Gateway bei lxdbr0 entfernen, weil es eine Brücke ist und dort keine Routing notwendig ist.

    Das könnte evtl der Fehler sein.

    Ich hatte mich schon etwas über den doppelten Gateway gewundert. War tatsächlich das Problem. ip -6 route del fe80::/64 dev lxdbr0 und dann die Dienste nochmal durchgestartet. Funktioniert.


    Leichter Off-Topic: Jetzt hängt der lxd.daemon beim Komplettneustart des VPS "A stop job is running for Service for snap application lxd.daemon". Das ist aber scheinbar ein Upstream Bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652

  • Von welchem Gateway redest du?

    Siehe gelbe Markierung (Gateway fe80::/64 zweimal da)

    pasted-from-clipboard.png


    Ich hatte mich schon etwas über den doppelten Gateway gewundert. War tatsächlich das Problem. ip -6 route del fe80::/64 dev lxdbr0 und dann die Dienste nochmal durchgestartet. Funktioniert.


    Leichter Off-Topic: Jetzt hängt der lxd.daemon beim Komplettneustart des VPS "A stop job is running for Service for snap application lxd.daemon". Das ist aber scheinbar ein Upstream Bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652

    Danke für deine Rückmeldung, manchmal sieht man den Wald vor lauter Bäume nicht. :)
    Das ganze ist mir ins Auge gesprungen.

  • Gateway fe80::/64 zweimal da

    Das ist kein Gateway, das ist eine Route. Eine Direct Connect Route um genau zu sein.

    fe80::/10 sind außerdem Link Lokale Adressen.


    Bei mir sieht das dann so aus:


    Code
    1. fe80::1 dev vmbr0 proto kernel metric 256 pref medium
    2. fe80::1 dev vmbr1 proto kernel metric 256 pref medium
    3. fe80::1 dev vmbr2 proto kernel metric 256 pref medium
    4. fe80::/64 dev enp4s0 proto kernel metric 256 pref medium
    5. fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
    6. fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
    7. fe80::/64 dev vmbr2 proto kernel metric 256 pref medium
    8. default via fe80::1 dev enp4s0 metric 1024 onlink pref medium


    Daher kann das nicht die Lösung sein.

  • Du hast Recht fe80::/10 sind Link Lokale Adressen in IPv6 und dürfen öfters vorkommen, das ist beim meinen Server auch so.


    Das Gatway auf den Hostsystem ist der Eintrag:

    default via fe80::1 dev eth0 proto static metric 1024 pref medium

    Was auch die Gateway Adresse im SCP ist

    Link-Local-Adressen nutzt man zur Adressierung von Knoten in abgeschlossenen Netzwerksegmenten sowie zur Autokonfiguration oder Neighbour-Discovery. Dadurch muss man in einem Netzwerksegment keinen DHCP-Server zur automatischen Adressvergabe konfigurieren. Link-Local-Adressen sind mit APIPA-Adressen im Netz 169.254.0.0/16 vergleichbar.

    Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die Zone ID mit angegeben werden, da eine Link-Lokale-Adresse auf einem Gerät mehrfach vorhanden sein kann. Bei einer einzigen Netzwerkschnittstelle würde eine Adresse etwa so aussehen: fe80::7645:6de2:ff:1<b>%1</b> bzw. fe80::7645:6de2:ff:1<b>%eth0</b>

    Du hast bei dir aber folgendes eingestellt und ich sehe noch ein Fehler

    1. fe80::1 dev vmbr0 proto kernel metric 256 pref medium
    2. fe80::1 dev vmbr1 proto kernel metric 256 pref medium
    3. fe80::1 dev vmbr2 proto kernel metric 256 pref medium

    Das Gastsystem ist Schuld:

    default via fe80::602c:55ff:fe94:7c14 dev eth0 proto ra metric 100 mtu 1500 pref medium <- Das ist Falsch!

    default via fe80::1 dev eth0 proto ra metric 100 mtu 1500 pref medium <- Müsst das nicht Richtig sein?


    Update: Er hat im Hostsystem auch Link Lokale Adressen unter lxdbr0 Eingestellt und dein Aufbau ist anders beim Hostsystem.

  • Hallo zusammen,

    angeritten mit tcpdump -nni interfacename icmp6 kannst du gucken, wo der Ping oder eine Antwort darauf kleben bleibt.

    Evtl. hilft das beim Debugging.

    Danke für den Tipp.

    Scheint gestern Zufall gewesen zu sein, dass es funktioniert hat.


    Anscheinend dauert es sehr lange bis das das neighbor advertisment durchgeführt wird....wenn es mal durchgeführt wird. Das ganz vehält sich sehr seltsam.

    Ich muss innerhalb der Container explizit dhclient -6 anstoßen. Dann dauert es bis zu zehn Sekunden bis die Adresse zugewiesen wird. Habe ich in zwei Ubuntu 18.04 Containern versucht.

  • Also es scheint als wäre diese Direct Connect Route durchaus notwendig wie H6G sagt.


    Wieder sehr langsames advertisment, danach funktioniert es jedoch. Zumindest in diesem container.

    In einem anderen Container hat er zwar das neighbor advertisment geschickt, aber Ping geht dennoch nicht durch....ich verstehe es nicht.



    Btw. ich würde meine Beiträge gerne zusammenfassen, mir fehlt dafür jedoch die Berechtigung. Manchmal funktioniert es, manchmal nicht.


  • Ein neu ersteller Container mit Debian Bullseye erhält gar keine IPv6 Adresse. dhclient -6 habe ich nach einer Minute abgebrochen.

    Es erscheint auch nichts im tcpdump.

    Debian Bullseye wird das neue Betriebsystem heisen. :/
    Wo hast du das System her, weil auf der Webseite von Debian steht folgendes "

    Die nächste Veröffentlichung von Debian heißt bullseye – bisher noch kein Veröffentlichungsdatum"?


    Ich selber setze Debian Buster als Produktivsystem ein, weil das keine Alpha oder Beta ist.

    Außer du möchtes damit rum Testen dann ist es in Ordnung. ;)


    Edit: IPv6 scheint sich Manchmal etwas seltsam zu Verhalten, weil ich hatte auch am Anfang Probleme gehapt mein Zusätzliches IPv6 Subnetz hinzufügen und laut Internet gibt es zwei Konfiguration Möglichkeiten bei Debian.

    Es geht aber nur ein und zwar die Beschriebene im Netcup Wiki.

  • Debian Bullseye wird das neue Betriebsystem heisen. :/
    Wo hast du das System her, weil auf der Webseite von Debian steht folgendes "

    Die nächste Veröffentlichung von Debian heißt bullseye – bisher noch kein Veröffentlichungsdatum"?


    Ich selber setze Debian Buster als Produktivsystem ein, weil das keine Alpha oder Beta ist.

    Außer du möchtes damit rum Testen dann ist es in Ordnung. ;)

    Bullseye steht wie andere noch in der Entwicklung stehende Betriebsysteme, beispielsweise Ubuntu Focal, als Container image über lxc image list images: zur Verfügung ;)

    Und ja, der Hauptgrund sind Testzwecke.

  • Habe noch etwas mit den Einstellungen herumgespielt, unter anderem ndppd auf static gesetzt, und bis auf die Tatsache, dass das advertsiment scheinber on-demand durchgeführt wird, funktioniertdas ganze jetzt.

    Falls jemand eine Idee hat das noch zu fixen wäre ich sehr dankbar.

  • Du hast bei dir aber folgendes eingestellt und ich sehe noch ein Fehler
    fe80::1 dev vmbr0 proto kernel metric 256 pref medium
    fe80::1 dev vmbr1 proto kernel metric 256 pref medium
    fe80::1 dev vmbr2 proto kernel metric 256 pref medium

    Das habe ich bei mir eingestellt, damit die Container fe80::1 als Gateway nutzen können. Das ist so richtig - ist aber nicht jedermanns Sache.