.png)
Tengo algunos problemas para conectar mis pods/contenedores de AKS a nuestra red local.
Tengo una red virtual en los espacios de nombres 172.16.20.0/22y 172.16.24.0/29. Tienen 2 subredes, cada una tiene uno de los rangos anteriores como rango de subred.
El clúster de AKS está vinculado a la 172.16.20.0/22subred y cada uno de los nodos, así como los pods, obtienen una dirección IP en ese rango. También agregué una VM normal a esta subred para una depuración temporal.
En la 172.16.24.0/29subred, tenemos una puerta de enlace de red virtual (no tiene IP en esta subred) que conecta esa subred a nuestra red local. La puerta de enlace VN tiene una puerta de enlace de red local coincidente con espacio de direcciones 172.17.151.0/24. En nuestra red local tenemos un servidor SMTP 172.17.151.254, escuchando en el puerto 25.
En la máquina virtual que inicié para depurar, puedo conectarme al servidor SMTP sin problemas. También puedo hacer ping a la VM desde el servidor SMTP sin problemas. Sin embargo, desde los pods no puedo conectarme a SMTP (probado con netcat -zv 172.17.151.254 25), ni puedo hacer ping a la dirección IP de un pod desde el servidor SMTP.
Ninguna de las subredes tiene un grupo de seguridad de red (NSG) adjunto, por lo que no puede ser una regla de NSG mal configurada. ¿Qué más podría estar provocando que falle la conexión? Los pods obtienen la misma configuración de red básica del servidor DHCP en la subred:
- Una dirección IP 172.16.20.0/22
- 172.16.20.1 como su puerta de enlace predeterminada
Nuestro personal de TI que mantiene el dispositivo local que se conecta a Azure VNG me ayudó a depurar, dicen que al iniciar una conexión SMTP ven que 172.17.151.254llega el paquete y un paquete de respuesta del servidor que regresa al túnel VPN. entonces parece que el paquete de respuesta se elimina en algún lugar de Azure.
Editar: Durante una nueva sesión de depuración con nuestro personal de TI, notamos que la IP de origen de los paquetes provenientes de nuestro pod que se comporta mal es 172.17.20.5, en lugar de 172.16.20.21. 172.17.20.5es la IP del nodo VMSS en el que se ejecuta el pod, por lo que podría tener sentido, pero significaría que el enrutamiento interno en ese nodo no está configurado correctamente.
¿O es algo específico de Kubernetes lo que está provocando que esto falle?
Lo que he probado hasta ahora:
- En VM: ping a
172.16.20.21(pod): funciona bien - En VM: ping a
172.17.151.254: funciona bien - En VM:
tracert 172.17.151.254tiene éxito en 1 salto (¿no debería mostrar al menos 2 saltos cuando pasa a través de la puerta de enlace predeterminada?) - En pod: ping a
172.16.20.4(vm): funciona bien - En pod: ping a
172.17.151.254: falla - En pod:
traceroute 172.17.151.254falla y no se muestran saltos - En un dispositivo VPN local: ping a
172.16.20.4(vm): funciona bien - En dispositivo VPN local: ping a
172.16.20.21(pod): falla
Información extra:
ifconfig -ade la vaina:
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
routesalida del 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 /alldesde la máquina virtual de depuración:
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 printdesde la máquina virtual de depuración:
===========================================================================
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
Respuesta1
El problema se encontró después de una exhaustiva solución con la ayuda del soporte de Microsoft.
La causa principal fue la dirección IP del servidor SMTP (punto final VPN) 172.17.151.254, que se superpone con la red Docker Bridge predeterminada que 172.17.0.0/16se configuró en los nodos K8S. Como este aspecto no estaba presente en la máquina virtual de depuración que inicié, el problema no se manifestó allí.
Lección aprendida: manténgase alejado del 172.17.0.0/16alcance cuando utilice AKS