.png)
Ich habe einige Probleme, meine AKS-Pods/Container mit unserem lokalen Netzwerk zu verbinden.
Ich habe ein virtuelles Netzwerk in den Namespaces 172.16.20.0/22und 172.16.24.0/29. Sie haben 2 Subnetze, jedes hat einen der oben genannten Bereiche als Subnetzbereich.
Der AKS-Cluster ist an das 172.16.20.0/22Subnetz gebunden und jeder der Knoten sowie die Pods erhalten eine IP-Adresse in diesem Bereich. Ich habe diesem Subnetz auch eine reguläre VM zum temporären Debuggen hinzugefügt.
Im 172.16.24.0/29Subnetz haben wir ein virtuelles Netzwerk-Gateway (es hat in diesem Subnetz keine IP), das dieses Subnetz mit unserem lokalen Netzwerk verbindet. Das VN-Gateway hat ein passendes lokales Netzwerk-Gateway mit dem Adressraum 172.17.151.0/24. In unserem lokalen Netzwerk haben wir einen SMTP-Server auf 172.17.151.254, der auf Port 25 lauscht.
Auf der VM, die ich zum Debuggen hochgefahren habe, kann ich problemlos eine Verbindung zum SMTP-Server herstellen. Ich kann die VM auch problemlos vom SMTP-Server aus anpingen. Von den Pods aus kann ich jedoch keine Verbindung zu SMTP herstellen (getestet mit netcat -zv 172.17.151.254 25), und ich kann auch nicht die IP-Adresse eines Pods vom SMTP-Server aus anpingen.
Keinem der Subnetze ist eine Netzwerksicherheitsgruppe (NSG) zugeordnet, es kann also keine falsch konfigurierte NSG-Regel sein. Was könnte sonst dazu führen, dass die Verbindung fehlschlägt? Die Pods erhalten vom DHCP-Server im Subnetz die gleiche grundlegende Netzwerkkonfiguration:
- Eine IP-Adresse 172.16.20.0/22
- 172.16.20.1 als Standard-Gateway
Unser IT-Personal, das das lokale Gerät wartet, das eine Verbindung zum Azure VNG herstellt, hat mir beim Debuggen geholfen. Sie sagen, dass 172.17.151.254sie beim Initiieren einer SMTP-Verbindung das ankommende Paket und ein Antwortpaket vom Server sehen, das zurück in den VPN-Tunnel geht. Es scheint also, dass das Antwortpaket irgendwo in Azure verloren geht.
Bearbeiten: Während einer weiteren Debugging-Sitzung mit unserem IT-Personal haben wir festgestellt, dass die Quell-IP der Pakete, die von unserem fehlerhaften Pod kommen, 172.17.20.5statt ist 172.16.20.21. 172.17.20.5ist die IP des VMSS-Knotens, auf dem der Pod läuft, also könnte das Sinn ergeben, würde aber bedeuten, dass das interne Routing auf diesem Knoten nicht richtig konfiguriert ist.
Oder ist das etwas Kubernetes-Spezifisches, das den Fehler verursacht?
Was ich bisher versucht habe:
- Auf VM: Ping an
172.16.20.21(Pod): funktioniert einwandfrei - Auf VM: Ping an
172.17.151.254: funktioniert einwandfrei - Auf VM:
tracert 172.17.151.2541 Hop ist erfolgreich (sollten hier nicht mindestens 2 Hops angezeigt werden, da es durch das Standard-Gateway geht?) - Auf dem Pod: Ping an
172.16.20.4(VM): funktioniert einwandfrei - Auf Pod: Ping an
172.17.151.254: schlägt fehl - Auf Pod:
traceroute 172.17.151.254schlägt fehl, ohne dass Hops angezeigt werden - Auf lokalem VPN-Gerät: Ping an
172.16.20.4(VM): funktioniert einwandfrei - Auf lokalem VPN-Gerät: Ping an
172.16.20.21(Pod): schlägt fehl
Zusatzinformation:
ifconfig -aaus Pod:
eth0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 172.16.20.21 netmask 255.255.252.0 broadcast 0.0.0.0
ether de:c7:74:e3:c5:24 txqueuelen 1000 (Ethernet)
RX packets 386868 bytes 35746728 (34.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 511891 bytes 43865660 (41.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 5 bytes 504 (504.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 504 (504.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
routeAusgabe vom Pod:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.20.1 0.0.0.0 UG 0 0 0 eth0
172.16.20.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
ipconfig /allvon der Debug-VM:
Windows IP Configuration
Host Name . . . . . . . . . . . . : debug-vm
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 00-0D-3A-2D-DC-BA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::e9bb:fede:66cc:398c%6(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.20.4(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Lease Obtained. . . . . . . . . . : Friday, August 28, 2020 7:15:08 AM
Lease Expires . . . . . . . . . . : Friday, October 8, 2156 1:20:49 PM
Default Gateway . . . . . . . . . : 172.16.20.1
DHCP Server . . . . . . . . . . . : 168.63.129.16
DHCPv6 IAID . . . . . . . . . . . : 100666682
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-DA-67-54-00-0D-3A-2D-DC-BA
DNS Servers . . . . . . . . . . . : 168.63.129.16
NetBIOS over Tcpip. . . . . . . . : Enabled
route printvon der Debug-VM:
===========================================================================
Interface List
6...00 0d 3a 2d dc ba ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.20.1 172.16.20.4 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 172.16.20.1 172.16.20.4 11
169.254.169.254 255.255.255.255 172.16.20.1 172.16.20.4 11
172.16.20.0 255.255.252.0 On-link 172.16.20.4 266
172.16.20.4 255.255.255.255 On-link 172.16.20.4 266
172.16.23.255 255.255.255.255 On-link 172.16.20.4 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.16.20.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.16.20.4 266
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
6 266 fe80::/64 On-link
6 266 fe80::e9bb:fede:66cc:398c/128
On-link
1 331 ff00::/8 On-link
6 266 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
Antwort1
Das Problem wurde nach umfassender Fehlerbehebung mit Hilfe des Microsoft-Supports gefunden.
Die Hauptursache war die IP-Adresse des SMTP-Servers (VPN-Endpunkt) auf 172.17.151.254, die sich mit dem Standard-Docker-Bridge-Netzwerk überschneidet, 172.17.0.0/16das auf den K8S-Knoten konfiguriert war. Da dieser Aspekt auf der von mir gestarteten Debug-VM nicht vorhanden war, trat das Problem dort nicht auf.
Lektion gelernt: Halten Sie sich 172.17.0.0/16bei der Verwendung von AKS von der Reichweite fern