Un servicio escucha en 127.0.0.1:1080. Una regla DNAT dirige el tráfico entrante a esa dirección, pero la conexión falla. El servicio puede estar sano y la regla NAT puede coincidir: las direcciones de loopback IPv4 reciben un tratamiento de enrutamiento especial.

El route_localnet de Linux controla si las direcciones 127/8 se tratan como direcciones marcianas durante el enrutamiento. Su valor predeterminado conserva el límite habitual del loopback. Una excepción específica de una interfaz puede ser relevante para un diseño deliberado de redirección local.

Eso explica por qué una regla que funciona en otra máquina puede depender de un sysctl que no copió. No justifica habilitar la opción en todas partes.

La suposición de seguridad cambia con la ruta

La vinculación al loopback se usa a menudo porque un auxiliar no tiene autenticación de cliente independiente. Si el tráfico que llega de otra interfaz puede enrutarse hacia allí, la dirección de vinculación por sí sola ya no describe al público alcanzable. Restrinja las fuentes de entrada, el destino y el puerto en el conjunto de reglas real, incluido el tráfico que afirma direcciones de origen o destino de loopback cuando corresponda.

Revise el espacio de nombres de red que contiene el servicio. El loopback de un contenedor no es el del anfitrión, y cambiar un ajuste de interfaz del anfitrión no crea automáticamente un oyente en el contenedor.

rp_filter responde a una pregunta distinta sobre la validación de la ruta de origen. Desactivarlo globalmente no es un sustituto general de entender el enrutamiento de loopback. Del mismo modo, ip_nonlocal_bind trata de vincular sockets a direcciones no locales, no de hacer correcta esta ruta DNAT.

Por último, el protocolo redirigido debe encajar con el oyente. Enviar tráfico HTTP o TLS sin procesar a un puerto SOCKS todavía requiere un traductor; una excepción de enrutamiento no puede aportar la negociación que falta.

Artículos relacionados