Proxy SOCKS de Ansible: ¿qué máquina es dueña de localhost?

Una tarea que usa socks5h://127.0.0.1:65432 debe ejecutarse en el entorno de red donde existe ese escucha. Un túnel que funciona desde el controlador no lo hace disponible en la dirección loopback de un host gestionado — ni dentro de un contenedor de ejecución.

Para la tarea que falla, establezca cuatro hechos:

1. El host o contenedor que ejecuta la solicitud de red.
2. Su usuario efectivo y su intérprete de Python.
3. La biblioteca HTTP o el SDK del módulo.
4. La dirección en la que ese proceso puede alcanzar el escucha SOCKS.

El destino de inventario de la obra por sí solo no responde la primera pregunta. Los módulos usan su conexión configurada, la delegación puede mover la ejecución y una conexión local puede mantener el trabajo en el controlador. Las búsquedas del lado del controlador ocurren completamente fuera del módulo remoto.

Para una tarea de imagen de OpenStack, revise los requisitos de la colección openstack.cloud instalada y su entorno de SDK de OpenStack. Que curl funcione en otro lugar no demuestra las capacidades SOCKS ni las dependencias de ese SDK.

Si la operación de API debe ejecutarse localmente, haga explícita esa elección de ejecución y proporcione allí la configuración. Si se ejecuta de forma remota, elija un proxy accesible desde ese contexto. El environment: de la tarea de Ansible afecta al proceso de la tarea; no reconfigura cada búsqueda ni cada complemento, y el SDK sigue necesitando admitir el esquema en ese entorno de Python.

Mantenga dos rutas separadas: SSH o ProxyJump lleva Ansible hasta un host, mientras que el cliente HTTP del módulo va desde su contexto de ejecución hasta la API. Una primera ruta que funciona no configura la segunda. Exponer un escucha que solo existe en el controlador para resolver la accesibilidad también cambia quién puede acceder a él, así que es una decisión de despliegue y no una corrección de dirección.