Docker und iptables sowie Implementierung von Netzwerkisolations- und Kommunikationsvorgängen im Bridge-Modus
|
Docker bietet mehrere Netzwerke wie Bridge, Host, Overlay usw. Auf demselben Docker-Host befinden sich gleichzeitig mehrere unterschiedliche Netzwerktypen, und Container in unterschiedlichen Netzwerken können nicht miteinander kommunizieren. Die netzwerkübergreifende Isolierung und Kommunikation von Docker-Containern wird mit Hilfe des iptables-Mechanismus erreicht. Die Filtertabelle von iptables ist standardmäßig in drei Ketten unterteilt: INPUT, FORWARD und OUTPUT. Docker bietet außerdem eine eigene Kette in der FORWARD-Kette (Weiterleitung an eine benutzerdefinierte Kette), um Isolation und Kommunikation zwischen Bridge-Netzwerken zu erreichen. Grundlegende Docker-Netzwerkkonfiguration
Beim Start von Docker wird auf dem Host automatisch eine virtuelle Docker0-Brücke erstellt. Tatsächlich handelt es sich um eine Linux-Brücke, die als Software-Switch verstanden werden kann. Es leitet den Datenverkehr zwischen den angeschlossenen Netzwerkports weiter. Gleichzeitig weist Docker der Docker0-Schnittstelle zufällig eine Adresse in einem lokalen, unbesetzten privaten Netzwerksegment zu. Die typische IP-Adresse ist beispielsweise 172.17.0.1 und die Maske 255.255.0.0. Auch dem Netzwerk-Port im nachfolgend gestarteten Container wird automatisch eine Adresse im gleichen Netzwerksegment (172.17.0.0/16) zugewiesen. Beim Erstellen eines Docker-Containers wird gleichzeitig ein Paar von Veth-Paarschnittstellen erstellt (wenn ein Datenpaket an eine Schnittstelle gesendet wird, kann die andere Schnittstelle dasselbe Datenpaket auch empfangen). Ein Ende dieses Schnittstellenpaars befindet sich im Container, nämlich eth0; das andere Ende ist lokal und an der Docker0-Bridge gemountet, mit einem Namen, der mit veth beginnt (z. B. veth1). Auf diese Weise kann der Host mit dem Container kommunizieren und die Container können miteinander kommunizieren. Docker erstellt ein virtuelles gemeinsames Netzwerk zwischen dem Host und allen Containern. 1. Docker-Kette in der Filtertabelle von iptables In Docker 18.05.0 (2018.5) und späteren Versionen werden die folgenden vier Ketten bereitgestellt:
Derzeit sind die Standard-IPtables-Einstellungen von Docker für den Host in der Datei /etc/sysconfig/iptables aufgeführt. ##Adressweiterleitungstabelle NAT-Regelkette und Standard-*NAT #PREROUTING Regelkette Standardrichtlinie ist ACCEPT :PREROUTING AKZEPTIEREN [0:0] #INPUT Regelkette Standardrichtlinie ist ACCEPT :EINGABE AKZEPTIEREN [0:0] #OUTPUT Regelkette Standardrichtlinie ist ACCEPT :AUSGABE AKZEPTIEREN [4:272] #Die Standardrichtlinie der POSTROUTING-Regelkette ist ACCEPT :POSTROUTING AKZEPTIEREN [4:272] #Die Standardrichtlinie der DOCKER-Regelkette lautet ACCEPT :DOCKER - [0:0] ##############################In der PREROUTING-Regelkette hinzugefügte Regeln############################### ##-m bedeutet, dass das Erweiterungsmodul zum Abgleichen von Paketen verwendet wird. Wenn der Zieladresstyp des Pakets, das auf dem lokalen Computer ankommt, ein lokales Netzwerk ist, wird es der DOCKER-Kette zugewiesen -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER ##############################In der OUTPUT-Regelkette hinzugefügte Regeln############################## -A AUSGABE ! -d 127.0.0.0/8 -m Adresstyp --Zieltyp LOKAL -j DOCKER ##############################Zur POSTROUTING-Regelkette hinzugefügte Regeln############################### ##Diese Regel soll dem Container die Kommunikation mit dem externen Netzwerk ermöglichen. #Die Pakete mit der Quelladresse 192.168.0.0/20 (also vom Docker-Container generierte Pakete), die nicht von der Docker0-Netzwerkkarte gesendet werden, #werden in die Adresse der Host-Netzwerkkarte konvertiert. -A POSTROUTING -s 192.168.0.0/20 ! -o docker0 -j MASQUERADE #####################################Zur DOCKER-Regelkette hinzugefügte Regeln############################### #Das von der Schnittstelle docker0 eingegebene Datenpaket wird an die Aufrufkette zurückgegeben; -i gibt an, von welcher Schnittstelle das Datenpaket verarbeitet werden soll -A DOCKER -i docker0 -j RETURN ############################################################################### ##Ketten und Standardrichtlinien in der Regeltabelle*Filter :EINGABEABFALL [4:160] :Weiterleiten Annehmen [0:0] :AUSGABE AKZEPTIEREN [59:48132] :DOCKER - [0:0] :DOCKER-ISOLATION-STUFE-1 - [0:0] :DOCKER-ISOLATION-STUFE-2 - [0:0] :DOCKER-USER - [0:0] #####################################In der FORWARD-Regelkette hinzugefügte Regeln################################ ##Alle Datenpakete werden der DOCKER-USER-Kette zugewiesen -A FORWARD -j DOCKER-USER ##Alle Datenpakete werden der Kette DOCKER-ISOLATION-STAGE-1 zugewiesen -A FORWARD -j DOCKER-ISOLATION-STAGE-1 -A WEITER -o docker0 -m conntrack --ctstate VERWANDTE, HERGESTELLTE -j AKZEPTIEREN ##Von der Schnittstelle docker0 ausgegebene Datenpakete werden der DOCKER-Kette zugewiesen -A FORWARD -o docker0 -j DOCKER ##Datenpakete, die von der Docker0-Schnittstelle eingegeben und nicht von der Docker0-Schnittstelle ausgegeben werden, dürfen passieren -A FORWARD -i docker0 ! -o docker0 -j ACCEPT ##Von der Docker0-Schnittstelle eingegebene Datenpakete und von der Docker0-Schnittstelle ausgegebene Datenpakete dürfen passieren -A FORWARD -i Docker0 -o Docker0 -j ACCEPT ###########################Regeln zur Regelkette DOCKER-ISOLATION-STAGE-1 hinzugefügt################### ##Datenpakete, die von der Docker0-Schnittstelle eingegeben, aber nicht von der Docker0-Schnittstelle ausgegeben werden, werden der DOCKER-ISOLATION-STAGE-2-Kette zugewiesen.##Das heißt, Datenpakete von Docker0 zu verarbeiten, aber nicht von Docker0 auszugeben -A DOCKER-ISOLATION-STAGE-1 -i Docker0 ! -o Docker0 -j DOCKER-ISOLATION-STAGE-2 ##Das Datenpaket kehrt direkt zur Aufrufkette zurück -A DOCKER-ISOLATION-STAGE-1 -j RETURN ###########################Regeln zur Regelkette DOCKER-ISOLATION-STAGE-2 hinzugefügt################### ##Von der Docker0-Schnittstelle ausgegebene Datenpakete werden verworfen -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP ##Das Datenpaket kehrt direkt zur Aufrufkette zurück -A DOCKER-ISOLATION-STAGE-2 -j RETURN ######################################Zur DOCKER-USER-Regelkette hinzugefügte Regeln################################ ##Kehre direkt zur Aufrufkette zurück -A DOCKER-USER -j RETURN 2. Dockers DOCKER-Kette Es werden nur IP-Pakete vom Host an Docker0 verarbeitet. 3. Dockers DOCKER-ISOLATION-Kette (Isolierung der Kommunikation zwischen verschiedenen Bridge-Netzwerken) Wie Sie sehen, bietet Docker zwei Implementierungen der Stufe DOCKER-ISOLATION, um die Kommunikation zwischen verschiedenen Bridge-Netzwerken zu isolieren. Die Kette DOCKER-ISOLATION-STAGE-1 filtert Pakete, deren Quelladresse das Bridge-Netzwerk ist (standardmäßig docker0). Passende Pakete werden dann von der Kette DOCKER-ISOLATION-STAGE-2 verarbeitet. Wenn keine Übereinstimmung vorliegt, kehren Sie zur übergeordneten Kette zurück. In der Kette DOCKER-ISOLATION-STAGE-2 werden Pakete weiterverarbeitet, deren Zieladresse das Bridge-Netzwerk ist (standardmäßig docker0). Übereinstimmende Pakete weisen darauf hin, dass das Paket von einem Bridge-Netzwerk an ein anderes Bridge-Netzwerk gesendet wird. Solche Pakete aus anderen Bridge-Netzwerken werden direkt verworfen. Nicht übereinstimmende Datenpakete werden zur nachfolgenden Verarbeitung an die übergeordnete Kette weitergeleitet. 4. Dockers DOCKER-USER-Kette Beim Start von Docker werden die Filterregeln in der DOCKER-Kette und der DOCKER-ISOLATION-Kette (jetzt DOCKER-ISOLATION-STAGE-1) geladen und wirksam gemacht. Es ist absolut verboten, hier die Filterregeln zu verändern. Wenn Benutzer die Filterregeln von Docker ergänzen möchten, wird dringend empfohlen, sie an die DOCKER-USER-Kette anzuhängen. Die Filterregeln in der DOCKER-USER-Kette werden vor den von Docker erstellten Standardregeln geladen (in der obigen Regelliste wird die DOCKER_USER-Kette zuerst an die Regelkette angehängt) und überschreiben somit die Standardfilterregeln von Docker in der DOCKER-Kette und der DOCKER-ISOLATION-Kette. Beispielsweise darf nach dem Start von Docker standardmäßig jede externe Quell-IP weitergeleitet werden, sodass jede Docker-Containerinstanz auf dem Host von der Quell-IP aus verbunden werden kann. Wenn Sie nur einer bestimmten IP den Zugriff auf die Containerinstanz erlauben, können Sie Routing-Regeln in die DOCKER-USER-Kette einfügen, sodass sie vor der DOCKER-Kette geladen werden kann. Hier ist ein Beispiel: #Erlauben Sie nur 192.168.1.1, auf den Container zuzugreifen iptables -A DOCKER-USER -i docker0 ! -s 192.168.1.1 -j DROP #Erlauben Sie nur IPs im Netzwerksegment 192.168.1.0/24, auf den Container zuzugreifen iptables -A DOCKER-USER -i docker0 ! -s 192.168.1.0/24 -j DROP #Erlauben Sie nur IPs im Netzwerksegment 192.168.1.1-192.168.1.3, auf den Container zuzugreifen (erfordert das Modul „iprange“) iptables -A DOCKER-USER -m iprange -i docker0 ! --src-range 192.168.1.1-192.168.1.3 -j DROP 5. Docker-Regeln in der NAT-Tabelle von iptables Um vom Container aus auf andere Docker-Hosts zugreifen zu können, muss Docker Weiterleitungsregeln in die POSTROUTING-Kette in der Nat-Tabelle von iptables einfügen. Das Beispiel sieht wie folgt aus: iptables -t nat -A POSTROUTING -s 172.18.0.0/16 -j MASQUERADE Die obige Konfiguration schränkt den IP-Bereich der Containerinstanz weiter ein, um zwischen Situationen zu unterscheiden, in denen sich auf dem Docker-Host mehrere Bridge-Netzwerke befinden. 6. Das Ändern der iptables-Filtertabelle ist in Docker verboten Beim Start von Dockerd ist der Parameter --iptables standardmäßig auf „true“ gesetzt, was bedeutet, dass die iptables-Routingtabelle geändert werden kann. Um diese Funktion zu deaktivieren, haben Sie zwei Möglichkeiten: Startparameter festlegen --iptables=false Ändern Sie die Konfigurationsdatei /etc/docker/daemon.json und setzen Sie "iptables": "false". Führen Sie dann systemctl reload docker aus, um neu zu laden Zusatzwissen: Docker-Netzwerkmodus Standard-Bridge-Modus Wie oben erwähnt, gibt es fünf Netzwerkmodi für Docker, nämlich Birdge, Host, Overlay, Nacvlan, Keine und Netzwerk-Plugin. Hier stellen wir hauptsächlich den Standard-Bridge-Modus von Bridge vor. 1. Einleitung In Netzwerkkonzepten ist eine Brücke ein Gerät der Verbindungsschicht, das den Datenverkehr zwischen Netzwerksegmenten weiterleitet. Eine Netzwerkbrücke ist ein Hardware- oder Softwaregerät, das auf dem Hostkernel ausgeführt wird. In Docker verwendet das Bridge-Netzwerk Software-Bridging. Container, die mit demselben Bridge-Netzwerk verbunden sind, können direkt und mit vollen Ports miteinander kommunizieren und sind direkt von Containern isoliert, die nicht mit dem Bridge-Netzwerk verbunden sind. Auf diese Weise verwaltet das Bridge-Netzwerk die Verbindung und Isolierung aller Container auf demselben Host. Der Bridge-Treiber von Docker installiert automatisch Regeln auf dem Host, sodass Netzwerke auf derselben Bridge miteinander kommunizieren können und Container auf verschiedenen Bridge-Netzwerken voneinander isoliert sind. Bridge Networking ist auf Container anwendbar, die vom Docker-Daemon auf demselben Host generiert werden. Verwenden Sie für Interaktionen zwischen Containern auf verschiedenen Hosts entweder Routing-Operationen auf Betriebssystemebene oder den Overlay-Netzwerktreiber. Wenn wir Docker starten, systemctl start docker, wird automatisch ein Standard-Bridge-Netzwerk (birbr0) erstellt, um den Docker-Daemon mit dem Host-Computer zu verbinden, und ein Netzwerk docker0 wird erstellt. Nachfolgende Container stellen automatisch eine Verbindung zum Bridge-Netzwerk (docker0) her. Wir können die lokale Brücke anzeigen. Jedes Mal, wenn ein Container erstellt wird, wird eine neue Brücke erstellt, um den Container mit dem Standardbrückennetzwerk zu verbinden. [root@localhost hadoop]# brctl zeigen Bridge-Name Bridge-ID STP-fähige Schnittstellen docker0 8000.0242b47b550d nein virbr0 8000.52540092a4f4 ja virbr0-nic [root@localhost hadoop] Die Brücke virbr0 verbindet Docker0 und den Host-Rechner. Auf der Brücke wird eine Schnittstelle virbr0-nic angelegt, die Daten vom Docker0-Netzwerk empfängt. Bei jeder Containergenerierung wird eine neue Schnittstelle auf Docker0 erstellt und die Adresse von Docker0 als Gateway des Containers festgelegt. [root@localhost hadoop]# docker run --rm -tdi nvidia/cuda:9.0-base [root@localhost hadoop]# docker ps CONTAINER ID BILD BEFEHL ERSTELLT STATUS PORTS NAMEN 9f9c2b80062f nvidia/cuda:9.0-base "/bin/bash" vor 15 Sekunden Up 14 Sekunden quizzical_mcnulty [root@localhost hadoop]# brctl zeigen Bridge-Name Bridge-ID STP-fähige Schnittstellen docker0 8000.0242b47b550d nein vethabef17b virbr0 8000.52540092a4f4 ja virbr0-nic [root@localhost hadoop] Lokale Netzwerkinformationen anzeigen ifconfig -a [root@localhost hadoop]# ifconfig -a
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.1 Netzmaske 255.255.240.0 Broadcast 192.168.15.255
inet6 fe80::42:b4ff:fe7b:550d Präfixlänge 64 Bereichs-ID 0x20<link>
Ether 02:42:b4:7b:55:0d txqueuelen 0 (Ethernet)
RX-Pakete 37018 Bytes 2626776 (2,5 MiB)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 46634 Bytes 89269512 (85,1 MiB)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.252.130 Netzmaske 255.255.255.0 Broadcast 192.168.252.255
Ether 00:25:90:e5:7f:20 txqueuelen 1000 (Ethernet)
RX-Pakete 14326014 Bytes 17040043512 (15,8 GiB)
RX-Fehler 0 verloren 34 Überläufe 0 Frame 0
TX-Pakete 10096394 Bytes 3038002364 (2,8 GiB)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
Gerätespeicher 0xfb120000-fb13ffff
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
Ether 00:25:90:e5:7f:21 txqueuelen 1000 (Ethernet)
RX-Pakete 0 Bytes 0 (0,0 B)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 0 Bytes 0 (0,0 B)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
Gerätespeicher 0xfb100000-fb11ffff
lo: Flags = 73 <UP, LOOPBACK, RUNNING> mtu 65536
inet 127.0.0.1 Netzmaske 255.0.0.0
inet6 ::1 Präfixlänge 128 Bereichs-ID 0x10<Host>
loop txqueuelen 0 (Lokaler Loopback)
RX-Pakete 3304 Bytes 6908445 (6,5 MiB)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 3304 Bytes 6908445 (6,5 MiB)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
oray_vnc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1200
inet 172.1.225.211 Netzmaske 255.0.0.0 Broadcast 172.255.255.255
Ether 00:25:d2:e1:01:00 txqueuelen 500 (Ethernet)
RX-Pakete 1944668 Bytes 227190815 (216,6 MiB)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 2092320 Bytes 2232228527 (2,0 GiB)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
vethabef17b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e47d:4eff:fe87:39d3 Präfixlänge 64 Bereichs-ID 0x20<link>
Ether e6:7d:4e:87:39:d3 txqueuelen 0 (Ethernet)
RX-Pakete 0 Bytes 0 (0,0 B)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 8 Bytes 648 (648,0 B)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 Netzmaske 255.255.255.0 Broadcast 192.168.122.255
Ether 52:54:00:92:a4:f4 txqueuelen 0 (Ethernet)
RX-Pakete 0 Bytes 0 (0,0 B)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 0 Bytes 0 (0,0 B)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0
virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500
Ether 52:54:00:92:a4:f4 txqueuelen 500 (Ethernet)
RX-Pakete 0 Bytes 0 (0,0 B)
RX-Fehler 0 verloren 0 Überläufe 0 Frame 0
TX-Pakete 0 Bytes 0 (0,0 B)
TX-Fehler 0 verloren 0 Überläufe 0 Träger 0 Kollisionen 0Docker kombiniert die Bridge- und Routing-Regeln, um die Interaktion zwischen Containern auf demselben Hostcomputer einzurichten. Unter dem Docker Container Bridge-Netzwerktreiber wird die Netzwerkzugriffsmethode in der folgenden Abbildung angezeigt:
Wenn beim Starten des Containers eine Portzuordnung angegeben wird, ordnen Sie den internen Port 80 dem Host-Port 8080 zu. Sie können die Netzwerkkarte auch in 0.0.0.0:8080 wie folgt angeben
Überprüfen Sie dann die Routing-Tabelle.
Sie können sehen, dass die Routing-Weiterleitungsregeln hinzugefügt wurden: [root@localhost hadoop]# iptables -t nat -vnL Chain PREROUTING (Richtlinie ACCEPT 55 Pakete, 2470 Bytes) pkts Bytes Ziel Schutz Opt-in Out Quelle Ziel 161K 8056K PREROUTING_direkt alle -- * * 0.0.0.0/0 0.0.0.0/0 161K 8056K PREROUTING_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 161K 8056K PREROUTING_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DOCKER alle -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE entspricht Zieltyp LOCAL Chain INPUT (Richtlinie ACCEPT 0 Pakete, 0 Bytes) pkts Bytes Ziel Schutz Opt-in Out Quelle Ziel Chain OUTPUT (Richtlinie ACCEPT 0 Pakete, 0 Bytes) pkts Bytes Ziel Schutz Opt-in Out Quelle Ziel 3442 258K OUTPUT_direkt alle -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DOCKER alle -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE entspricht Zieltyp LOCAL Chain POSTROUTING (Richtlinie ACCEPT 0 Pakete, 0 Bytes) pkts Bytes Ziel Schutz Opt-in Out Quelle Ziel 0 0 MASQUERADE alle -- * !docker0 192.168.0.0/20 0.0.0.0/0 0 0 RETURN alle -- * * 192.168.122.0/24 224.0.0.0/24 0 0 RETURN alle -- * * 192.168.122.0/24 255.255.255.255 0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq-Ports: 1024-65535 0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq-Ports: 1024-65535 0 0 MASQUERADE alle -- * * 192.168.122.0/24 !192.168.122.0/24 3442 258K POSTROUTING_direct alle -- * * 0.0.0.0/0 0.0.0.0/0 3442 258K POSTROUTING_ZONES_SOURCE alle -- * * 0.0.0.0/0 0.0.0.0/0 3442 258K POSTROUTING_ZONES alle -- * * 0.0.0.0/0 0.0.0.0/0 0 0 MASQUERADE tcp -- * * 192.168.0.3 192.168.0.3 tcp dpt:80 Chain DOCKER (2 Referenzen) pkts Bytes Ziel Schutz Opt-in Out Quelle Ziel 0 0 RETURN alle --docker0 * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 bis:192.168.0.3:80 Der Standard-Porttyp ist TCP. 2. Konfiguration des Zugriffs zwischen Containern Starten Sie zuerst zwei Container, betreten Sie dann den Container und überprüfen Sie die IP-Informationen jedes Containers. [root@localhost hadoop]# docker ps CONTAINER ID BILD BEFEHL ERSTELLT STATUS PORTS NAMEN 462751a70444 nvidia/cuda:9.0-base "/bin/bash" vor 17 Minuten Vor 17 Minuten 0.0.0.0:8080->80/tcp sad_heyrovsky 9f9c2b80062f nvidia/cuda:9.0-base "/bin/bash" vor 41 Minuten Up 41 Minuten quizzical_mcnulty [root@localhost hadoop] Ich starte hier zwei Container und rufe dann „docker inspect container ID“ auf, um die Container-IP anzuzeigen
Unsere beiden Container sind 192.168.0.2 192.168.0.3 Rufen Sie einen der Container auf und pingen Sie eine andere Maschine an. Sie werden feststellen, dass die einzige Möglichkeit zum Pingen darin besteht, den Adressmodus zu verwenden: ping 192.168.0.3.
Wenn Sie einen Alias zu /etc/hosts hinzufügen und dann den Namen anpingen, werden Sie feststellen, dass kein Ping möglich ist.
Was den Grund dafür angeht, werden im nächsten Artikel benutzerdefinierte Bridge-Netzwerke zur Lösung dieses Problems näher erläutert. Der obige Artikel über Docker und iptables sowie die Implementierung der Netzwerkisolation und des Kommunikationsbetriebs im Bridge-Modus ist der gesamte Inhalt, den der Herausgeber mit Ihnen teilt. Ich hoffe, er kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen. Das könnte Sie auch interessieren:
|
<<: So optimieren Sie MySQL-Indizes
>>: Detaillierte Einführung in Robots.txt
Artikel empfehlen
Detaillierte Verwendung von Echarts in vue2 vue3
Inhaltsverzeichnis 1. Installation 2. Verwenden S...
Der Unterschied zwischen ENTRYPOINT und CMD in Dockerfile
Im Lernprogramm zum Docker-System haben wir geler...
So fügen Sie Emoji-Ausdrücke in MySQL ein
Vorwort Als ich heute ein Feedback-Formular für e...
So zeigen Sie verfügbare Netzwerkschnittstellen in Linux an
Vorwort Die häufigste Aufgabe nach der Installati...
Lebenszyklus und Ausführungsreihenfolge von React-Class-Komponenten
1. Zwei Möglichkeiten zum Definieren von Reaktion...
HTML-Tabellen-Tag-Tutorial (24): horizontales Ausrichtungsattribut der Zeile ALIGN
In horizontaler Richtung können Sie die Zeilenaus...
React implementiert Import und Export von Excel-Dateien
Inhaltsverzeichnis Präsentationsschicht Geschäfts...
So implementieren Sie abgerundete Ecken mit CSS3 unter Verwendung von JS
Ich bin auf ein Beispiel gestoßen, als ich nach e...
Einführung in das Versionsverwaltungstool Rational ClearCase
Rational ClearCase ist ein Tool für das Softwarek...
Einfaches Verständnis und Beispiele für MySQL Index Pushdown (ICP)
Vorwort Index Condition Pushdown (ICP) ist eine n...
Docker View-Prozess, Speicher und Cup-Verbrauch
Docker-Ansichtsprozess, Speicher, Cup-Verbrauch S...
Zusammenfassung und Praxis des Javascript-Prototyp-Kettendiagramms
Inhaltsverzeichnis Prototypenkette Wir können ein...
Vergleich der Leistung von int, char und varchar in MySQL
Im Internet kursieren viele scheinbar wahre „Gerü...
Detaillierter Informationsaustausch über das MySQL-Protokollsystem
Jeder, der schon einmal an einem großen System ge...
Detaillierte Erläuterung des Linux-Befehls zur Änderung des Hostnamens
Linux-Befehl zum Ändern des Hostnamens 1. Wenn Si...