как настроить ssh-туннель для именованного виртуального хоста, на котором запущен Jenkins

В настоящее время я настраиваю сервер в нашей лаборатории в Uni, который будет использоваться для нескольких целей, включая базу данных библиографии и сервер CI (Jenkins). Чтобы поддерживать четкое разделение проблем, у меня есть заключенный в тюрьму виртуальный хост (VH) для каждой функции вместе с назначенным внутренним доменным именем. Внутри лаборатории все работает нормально. Я установил BIND9 на сервер, поэтому он может разрешать доменные имена.

Однако, чтобы подключиться к нашей лаборатории из дома, нам нужно сначала подключить VPN к Uni, а затем по SSH к шлюзу нашей лаборатории. Через шлюз мы можем получить доступ к любым внутренним машинам, которые нам нужны. После входа в шлюз мы используем туннели SSH по мере необходимости. В соответствии с политикой университета, к машинам внутри нашей лаборатории нельзя получить прямой доступ через VPN без входа в шлюз.

Мне интересно, можно ли получить доступ к виртуальным хостам через один туннель SSH? Нравится указание имени сервера (SNI)? Или мне нужно настроить прокси-сервер, такой как Squid? Я так понимаю, что трафик DNS и HTTP необходимо маршрутизировать правильно. Можно ли это сделать, просто используя hosts настройки файла?

Любые советы будут высоко ценится. Спасибо!

Обновить
Я продолжал работать над проблемой и нашел решение, которое, кажется, работает, но все еще имеет один остающийся недостаток; Дженкинс на Manage страница при использовании VPN / SSH жалуется It appears that your reverse proxy set up is broken. Таким образом, хотя мои запросы верны, некоторые из моих ответов нет, и я хотел бы это исправить.

Короткий ответ - использовать обратный прокси-сервер, расположенный на удаленном компьютере, который перенаправляет запросы на порты localhost, которые туннелируются. Решение заключалось в следующем:
1) Поскольку SNI недоступен, в этом случае можно назначить дополнительный уникальный порт, который будет прослушиваться для каждого виртуального хоста. Я решил использовать диапазон 808x вверх.
2) Я обновил раздел в файле конфигурации SSH на моем локальном компьютере, который я использую для подключения к шлюзу, чтобы включить переадресацию всех этих портов.
3) Я настроил локальный обратный прокси на моем локальном компьютере (используя Apache2 в моем случае), чтобы я мог обращаться к каждому порту, используя доменное имя, тем самым перенаправляя запросы на http://localhost:808x. Для местных VH я решил использовать .vpn TLD, чтобы пометить их как доменные имена для использования при использовании VPN для подключения к лаборатории. Таким образом, я могу использовать обычный .int доменное имя, когда я нахожусь в лаборатории, без каких-либо конфликтов.

В целом, это решение работает хорошо. Хотя есть возможность dismiss ошибку, я хотел бы ее исправить, потому что после прочтения документации мне неясно, к каким последствиям приведет простое ее отклонение.

Итак, мой вопрос теперь очень ориентирован на Дженкинса, поэтому я включил ниже различные файлы конфигурации, которые я установил. Мне интересно, что я мог пропустить в своих обратных прокси-серверах, или мне нужно использовать mod_rewrite. Любой совет будет принят во внимание.

СЕРВЕРНАЯ СТОРОНА
у меня есть mod_proxy, mod_proxy_http, и mod_headers включен. Я только показал изменения, которые я внес в файлы по умолчанию.

ports.conf

Listen 80
### TOMCAT is running on 8081
Listen 8082
Listen 8083

jenkins.int.vhost

<VirtualHost *:80 *:8081 *:8083>

        ServerName        jenkins.int
        ProxyRequests     Off
        ProxyPreserveHost On
        AllowEncodedSlashes NoDecode

        <Proxy http://localhost:8081/*>
          Order deny,allow
          Allow from all
        </Proxy>

        ProxyPass         /  http://localhost:8081/ nocanon
        ProxyPassReverse  /  http://localhost:8081/
        ProxyPassReverse  /  http://jenkins.int/

#       Header edit Location ^http://jenkins.vpn http://jenkins.int
</VirtualHost>

/ и т.д. / по умолчанию / Дженкинс

# port for HTTP connector (default 8080; disable with -1)
HTTP_PORT=8081
JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT"

/var/lib/jenkins/jenkins.model.JenkinsLocationConfiguration.xml

<jenkinsUrl>http://jenkins.int/</jenkinsUrl>

/var/lib/jenkins/jenkins.CLI.xml

<jenkins.CLI>
  <enabled>true</enabled>
</jenkins.CLI>

Это необходимо для запуска скриптов.

СТОРОНА КЛИЕНТА

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>

    ServerName biblio.vpn

    ProxyPass / http://localhost:8082/

</VirtualHost>

<VirtualHost *:80>

    ServerName jenkins.vpn
    ProxyRequests Off
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

    ProxyPass / http://localhost:8083/
    ProxyPassReverse / http://localhost:8083/
    ProxyPassReverse / http://jenkins.int/

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Файл конфигурации SSH

LocalForward localhost:8080 server.local:8080
LocalForward localhost:8081 server.local:8081
LocalForward localhost:8082 server.local:8082
LocalForward localhost:8083 server.local:8083

Обновление 2

Поговорив с некоторыми полезными пользователями Jenkins в IRC, я пришел к выводу, что в нашем случае ошибку / предупреждение о сломанном обратном прокси-сервере можно не учитывать.
Последняя, ​​незначительная, но неприятная проблема заключалась в том, что ссылка «Новое представление» указывала на неправильный адрес («jenkins.int» вместо «jenkins.vpn»). Редактирование core / src / main / java / jenkins / model / NewViewLink.java и замена Jenkins.getInstance().getRootUrl() с участием "/" в строке 47, затем перекомпоновка Jenkins и загрузка файла WAR устранили эту проблему.