iptables REDIRECT a Kubernetes NodePort hace que la solicitud se cuelgue

iptables REDIRECT a Kubernetes NodePort hace que la solicitud se cuelgue

Estoy intentando dirigir el tráfico del cliente a un NodePort del clúster de Kubernetes que escucha en 192.168.1.100.30000 (puerto https).

El cliente necesita realizar una solicitud a 192.168.1.100.8000, por lo que agregué la siguiente regla REDIRECT en iptables:

iptables -t nat -I PREROUTING -p tcp --dst 192.168.1.100 --dport 8000 -j REDIRECT --to-port 30000
iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

Sin embargo, recibo el siguiente error:

# curl -vk https://192.168.1.100:8000/v1/api
* About to connect() to 192.168.1.100 port 8000 (#0)
*   Trying 192.168.1.100...
* Connected to 192.168.1.100 (192.168.1.100) port 8000 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -12263 (SSL_ERROR_RX_RECORD_TOO_LONG)
* SSL received a record that exceeded the maximum permissible length.
* Closing connection 0
curl: (35) SSL received a record that exceeded the maximum permissible length.

También intenté configurar el sistema remoto indicado enesteResponda y realice una solicitud al mismo punto final y obtuvo el siguiente error:

# ip netns exec remotesystem curl -vk https://192.168.1.100:8000/v1/api
* About to connect() to 192.168.1.100 port 8000 (#0)
*   Trying 192.168.1.100...
* Connection timed out
* Failed connect to 192.168.1.100:8000; Connection timed out
* Closing connection 0
curl: (7) Failed connect to 192.168.1.100:8000; Connection timed out

Sé que el clúster de Kubernetes tiene políticas de red aplicadas con calico crds, sin embargo, agregué una opción predeterminada para permitir todo a la política de red y el tráfico parece seguir bloqueado.

También verifiqué los registros del controlador de ingreso para ver si la solicitud llegó allí, pero no vi ningún resultado de registro al realizar la solicitud.

Lo extraño es que al activar directamente el puerto del nodo https://192.168.1.100.30000/v1/apifunciona y obtengo una respuesta exitosa.

La pregunta es, ¿por qué el curling https://192.168.1.100:8000/v1/api (with the REDIRECT rule to 30000)hace que la solicitud se cuelgue?

información relacionada