Sekundäre IP vollständig auf LXC-Container weiterleiten

  • Hallo,

    aktuell versuche ich, mein internes Netzwerk auf einem LXC-Host zum laufen zu bekommen.

    I habe zwei IP´s:

    Code
    1. eine die mit meinem Server mitgeliefert wurde - sagen wir: 1.1.1.1 ("IP-1")
    2. und eine welche zu dem gleichen Interface gerouted wird - sagen wir: 2.2.2.2 ("IP-2")

    Ich benutze IP-1 um ein NAT zu erstellen, womit ich die meisten LXC-Container anbinde.

    Ich möchte IP-2 vollständig für einen LXC-Container verwenden. Aber die Zuweisung klappt nur in eine Richtung.


    Wenn ich IP-2 mit meinem Browser aufrufe, lande ich auf dem gewünschten Container, wenn ich aber zum Beispiel curl http://ifconfig.me/ip auf dem Container aufrufe, erhalte ich IP-1 zurück.


    Langsam gehen mir die Ideen aus, wie man das fixxen könnte. Hat hier ggf. jemand ne Ahnung ?


    Ich hänge mal hier mein Networking an:

    (Das Gateway ist für beide IPs gleich)

    (LXC-Config + Networking im Container ist auf 10.10.10.1 gesetzt)

    /etc/network/interfaces (HOST):

  • Hey,

    du meinst

    Code
    1. up iptables -t nat -F POSTROUTING
    2. up iptables -t nat -A POSTROUTING -s 2.2.2.2/32 -o eth0 -j SNAT --to 10.10.10.1
    3. #up iptables -t nat -A PREROUTING -d 2.2.2.2/32 -j DNAT --to-destination 10.10.10.1
    4. up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE

    ?


    Weil das funktioniert gar nicht. Also in keine Richtung.

  • Ein IP Paket hat im Header zwei Adressen: Das Ziel (Destination) und die Quelle (Source).

    NAT (Network Address Translation) tauscht diese Adressen aus.

    SNAT (SourceNAT) tauscht die Quelle aus (mit dem --to-source Parameter) und macht das gleiche wie Masquerade, nur bei Masquerade kannst du die Adresse nicht gezielt manipulieren.


    DNAT (Destination NAT) tauscht das Ziel aus.


    Du brauchst beides:


    Code
    1. up iptables -t nat -A POSTROUTING -i virbr0 -o eth0 -j SNAT --to-source 2.2.2.2
    2. up iptables -t nat -A PREROUTING -d 2.2.2.2/32 -j DNAT --to-destination 10.10.10.1


    Statt virbr0 kannst du auch nach -s 10.10.10.1 filtern, wenn das die Adresse vom Container ist. Ggf. den Namen der Netzwerkkarte anpassen.

    Die Masquerade Regel kann also raus.

  • Hat mit der Netzmaske nichts zu tun. Du hattest nur die to Parameter falsch.

    Sorry, ich hatte das falsche reinkopiert. Fakt ist, dass wenn ich die Netzmaske hinzufüge, der Container kein Internet mehr sieht. (Ein-und ausgehend.)



    Funktioniert:

    Code
    1. up iptables -t nat -A POSTROUTING -s 10.10.10.1 -j SNAT --to-source 185.243.10.81
    2. up iptables -t nat -A PREROUTING -d 185.243.10.81 -j DNAT --to-destination 10.10.10.1


    Funktioniert nicht:


    Code
    1. up iptables -t nat -A POSTROUTING -s 10.10.10.1 -j SNAT --to-source 185.243.10.81/32
    2. up iptables -t nat -A PREROUTING -d 185.243.10.81/32 -j DNAT --to-destination 10.10.10.1


    Wie auch immer. Das müssen wir jetzt ja nicht Ewigkeiten ausdiskutieren. Danke allen.

  • Hat denn jemand derweil ne working-config mit LXC und Routing auf die Beine gestellt?

    Von welchem Setup Typ reden wir jetzt - eine IP vollständig an den Container durchNATen oder dem Container eine globale IP zuweisen.


    Für ersteres könnte ich glaube ich ein paar iptables Regeln zusammenklopfen, für zweiteres kann ich versuchen, dir was aus meinem Bekanntenkreis zu organisieren.

  • Ich habe einen VPS mit einer zusätzlichen öffentlichen IP. Meine Wunschkonfiguration wäre, dass der Host die Haupt-IP hat und der LXC-Container die zusätzliche IP, ohne NAT, nur Routing/Bridging o. Ä. Wenn du da was organisieren könntest wäre ein Traum.

  • Ich habe einen VPS mit einer zusätzlichen öffentlichen IP. Meine Wunschkonfiguration wäre, dass der Host die Haupt-IP hat und der LXC-Container die zusätzliche IP, ohne NAT, nur Routing/Bridging o. Ä. Wenn du da was organisieren könntest wäre ein Traum.

    Hast Du ein Ubuntu mit netplan am Laufen?

  • So läuft das bei mir.


    Edit: IPv4 Forwarding muss hierfür aktiviert sein.

  • Ich habe einen VPS mit einer zusätzlichen öffentlichen IP. Meine Wunschkonfiguration wäre, dass der Host die Haupt-IP hat und der LXC-Container die zusätzliche IP, ohne NAT, nur Routing/Bridging o. Ä. Wenn du da was organisieren könntest wäre ein Traum.

    Folgendes:

    IP für den Host 1.2.3.4/22

    IP für den Container 5.6.7.8/32


    Deine ens3 machst du ganz normal statisch mit der oberen IP. Und dann legst du dir noch eine vmbr0 (oder ggf. auch vmbr1 oder whatever) an:

    Code
    1. auto vmbr0
    2. iface vmbr0 inet static
    3. address 1.2.3.4/22
    4. bridge_ports none
    5. bridge_stp off
    6. bridge_fd 0
    7. up ip route add 5.6.7.8/32 dev vmbr0


    Dein Container bekommt dann die vmbr0 mit der 5.6.7.8/32 als IP und der 1.2.3.4 als Gateway.


    Ich denke IP Forwarding in /etc/sysctl.conf hast du ja sowieso an - wenn nicht, anschalten und mal sysctl -p machen ;)



    Ich konnte das natürlich jetzt nicht testen - aber so sollte es theoretisch gehen. Am besten einfach mal austesten. IPv6 sollte sich äquivalent verhalten. :)

  • In jedem Fall schon mal Danke!


    IPv4 läuft, v6 noch nicht. Das sind meine Configs:

    Container:


    Woran könnte das nun liegen, dass v4 (wie erwartet) tut, v6 aber nicht? Beide Forwardings in der sysctl sind an. Müssen ggf. für v6 noch mehr Optionen in der sysctl aktiviert werden?


    Viele Grüße
    Matthias

  • Müssen ggf. für v6 noch mehr Optionen in der sysctl aktiviert werden?

    Da gibt es auch nur eine normale Forwarding Funktion, die du einschalten musst. Die heißt net.ipv6.conf.all.forwarding=1 - da musst du nur die Auskommentierung entfernen und neu einlesen.


    Woran könnte das nun liegen, dass v4 (wie erwartet) tut, v6 aber nicht? Beide Forwardings in der sysctl sind an. Müssen ggf. für v6 noch mehr Optionen in der sysctl aktiviert werden?

    Ich meine mal gelesen zu haben, dass es da einen Neighbor Discovery Protocol Daemon (ndpd) brauch... da musst du dich ggf. mal dazu belesen ;)

  • Genau. Installiere Dir den ndppd.


    Setze statt der default rule eine für Dein /64 Netz ein. auto sollte eigentlich super funktionieren. Bei Netcup habe ich zuletzt immer ein extra /64 von irgendwelchen Aktionen auf den Server geroutet, damit brauchte ich sowas nicht mehr.

  • Ok, gelogen. Von extern kann ich den Container jetzt pingen - der kommt aber nicht raus. Ne Idee?

    Klemmt es da vielleicht irgendwo an der Firewall des Proxmox Hosts? Wie weit kommst du mit einem Traceroute? Kannst du den Host vom Container aus pingen?