Docker - Netzwerk - Mehrere Öffentliche IP-Adressen
Hallo,
ich bin neu im Thema Docker und komme mit dem Netzwerk überhaupt nicht zurecht.
Auch nach mehreren Stunden Google Benutzen und Dokumentation durchstöbern finde ich keine Lösung.
Ich bitte euch somit um Nachsicht, falls es für euch zu einfach ist.
Folgendes Szenario:
Ich habe seit Ewigkeiten einen Root-Server, bei dem alles ohne Probleme und wie gewollt funktionierte.
Diesen habe ich nun Spaßeshalber vor 2 Wochen geplättet und Docker installiert.
Mit Portainer zusammen funktioniert alles wie gewollt.
Jetzt kam die Entscheidung dazu, dass ich ein paar Dienste unter einer neuen IP laufen lassen möchte.
Meine derzeitige Konfig.:
IP: YYY.XX.67.129
Gateway: YYY.XX.67.1
Subnet: 255.255.255.255 /32
Netzadresse: YYY.XX.67.0
Meine neue IP-Adresse hat keine eigene Netzadresse.
Sie lautet: VV.UUU.253.21 und ist eine /32er IP.
Nun hab ich aufgrund dessen aber anscheinend ein Problem diese hinzuzufügen.
Laut Support solle ich die YYY.XX.67.1 als Gateway verwenden, doch es klappt leider nicht, da ich die Meldung bekomme:
wenn ich folgendes ausführe:
Und wenn ich das Gateway weglasse, bekomme ich:
wenn ich folgendes Ausführe:
Das Routing habe ich eigentlich schon hinzugefügt über:
Übersehe ich etwas?
Kann es sein, dass ich einen Größeren IP-Block brauche mit der Möglichkeit eine als Gateway zu nehmen?
ich bin neu im Thema Docker und komme mit dem Netzwerk überhaupt nicht zurecht.
Auch nach mehreren Stunden Google Benutzen und Dokumentation durchstöbern finde ich keine Lösung.
Ich bitte euch somit um Nachsicht, falls es für euch zu einfach ist.
Folgendes Szenario:
Ich habe seit Ewigkeiten einen Root-Server, bei dem alles ohne Probleme und wie gewollt funktionierte.
Diesen habe ich nun Spaßeshalber vor 2 Wochen geplättet und Docker installiert.
Mit Portainer zusammen funktioniert alles wie gewollt.
Jetzt kam die Entscheidung dazu, dass ich ein paar Dienste unter einer neuen IP laufen lassen möchte.
Meine derzeitige Konfig.:
IP: YYY.XX.67.129
Gateway: YYY.XX.67.1
Subnet: 255.255.255.255 /32
Netzadresse: YYY.XX.67.0
Meine neue IP-Adresse hat keine eigene Netzadresse.
Sie lautet: VV.UUU.253.21 und ist eine /32er IP.
Nun hab ich aufgrund dessen aber anscheinend ein Problem diese hinzuzufügen.
Laut Support solle ich die YYY.XX.67.1 als Gateway verwenden, doch es klappt leider nicht, da ich die Meldung bekomme:
no matching subnet for gateway YYY.XX.67.1
docker network create --subnet=VV.UUU.253.21/32 --ip-range VV.UUU.253.21/32 --gateway=YYY.XX.67.1 multi-host-network
Und wenn ich das Gateway weglasse, bekomme ich:
Error response from daemon: failed to allocate gateway (): No available addresses on this pool
docker network create --subnet=VV.UUU.253.21/32 --ip-range VV.UUU.253.21/32 multi-host-network
Das Routing habe ich eigentlich schon hinzugefügt über:
ip -4 address add VV.UUU.253.21/32 dev enp2s0 #ip-addresse
ip -4 route add YYY.XX.67.1/32 dev enp2s0 #pointopoint-Route
ip -4 route add default via YYY.XX.67.1 dev enp2s0 #default-gateway
Übersehe ich etwas?
Kann es sein, dass ich einen Größeren IP-Block brauche mit der Möglichkeit eine als Gateway zu nehmen?
Please also mark the comments that contributed to the solution of the article
Content-Key: 399526
Url: https://administrator.de/contentid/399526
Printed on: May 8, 2024 at 02:05 o'clock
14 Comments
Latest comment
Guten Abend,
für die Docker Container vergibt man immer für IPv4 ein RFC1918 Subnetz.
Alles andere wäre nur Verschwendung von IPv4 Adressen...
Wenn du ein Container erstellst, dann kannst du beim Bind Port eine bestimmte IP Adresse vergeben.
Damit wird ein Listener mit dieser IP Adresse und dem Port erstellt.
Viele Grüße,
Exception
für die Docker Container vergibt man immer für IPv4 ein RFC1918 Subnetz.
Alles andere wäre nur Verschwendung von IPv4 Adressen...
Wenn du ein Container erstellst, dann kannst du beim Bind Port eine bestimmte IP Adresse vergeben.
Damit wird ein Listener mit dieser IP Adresse und dem Port erstellt.
Viele Grüße,
Exception
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.
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.
Nebenbei: Direktes weiterleiten ohne NAT an einen einzigen Container ist nicht möglich? LXC/LXD bietet diese Funktion, wie mir bekannt ist. Würde aber gern bei Docker bleiben.
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!
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.
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
Zitat von @aqui:
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.
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.
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:
ip -4 addr add 192.0.2.100/32 dev eth0
ip -4 route add 203.0.113.1/32 dev eth0
ip -4 route add default via 203.0.113.1 dev eth0
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.
Zitat von @129580:
für die Docker Container vergibt man immer für IPv4 ein RFC1918 Subnetz.
Alles andere wäre nur Verschwendung von IPv4 Adressen...
für die Docker Container vergibt man immer für IPv4 ein RFC1918 Subnetz.
Alles andere wäre nur Verschwendung von IPv4 Adressen...
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
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.
Zwar noch nie mit Docker zusammen getestet, aber die werden auch keine Spezialmagie sondern normales iptables mit dem normalen Connection-Tracker benutzen.
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.
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.
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
Eventuell kann Docker mit anderen Ranges nicht umgehen, was sehr schade wäre =(
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:
-p <zweite ip>:<host_port>:<container_port>
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
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
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
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
no matching subnet for range
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
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
Zitat von @norreyy:
ip -4 route add YYY.XX.67.1/32 dev enp2s0 #pointopoint-Route
Wie sich eine IP zusammensetzt und was wofür da ist, ist mir sehr wohl bekannt.
Darum geht es hier auch nicht, es geht wie geschrieben um 2 Öffentliche IP-Adressen, die über ein Gateway müssen. WAs mit Docker nicht funktioniert.
ip -4 route add YYY.XX.67.1/32 dev enp2s0 #pointopoint-Route
Wie sich eine IP zusammensetzt und was wofür da ist, ist mir sehr wohl bekannt.
Darum geht es hier auch nicht, es geht wie geschrieben um 2 Öffentliche IP-Adressen, die über ein Gateway müssen. WAs mit Docker nicht funktioniert.
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:
docker network create --subnet=YYY.XX.67.1/32 --ip-range VV.UUU.253.21/32 --gateway=YYY.XX.67.1
- 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...
subnetting.. schöner teil der ausbildung gewesen.
wenn man die prüfungen ohne tatschenrechner geschafft hat konnte man subnetting.
btw steht 255 in der subnetzmaske für 0 bis 255 sonst wäre 10.0.0.1 ja nicht erlaubt.
/besserwisserischrumtroll
bei ner 10.0.0.128/26 (255.255.255.192) ist die 10.0.0.128 die netz ip, 10.0.0.191 die broadcast ip und der raum da zwischen zuteilungsfähig.
und ja.. /32er sind vor allem bei ovh und anderen großen hostern sehr beliebt.
krebs pur in der konfiguration aber läuft.
wenn man die prüfungen ohne tatschenrechner geschafft hat konnte man subnetting.
btw steht 255 in der subnetzmaske für 0 bis 255 sonst wäre 10.0.0.1 ja nicht erlaubt.
/besserwisserischrumtroll
bei ner 10.0.0.128/26 (255.255.255.192) ist die 10.0.0.128 die netz ip, 10.0.0.191 die broadcast ip und der raum da zwischen zuteilungsfähig.
und ja.. /32er sind vor allem bei ovh und anderen großen hostern sehr beliebt.
krebs pur in der konfiguration aber läuft.