Jenkins Номер порта Slave для брандмауэра

Мы используем Jenkins 1.504 на Windows.

Нам нужно иметь Master и Slave в разных подсетей с межсетевым экраном.
У нас не может быть ЛЮБОГО к ЛЮБЫМ правилам брандмауэра порта, мы должны указать номера портов точные.

Я знаю, что мастер порта слушает.

Я также вижу, что Slave открывает соединение с Master из произвольного порта, динамически назначаемого каждому прогону, а порт на стороне мастера также произволен.
Я могу исправить мастер-порт, указав его в разделе Управление Jenkins > Настройка глобальной безопасности > TCP-порт для ведомых агентов JNLP).

Как исправить ведомый порт?

ОБНОВЛЕНИЕ: найден механизм соединения, описанный здесь: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI#JenkinsCLI-Connectionmechanism

Я думаю, это может сработать для нас, но все же было бы лучше иметь фиксированное соединение с фиксированным портом.

Ответ 1

У нас была аналогичная ситуация, но в нашем случае Infosec согласился разрешить любому пользователю 1, поэтому нам не пришлось исправлять ведомый порт, а исправлял мастер-порт JNLP высокого уровня 49187 ( "Настроить глобальную безопасность" → "TCP-порт для ведомых агентов JNLP" ).

TCP
49187 - Fixed jnlp port
8080 - jenkins http port

Другие порты, необходимые для запуска ведомого устройства как службы Windows

Ответ 2

Ведомое устройство не является сервером, это приложение типа клиента. Сетевые клиенты (почти) никогда не используют определенный порт. Вместо этого они запрашивают ОС для случайного свободного порта. Это работает намного лучше, поскольку вы обычно запускаете клиентов на многих машинах, где текущая конфигурация неизвестна заранее. Это предотвращает запуск тысяч "клиентов не запускается, потому что порт уже используется" отчеты об ошибках каждый день.

Вам нужно сообщить отделу безопасности, что подчиненное устройство не является сервером, а клиентом, который подключается к серверу, и вам абсолютно необходимо иметь правило, которое говорит клиент: ANY → server: FIXED. Номер порта клиента должен быть >= 1024 (порты с 1 по 1023 нуждаются в специальных разрешениях), но я не уверен, что вы на самом деле ничего выиграли, добавив правило для этого - если злоумышленник может открывать привилегированные порты, они в основном уже владеют машиной.

Если они утверждают, то спросите их, почему они не требуют того же правила для всех веб-браузеров, которые люди используют в вашей компании.

Ответ 3

У меня есть аналогичный сценарий, и у меня не возникло проблем с подключением после установки порта JNLP во время описания и добавления одного правила брандмауэра, разрешающего подключение на сервере с использованием этого порта. Конечно, это случайно выбранный порт клиента, идущий на известный порт сервера (требуется правило хоста: ANY → server: 1).

Из моего чтения исходного кода я не вижу способа установить локальный порт для использования при выполнении запроса от ведомого. Это, к сожалению, было бы неплохо.

Альтернатива:

Используйте простой прокси на своем клиенте, который прослушивает порт N, а затем пересылает все данные на фактический сервер Jenkins на удаленном хосте с использованием постоянного локального порта. Подключите свой ведомый к этому локальному прокси вместо реального сервера Jenkins.

Создайте собственную рабочую сборку Jenkins, которая позволяет указать локальный порт для использования.

Помните также, если вы используете HTTPS через самозаверяющий сертификат, вы должны изменить файл конфигурации jenkins-slave.xml на подчиненном устройстве, чтобы указать параметр -noCertificateCheck в командной строке.