SOCKS прокси в Ansible: кой компютър притежава localhost?

Открийте процеса, който прави заявка към Ansible API, преди да го насочите към SSH SOCKS слушател на loopback.

Задача, използваща socks5h://127.0.0.1:65432, трябва да работи в мрежовата среда, където съществува този слушател. Тунел, работещ от контролера, не го прави достъпен на loopback адреса на управляван хост — или вътре в контейнер за изпълнение.

За неуспешната задача установете четири факта:

  1. Хостът или контейнерът, който изпълнява мрежовата заявка.
  2. Неговият ефективен потребител и Python интерпретатор.
  3. HTTP библиотеката или SDK на модула.
  4. Адресът, на който този процес може да достигне SOCKS слушателя.

Само целта от инвентара на пиесата не отговаря на първия въпрос. Модулите използват конфигурираната си връзка, делегирането може да премести изпълнението, а локалната връзка може да остави работата на контролера. Търсенията от страна на контролера се извършват напълно извън отдалечения модул.

За задача с OpenStack образ проверете изискванията на инсталираната колекция openstack.cloud и нейната среда за OpenStack SDK. Успешният curl другаде не доказва SOCKS възможностите или зависимостите на този SDK.

Ако операцията с API трябва да се изпълнява локално, направете този избор на изпълнение явен и задайте настройката там. Ако се изпълнява отдалечено, изберете прокси, достъпно от този контекст. environment: на задачата в Ansible влияе на процеса на задачата; той не преконфигурира всяко търсене или плъгин и SDK все още трябва да поддържа схемата в тази Python среда.

Дръжте двата маршрута отделно: SSH или ProxyJump отвежда Ansible до хост, докато HTTP клиентът на модула стига от контекста си на изпълнение до API. Работещият първи маршрут не конфигурира втория. Излагането на слушател само от контролера, за да се реши достъпността, също променя кой може да го достига, така че това е решение за внедряване, а не корекция на адрес.

Подобни статии