Beiträge von DigitalClark

    Die IPv6 kannst du doch auch in der LXC Config für die Bridge zuweisen

    Danke! Das war der springende Punkt! Ich habe mir nochmal die /usr/lib/x86_64-linux-gnu/lxc/lxc-net genauer angeschaut und meine /etc/default/lxc-net angepasst.
    Die sieht nun wie folgt aus

    Die up bzw. post-up Anweisungen habe ich komplett aus der /etc/network/interfaces des Hosts entfernt.

    Jetzt klappt alles! ND-Proxy eines gesamten Subnetz, statische IPv6-Addresse für die lxc-net Bridge und die Container, persistent selbst nach einem Reboot!
    Eigentlich gar nicht mal so schwer, war nur eine Menge Research :D.


    Vielen Dank euch allen!

    Du hast jetzt auf ens3 eine Adresse aus deinem Subnetz mit /64 eingerichtet und auf lxcbr0 mit /80. Zwei Interfaces mit Adressen aus dem gleichen Subnetz. Macht das nicht Schwierigkeiten?

    Sehr gut möglich... Meine Konfiguration ist wie gesagt eine gesunde Mischung aus Trial & Error und Inspiration aus diesem Thread bzw. diesem Blog-Post. Dort scheint alles an das primäre eth0-Interface angebunden zu sein. Dort wird aber auch Ubuntu, netplan und LXD verwendet...

    Auf dem Host: ip -6 addr add fe80::1 dev lxcbr0 - dann kannst du im Container auch fe80::1 als Gateway eintragen.

    Sauber! Hat funktioniert.


    Für die initiale Verzögerung hatte ich bisher auch keine Lösung gefunden. Der Ping ist aber ein guter Workaround.

    Sobald es mal wieder ein /64 Subnetz im Angebot geben sollte werde ich da definitiv zuschlagen! Solang muss der Workaround hinhalten 8o.


    __________________________________________________________________________________________________________________


    Ich muss mich außerdem nochmal korrigieren:

    Zitat von Ich selber

    Hier weise ich also nach dem raisen des ens3-Interfaces der lxcbr0 Bridge ein /80 Subnetz hinzu (mir ist leider aufgefallen, dass nach dem Reboot die lxcbr0 Bridge nicht immer bereit zu seien scheint und die Adresse nicht zugewiesen wird, hier scheint es also noch Verbesserungspotential zu geben).

    Dies scheint tatsächlich nach keinem Reboot zu funktionieren, weder mit up <...> noch mit post-up <...>. Wie @frank_m schon angedeutet hat ist das möglicherweise auch gar nicht mal die beste Lösung (?).

    Hättet ihr da noch eine Idee?

    So, ich musste mich die letzten Tage nochmal etwas mehr mit der Thematik beschäftigen und wollte nochmal ein Statusupdate geben.


    Was mir nicht so gut gefällt, ist, dass du eine Bridge hast, die deine NIC beinhaltet und in den Container reinbridged.


    [...]

    Ich persönlich würde das nicht so machen. Das kann zu Problemen führen, muss es aber nicht. Den Container würde ich in die lxcbr0 einhängen und ein geroutetes Setup fahren.

    Du hattest auf jeden Fall Recht. Meine vorheriger Lösungsansatz mit der Bridge hat zwar "funktioniert", hat aber tatsächlich zu Problemen geführt und war verhältnismäßig auch viel zu umständlich.

    Ich habe es jetzt, wie von @H6G empfohlen, mit Routing gelöst (ich hoffe jedenfalls dass ich es richtig verstanden habe :D).

    Die Bridge habe ich komplett verworfen, meine /etc/network/interfaces auf dem Host sieht nun wie folgt aus:

    Hier weise ich also nach dem raisen des ens3-Interfaces der lxcbr0 Bridge ein /80 Subnetz hinzu (mir ist leider aufgefallen, dass nach dem Reboot die lxcbr0 Bridge nicht immer bereit zu seien scheint und die Adresse nicht zugewiesen wird, hier scheint es also noch Verbesserungspotential zu geben).

    Im Container weise ich lediglich nur noch die statische IPv6 Adresse zu:

    Als Gateway nutze ich die Public-Adresse die ich der lxcbr0 Bridge zugewiesen habe. fe80::1 funktioniert hier leider (noch) nicht.

    Die ndppd.conf habe ich auch nochmal angepasst:

    Hier proxie ich nun zusätzlich mittlerweile das gesamte /80 Subnetz anstatt einzelner Adressen.

    Nun funktioniert auch alles und ich habe kaum mehr Paketverlust, lediglich zu Anfang wenn die Route wieder aufgebaut wird. Dies Problem bleibt auch weiterhin bestehen (ich nehme mal an jedoch nur mit dem inkludierten /64 Subnetz). Damit die Route im Cache bleibt lege ich in jedem Container einen Cronjob an, welcher alle 3 Minuten mal ein ping -6 -w 60 -c 8 netcup.de macht. Zwar nicht hübsch, funktioniert aber (soweit).

    Falls euch noch irgendetwas auffällt oder ihr Verbesserungsvorschläge habt: Bitte immer her damit! Für mich war dieser kleine Ausflug ins Thema IPv6 mit LXC und manuelle Netzwerk-Konfiguration komplett neu, also falls ich etwas übersehen habe oder man etwas noch eleganter lösen könnte, lasst es mich wissen!

    Schönen Abend wünsch ich euch Allen!

    Danke schon mal für eure Antworten!


    im Container drinnen kannst Du die IPv6 des fe80:xxx Gateways pingen?

    Ja, das geht (als Gateway im Container nutze ich nicht fe80::1, sondern die Link Local Adresse das Hosts).


    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


    Wie oben schon diskutiert scheint ein Neighbor Discovery Proxy definitiv notwendig zu sein.

    Gute Nachrichten: Das Problem scheint jetzt behoben zu sein. Woran es genau lag kann ich leider noch nicht sagen, ich habe jedoch eine Vermutung. Sobald ich es genau eingrenzen kann, werde ich diesen Post nochmal editieren!
    Ich habe den Host mal neugestartet (was ich jedoch gestern öfters gemacht habe und eigentlich nichts geändert hat) und IPv6 im Container für das Interface deaktiviert, welches an das lxc-net NAT angeschlossen ist.

    Danke für die Antwort!


    Zitat

    der beim vServer mitgelieferte /64-Prefix ist schon geroutet;

    Verstehe ich es richtig, dass ein Neighbor Discovery Proxy dann gar nicht nötig ist? Oder habe ich da etwas falsch verstanden? Ich bin darüber nämlich immer wieder gestoßen, als ich mich hier durch's Forum gelesen habe :).


    Zitat

    Hinweis: FORWARD bei IP6tables

    Oh, das habe ich vergessen: Ich nutze ufw, Forwarding habe ich erlaubt.



    EDIT:
    Ein weiterer Blick auf tcpdump zeigt, dass sogar alle ICMP6 Pakete beim Container ankommen und sogar beantwortet werden. Es kommen aber nicht alle wieder raus...

    Hey netcup-Forum!


    Ich habe mir vor kurzem LXC (nicht LXD!) auf Debian 10 eingerichtet und wollte nun neben dem IPv4 NAT (lxc-net) jedem Container eine eigene IPv6-Adresse aus dem "mitgeliefertem" /64 Subnetz zuweisen. Das ganze habe ich gelöst mit ndppd, da ich nach ausgiebigem durchforsten des netcup-Forums mehrfach gelesen habe, dass die inkludierten IPv6 Subnetze nicht geroutet sind und deshalb entweder ein zusätzliches IPv6 Subnetz oder ein Neighbor Discovery Proxy die Lösung sei (dazu später mehr). Das ganze hat auch geklappt, nach etwas rumprobieren und troubleshooting mit tcpdump habe ich schließlich eine IPv6-Adresse einem Container zuweisen können. Das Problem ist jedoch, dass beim anpingen des Containers von außen anfangs sehr viele Pakete verloren gehen (manche kommen jedoch vereinzelnt durch) und dann erst nach ca. 70 - 100 Paketen eine stabile Verbindung aufgebaut wird. Bricht man das pingen ab und versucht es nach nur ein paar Sekunden erneut, scheint die Route bereits aus dem Cache gelöscht wurden zu sein und das ganze geht von vorne los.

    Hier mal ein Dump vom Ping:

    Lustigerweise dauert es immer ca. 70 bis 100 Pakete, bis es dann stabil läuft. Pingt man den Container vom Host selbst läuft alles ohne Paketverlust.

    Um euch mal ein paar Infos über mein System zu liefern, hier die Konfiguration vom Host. Jedoch noch vorweg: Da für mich IPv6 und Neighbor Discovery noch recht neu ist und ich mich erst die letzte Woche in die Thematik eingearbeitet habe, weist mich gerne auf mögliche Denkfehler hin!

    Es folgt die Konfiguration vom ipv6test-Container:

    EDIT: Achso, by the way, ::1 ist der Host und ::2 der Container, der restliche Prefix ist der Gleiche.

    Nun noch einmal zum Thema /64 Subnetze: Ich habe leider noch nicht ganz verstanden in wie fern sich die inkludierten Subnetze von den zusätzlichen Subnetzen unterscheiden. Wenn nur die zusätzlichen Subnetze geroutet werden, wie werden dann die mitgelieferten Subnetze aufgeschaltet? Was ist der Grund, weshalb netcup diese unterschiedlich aufschaltet? Und vor allem, wenn der Fehler nicht bei mir liegt (was ich zwar stark hoffe, aber auf Grund von den zahlreichen anderen Threads bezüglich der mitgelieferten /64 Subnetze hier im Forum nicht glaube), was soll ich dann mit 18446744073709551616 IPv6-Adressen die man nicht ordentlich routen kann?

    Ich hoffe mich kann jemand aufklären.


    Vielen Dank schon mal im Voraus! Ich wünsche euch allen ein schönes Wochenende :)!

    Moin,


    auf deinem vServer müsste ein Webserver laufen (z.B. NGINX, Apache, etc.). In den DNS-Einstellungen deiner Domain verweist du lediglich auf die IP-Adresse des vServers mit Hilfe eines A-Records, dies kannst du im Customer Control Panel tun (falls du nicht die Nameserver eines externen Providers nutzt).


    Nun kannst du auf deinem vServer Virtual Hosts in Form von config-files erstellen, die (unter anderem) angeben aus welchem Verzeichnis der Webserver bei einem Request die Inhalte zurück liefern soll.


    Dazu kommt dann noch, dass du dir SSL-Zertifikate ausstellen lassen solltest (siehe Let's Encrypt) um Traffic über HTTPS zu ermöglichen.


    EDIT: Ach so, by the way :D, das oben natürlich nur als kleiner Leitfaden. Man sollte seinen Server natürlich (egal was man darauf laufen lässt) ausreichend absichern.

    Ist das RS 1000 Angebot für 6.49 €uro schon ausverkauft?


    Zitat

    Du kannst nicht zufällig auch den VPS 200 vorhersagen oder? ^^

    Das würde mich auch interessieren :D...

    Hallo,


    nachdem ich vorhin einen reinstall von Ubuntu 14.04 minimal durchgeführt habe, zeigt mir die VNC Console im SCP nur noch folgendes an:


    [Blockierte Grafik: http://i.imgur.com/1T09Ruf.png]


    Im SCP kann ich leider auch nichts machen:


    Es kann keine Aktion für diesen Server ausgeführt werden, da bereits folgende Aktion gerade auf dem Server ausgeführt wird:

    • reinstall


    Könnt ihr mir vielleicht weiterhelfen?


    MfG und schönes Wochenende,

    Clark :)