☰

Docker-Container können nicht mit Subnetzen kommunizieren, der Docker-Host jedoch schon. Wie finde ich heraus, wo die Pakete abgelegt werden?

tag-icon • tag-icon networking iptables docker openvpn ipv6
Docker-Container können nicht mit Subnetzen kommunizieren, der Docker-Host jedoch schon. Wie finde ich heraus, wo die Pakete abgelegt werden?

Wir haben ein Setup, bei dem wir einen Docker-Container haben, der über IPv6 mit Geräten in einem VPN (OpenVPN) kommunizieren muss. Dies geschieht durch den Aufbau einer Brücke zwischen den Docker-Netzwerken und der Tap0-Schnittstelle auf dem Host.

Die Endgeräte senden eine Nachricht an den Docker-Container und erwarten eine Bestätigungsnachricht zurück. Diese befinden sich jedoch in unterschiedlichen Subnetzen, wobei sich der Container und der Host im bbbb::/64Subnetz befinden und die Geräte im abcd::/64(zur Veranschaulichung). Es gibt ein Gateway, bbbb::abcd:2das den Verkehr von einem Subnetz zum anderen weiterleitet, und der Docker-Host verfügt hierfür über eine Gateway-Konfiguration.

Deutlich sein:

bbbb::4001 <--> bbbb::2105 <--> bbbb::abcd:2 <--> abcd::/64

Wobei bbbb::4001die Adresse des Containers ist; bbbb::2105die Adresse des Hosts ist; bbbb::abcd2die Adresse des Gateway-Geräts ist; abcd::/64das Subnetz ist, in dem sich die Endgeräte befinden.

Bei der Verwendung tsharkauf dem Host und dem Gateway beobachten wir Folgendes:

  1. Der Host kann direkt mit Endgeräten im abcd-Subnetz kommunizieren (mit Traceroute überprüft, konnte Pakete auf dem Host und dem Gateway sehen);
  2. Der Docker-Container kann mit dem Gateway kommunizieren (mit Ping überprüft, konnte Pakete auf dem Host und dem Gateway sehen);
  3. der Docker-Containerkonnte nichtKommunizieren Sie direkt mit Endgeräten im abcd-Subnetz: Wir konnten die Pakete auf dem Host auf dieselbe Weise sehen, wie wir sie für die Kommunikation des Hosts gesehen haben, aber wir haben nichts am Gateway ankommen sehen.

Wir haben versucht, iptablesdie Regeln zu ändern, um weitergeleitete Pakete zuzulassen (z. B. indem wir die Standardrichtlinie der FORWARDKette auf festgelegt haben ACCEPT), aber ohne Erfolg.

Wir sind uns nicht sicher, wo wir bei diesem Problem suchen sollen, denn es scheint, dass Pakete aus dem Docker-Container, die für das Subnetz bestimmt sind, in dem er sich nicht befindet, gelöscht werden.irgendwoauf dem Host, ODER vielleicht an den falschen Ort gesendet, aber wir sehen sie auf der br0Schnittstelle des Hosts, sie kommen einfach nie am Gateway an. Wenn der Docker-Container versucht, mit Dingen im selben Subnetz wie er zu kommunizieren, funktioniert es.

Wo fange ich an, danach zu suchen?

Antwort1

Das Problem hing mit der Netzwerkfunktion von Docker zusammen. Wir hatten ein Docker-Netzwerk eingerichtet, das eine Netzwerkbrücke zur Verbindung mit dem VPN verwendete. Diese Brücke wurde (über /etc/network/interfaces.d/br0.cfg) mit einer Gateway-Adresse eingerichtet bbbb::2105und das Docker-Netzwerk wurde nach der Bridge-Schnittstelle erstellt. Als das Docker-Netzwerk erstellt wurde, wurde die Gateway-Adresse nicht angegeben und Docker verwendete standardmäßig bbbb::1als Gateway-Adresse, die es zwangsweise br0verwendete. Diese Adresse ist dieselbe Adresse wie die des VPN-Servers. Das Ergebnis war, dass Pakete nicht tatsächlich auf dem Host verworfen, sondern an die tapSchnittstelle des VPN-Servers weitergeleitet wurden und der VPN-Server die Routing-Tabellen nicht so eingerichtet hatte, dass er wusste, was mit diesen Paketen zu tun war, sodass sie effektiv in ein schwarzes Loch gelockt wurden, sobald sie den VPN-Server erreichten.

Dies wurde deutlich, indem wir Tshark zur Überwachung der tapSchnittstelle des VPN-Servers sowie der tapSchnittstellen auf den Gateways und dem Docker-Host-Rechner verwendeten. Wir versuchten dann, ein Endgerät aus dem Docker-Container heraus anzupingen, und sahen Pakete auf dem Docker-Host und dem VPN-Server, aber nicht auf den Gateways. Als wir dasselbe auf dem Docker-Host versuchten, sahen wir Pakete auf dem Docker-Host und den Gateways, aber nicht auf dem VPN-Server. Dies zeigte, dass die Docker-Container so konfiguriert waren, dass sie Datenverkehr an den VPN-Server und nicht an die Netzwerkschnittstellen des Hosts sendeten.

Das Problem wurde durch die Einführung der --gatewayOption bei der Erstellung des Docker-Netzwerks behoben.

Der ungelöste Teil davon istWarumDies verhielt sich plötzlich so, obwohl das Setup seit 2016 funktionierte und eines Tages im Juni 2022 zufällig nicht mehr funktionierte.

verwandte Informationen