Docker - Netzwerk - Mehrere Öffentliche IP-Adressen

Ist ja auch etwas komisch das der Rechner eine /32er Adresse hat. Das ist eine Hostadresse und würde dann ein Hostrouting erfordern. Kann eigentlich nicht sein.
Der Server bzw. dessen IP dürften niemals eine /32er Host IP haben ! Das müsste in jedem Falle ein größeres Netz sein.
Die weitere IP die du vom Hoster für deinen Container bekommen hast sollte auch Teil dieses Netzes sein sofern der Container per Bridging am Server hängt.
Adress technisch gesehen macht dir o.a. IP Adressierung wenig bis keinen Sinn.

Das geht schon. Dein Ansatz war auch richtig. Du musst bei den Docker Netzwerk eine Bridge einrichten. Siehe auch:
https://docs.docker.com/engine/reference/commandline/network_create/

Aber das macht kein Sinn! Dann bräuchtest du für jeden Container eine extra öffentliche IP!!

Übrigens:
LXC != Docker. Sind zwar beides Container Technologien aber dessen Architektur und Konzepte sind unterschiedlich
Aber selbst unter LXC oder einer anderen Container Technik z.B. OpenVZ bräuchtest du für jeden Container eine öffentliche IP, wenn du nicht NAT machst. Bedenke: pro Container = ein Service!


Kann leider doch sein. Beispielsweise ist das bei Hetzner der Fall.
Für Bridging muss übrigens eine zweite MAC Adresse bei Hetzner angefordert werden und der IP zugewiesen werden.
Diese dann der Bridge bzw. dem Interface zuweisen.

Siehe auch:
https://wiki.hetzner.de/index.php/Virtualisierung
https://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen

Ich hatte ja schonmal angedeutet, dass der inflationäre Gebrauch von Superlativen wie "niemals" deren Nutzer selten in ein gutes Licht rückt
Zum IT-Beruf gehört nämlich, dass das eigene Wissen nicht als abschließend und allumfassend gilt und man immer auch was neues lernen kann.
Denn: Klar kann man /32-Netze benutzen. Das geht immer dann, wenn eine /32-Route für eine einzelne IPv4-Adresse auf eine bereits vorhandene und zu einem anderen Subnetz gehörende IP-Adresse angelegt wurde. Dann hat man sowas.

Aber selbst ohne zusätzliches Subnetz unterstützt Linux schon lange die Verwendung von P-t-P-Adressen. Das spart unterm Strich IP-Adressen, weil du keine Adressen für Broadcast, Network und Gateway verschwendest, da sich bei P-t-P-Adressen ja schon per Definition das Gateway außerhalb des Präfix befinden muss.
Wenn du es ausprobieren willst - unter Linux zu konfigurieren mit:


Damit bindest du eine PtP-Adresse auf eth0, gibst dem System noch an, wie es das Gateway erreicht und kannst dann auch ein Default-Gateway setzen. Einziger Unterschied zu normaler Adresskonfiguration: Du musst eine Route zum Gateway auf das Interface legen.



Ich bin kein Docker-Nutzer und vielleicht habe ich auch andere Einsatz-Szenarien als du - aber diese Krücke mit NAT ist ein absoluter Performance-Albtraum.
Zwar noch nie mit Docker zusammen getestet, aber die werden auch keine Spezialmagie sondern normales iptables mit dem normalen Connection-Tracker benutzen. Und dann lässt sich (so bei mir mit KVM + NAT geschehen) der gesamte Host inklusive aller darauf laufenden Container mit ein paar Tausend SYN-Paketen pro Sekunde aus dem Netzwerk schießen weil der Connection-Tracker vollgelaufen ist.
Wenn ich da dem Container seine eigene IP transparent route, hält der locker um die 2M SYN-Pakete pro Sekunde aus.

Wie gesagt, ich habe da möglicherweise andere Einsatz-Szenarien, aber da ich den Einsatzzweck vom TO auch nicht kenne, könnte es ja durchaus sein, dass auch er eine hohe Zahl Verbindungen erwartet, bei denen das NAT dann die Latschen aufstellt

Guten Abend,


Das ist korrekt. Per default gibt es eine Docker Bridge mit einem Netzwerk für die Container. Wenn ein neuer Container erstellt wird, dann erhält dieser seine IP von diesem Range. Die iptables sorgen dann für das automatische Forwarding zwischen Host und Containern. Das betrifft übrigens nur IPv4.

Bei IPv6 erhält jeder Container ganz normal eine Global Unicast Adresse, d.h. der Container ist öffentlich von außen erreichbar. Da gibts dann kein NAT o.ä. Man kann das natürlich auch mit IPv4 konfigurieren aber das ist quatsch. Dann bräuchte jeder Container eine öffentliche IPv4 Adresse, was schlicht Verschwendung ist. Zumal nicht jeder Container öffentlich erreichbar sein muss. Beispielsweise in Mikroservice Architekturen muss nur der Frontend Service bzw. API erreichbar sein. Aber nicht das ganze Backend.


Bei großen Enterprise Umgebungen kommen Orchestration Plattformen wie Kubernetes zum Einsatz. Dort sieht die Netzwerksache schon wieder ganz anders aus. Üblicherweise kommt dort ein Ingress Controller zum Einsatz und vor dem Ingress Controller steht dann ein Loadbalancer der den Traffic an die Ingress Controller verteilt. Kubernetes überwacht seine Ressourcen automatisch und tut horizontal automatisch skalieren.

VG
Exception

Kann gut sein, dass sowas nicht unterstützt wird. So ein Konstrukt ist eigentlich so nicht vorgesehen. (Macht auch kein Sinn)
Ich würde das einfacher machen. Konfiguriere die zweite IP ganz normal an den Server.

Anschließend den Container mit diesem Parameter starten:

Guten Morgen norreyy!

Ich habe mir jetzt mal die Frage und alle Kommentare dazu durchgelesen. Vorweg: Ich bin kein Docker Nutzer, aber das Problem liegt meiner Meinung nach auf der Hand.

1.) Du versuchst auf einer physischen Ethernetschnittstelle IP-Kommunikation zu etablieren. Ich habe in den Posts von dir keine Hinweise gefunden, dass du Punkt-Zu-Punkt Verbindungen verwendest oder verwenden willst.

2.) Du bekommst eh schon das Feedback, das dir den Fehler zeigt, nämlich

Ein kleiner Exkurs in die Netzwerkadressierung:
Ich hole hier ein bisschen weiter aus, ich glaube/hoffe es dient dem Gesamt-Verständnis, auch wenn Teilbereiche möglicherweise nur indirekt zur Problemlösung beitragen.

Wie bereits von Lord Gurke erwähnt gibt es in einem IPv4 basierten Netzwerk drei wichtige Adressen, nämlich

• IP-Subnet: Der Beginn des adressierbaren Segments
• IP-Adresse: Eine Adresse innerhalb des adressierbaren Segments
• IP-Broadcast: Die letzte IP Adresse im Segment, die für ungerichtete Netzwerkpakete (=Broadcasts) verwendet wird

Über den IP Broadcast laufen dann so lustige Dinge wie Discover-Protokolle, upnp, usw..

Beinahe jeder 08/15 Router aus dem Verbrauchersegment vergibt dir mit Default-Config eine Adresse aus dem Netz 192.168.x.x, als Beispiel nehme ich jetzt mal 192.168.1.1 als Router Adresse.
In der Regel kann man an solchen Routern IP Adressen zwischen 192.168.1.2 (weil 192.168.1.1 ja der Router ist) und 192.168.1.254 IP Adressen vergeben bzw. bekommen.
In dem Fall sind

• IP-Subnet: 192.168.1.0
• IP-Adresse: 192.168.1.1 (des Routers)
• IP-Broadcast: 192.168.1.255

Nachdem wir es bei Netzwerktechnik und IP Adressen eigentlich nur mit von Menschen einfach lesbaren Bit-Registern in der Größe von 2^8 Bit zu tun haben (=256 Zustandsmöglichkeiten, daher können die einzelnen Notationen in IP Adressen nie mehr als 255 oder weniger als 0 betragen) können wir mit der sogn. Subnetzmaske angeben, welche IP Adressen sich tatsächlich mit uns unterhalten können/dürfen.

Im Beispielfall wäre die Subnetzmaske 255.255.255.0; die Zahlen der einzelnen Notationen geben an, welcher Teil der IP Adresse eines Hosts gegenüber anders sein darf und welcher nicht. Die Zahl selbst gibt dann noch darüber Auskunft, um welchen Wert sich die IP Adresse selbst vom gegenüber unterscheiden darf.
255 heißt hier: dieser Teil der IP Adresse von gegenüber darf sich NICHT verändern
0 heißt hier: dieser Teil der IP Adresse kann von 1-254 bzw. 1-255 (inkl. Broadcast) sein.
Im Beispiel heißt das:
Wir können mit einer IP Adresse 192.168.1.1 und einer Subnetzmaske 255.255.255.0 andere Netzwerkteilnehmer erreichen, die zwar mit 192.168.1. beginnen müssen, die letzte Stelle der IP Adresse jedoch von 1-254 bzw. 1-255 haben können. Damit 2-Wege Kommunikation ganz sicher funktioniert sollte das gegenüber ebenfalls die selbe Subnetzmaske haben.

CIDR-Notation
Nachdem in die IP Subnetze selbst nur bestimmte Größen haben können (bedingt durch Binärsystem und der Tatsache, dass es ein IP-Subnetz und eine IP Broadcast-Adresse geben MUSS), haben sich einige kluge Köpfe die CIDR Notation überlegt; diese Schreibweise sagt einem nicht mehr, welche Subnetzmaske man hat und welche Zahlen drin stehen, sie sagt einem schlicht wie viele der Bits einer fremden IP Adresse gleich (sprich: wie viele Bits in der Subnetzmaske=1) sein müssen und lässt im Umkehrschluss dann die Information zu, wie viele Adressen wir in dem Subnetz erreichen können.

In unserem Beispiel mit 192.168.1.1 und der Subnetzmaske 255.255.255.0 sind die ersten 24 Bits fixiert (255 ist in Binär 1111 1111) und nur die letzten 8 sind veränderbar.
Die CIDR Notation der IP Adresse (!) unseres Beispiels wäre damit 192.168.1.1/24


TL;DR
Die CIDR Notation deiner IP Adressen ist /32. Obwohl dies, rein theoretisch für virtuelle Adapter, wie z.B. VPN Einwahl, möglich wäre, ist dies in einem Ethernet, speziell so wie du das geschrieben hast, eher ungewöhnlich. Die Tatsache, dass du versucht hast eine Route und ein Gateway zu definieren sagt mir eigentlich schon auch alles darüber, dass es sich hier nicht um Punkt-Zu-Punkt in Ethernet handelt sondern um ein ganz "normales" Ethernet Setup.

/32 würde nämlich bedeuten, dass IP Subnetz, IP Adresse und IP Broadcast immer die selbe IP Adresse wären. Damit kann der Rechner sich im Ethernet de facto nur sich selbst adressieren.

Für deine internen IP Adressen gehe ich persönlich jetzt ganz einfach mal davon aus, dass du /24er Adressen definiert haben wirst, weil's de facto usus ist und von den private IPs eh eine ganze Menge zur Verfügung stehen.
Um die Subnetzmaske (und damit die richtige CIDR Notation) für deine PUBLIC IPs zu bekommen würde ich dir vorschlagen entweder
a.) auf deinem Gateway nach zusehen, was denn hier eingetragen ist und die Einträge für CIDR oder Subnetzmaske auf deine Docker-Maschine zu übertragen oder
b.) deinen Internetprovider zu befragen, damit es hier zu keinen Fehlkonfigurationen kommt.


Hier noch ein externer Link zu einem CIDR-Rechner, den ich persönlich ganz gerne benutze, der dir dabei helfen kann Subnetzmasken in CIDR-
Notation umzuwandeln: http://www.subnet-calculator.com/cidr.php

Abschließend noch ein kleiner Berechnungs-Trick:
Wird die Zahl der CIDR Notation KLEINER, dann verdoppelt sich die Anzahl der adressierbaren IP Adressen im Subnetz. /23 zB. sind dann 512 IP Adressen (inkl. Broadcast und IP Subnet-Adresse)
Wird die Zahl der CIDR Notation GRÖSSER, dann halbiert sich die Anzahl der adressierbaren IP Adressen im Subnet. /25 zB sind dann 128 IP Adressen (inkl. Broadcast und IP Subnet-Adresse)


Ich hoffe ich konnte in irgendeiner Art und Weise helfen und wünsche noch einen schönen Sonntag!
lG
Areanod

Damn, das hab ich tatsächlich übersehen, sry...

Ich hab mir mal die Config-Zeile, die du im ursprünglichen Post geschrieben hast, genauer angesehen und würde folgendes vorschlagen:

• Wenn der Switch --subnet nämlich das IP-Subnetz angibt, dann müsstest du hier (rein theoretisch) die zu adressierende IP angeben, in deinem Fall die IP vom Gateway. Deswegen (vermutlich) auch der Subnetz-Error, den dir Docker ausgibt?
• Das nachführende multi-host-network widerspricht in meiner persönlichen Logik der Tatsache, dass das angegeben Netzwerk Point-To-Point sein soll. Wenn das ein Switch oder eine Option für docker network create sein soll, dann würde ich mal recherchieren, ob es hier einen eigenen Switch oder Option für Point-To-Point Verbindungen gibt.

Selbstverständlich muss am Gateway die Konfiguration auch entsprechend eingestellt sein (deine IP als Subnetz), sonst kann das GW nicht antworten; sollte aber dein Provider schon gemacht haben...


Eine weitere Idee: Wenn mein Vorschlag auf den ersten Anhieb NICHT funktioniert hat, versuch mal /31 anstatt /32; theoretisch wäre in einem /32 nämlich wirklich nur ein Rechner adressierbar, wird von den meisten Netzwerksoftwaren aber trotzdem korrekt interpretiert. Möglicherweise hat Docker da irgendwelche Eigenarten..

Schönen Abend
Areanod

Edit: Wenn du die IP Adresse deines GWs geheim halten willst solltest du deinen ersten Post nochmal editieren...