Ansible の SOCKS プロキシ：localhost はどのマシンのものか
Ansible API リクエストを行うプロセスを特定してから、loopback 上の SSH SOCKS リスナーへ向けましょう。
socks5h://127.0.0.1:65432 を使うタスクは、そのリスナーが存在するネットワーク環境で実行する必要があります。コントローラー側で動作するトンネルがあっても、管理対象ホストの loopback アドレスや実行コンテナ内では利用できません。
失敗するタスクについて、次の4点を確定します。
- ネットワークリクエストを実行するホストまたはコンテナ。
- その実効ユーザーと Python インタープリター。
- モジュールが使う HTTP ライブラリまたは SDK。
- そのプロセスが SOCKS リスナーに到達できるアドレス。
プレイのインベントリ対象だけでは最初の問いに答えられません。モジュールは設定された接続を使い、委譲は実行場所を移し、ローカル接続は作業をコントローラーに残せます。コントローラー側のルックアップはリモートモジュールの完全に外側で行われます。
OpenStack イメージのタスクでは、インストール済みの openstack.cloud コレクションの要件と、その OpenStack SDK 環境を確認してください。別の場所で curl が成功しても、その SDK の SOCKS 対応や依存関係を証明するものではありません。
API 操作をローカルで実行する意図なら、その実行方法を明示し、設定もそこに置きます。リモートで実行するなら、そのコンテキストから到達できるプロキシを選びます。Ansible タスクの environment: はタスクプロセスに作用しますが、すべてのルックアップやプラグインを再設定するわけではなく、SDK はその Python 環境で方式を引き続きサポートする必要があります。
2つの経路を分けて考えます。SSH や ProxyJump は Ansible をホストまで届け、モジュールの HTTP クライアントは実行コンテキストから API まで届きます。最初の経路が動いても2つ目は設定されません。コントローラーにしかないリスナーを到達性のために公開すると、誰がアクセスできるかも変わるため、これはアドレスの修正ではなく配備の判断です。