У нас есть виртуальная машина с публичным IPv4-адресом, к которому мы пример.com
и *.example.com
точки домена.
У нас есть несколько распределенных низкотехнологичных компьютеров, устанавливающих соединение/туннель wireguard с общедоступной виртуальной машиной.
Мы хотим, чтобы виртуальная машина обслуживала веб-сайт на портах 80
/443
, принимать ssh-соединения через порт 22
, и более.
Мы хотим, чтобы низкотехнологичные компьютеры были общедоступны через соответствующие поддомены, такие как низкотехнологичный-01.example.com
, low-tech-02.example.com
, и так далее, а также проксирование/маршрутизация запросов на соответствующие локальные/wireguard IP-адреса. Это должно работать для веб-сайтов через порты 80
/443
, ssh соединения через порт 22
, и более.
Редактировать: В идеале SSL-сертификаты должны обслуживаться низкотехнологичными компьютерами, а SSL-соединение не должно разрываться на виртуальной машине.
Редактировать: В идеале закрытые ssh-ключи для подключения к низкотехнологичным компьютерам не должны существовать на виртуальной машине, а только на клиенте.
Редактировать: Для ssh мы могли бы открыть и маршрутизировать по одному уникальному порту для каждого низкотехнологичного компьютера из общедоступный_IPv4:22xxx
к локальный/wireguard_IP:22
К сожалению, потратив два дня на пробы и пробы с настройкой nginx, мы пришли к выводу, что эту задачу вряд ли можно решить одним nginx.
Примечание: ssh не отправляет SNI; nginx не может прослушивать одни и те же порты для http
а также транслировать
связи; а может и больше проблем.
Но также у нас полностью закончились идеи, и мы не можем понять, какой подход мог действительно правильно решить эту задачу.
(www\.)?example.com
â> общедоступный IPv4 â> веб-сайт, ssh и т. д.
низкотехнологичный-01.example.com
â> публичный IPv4 â> ??? ~> 10.0.0.101
✓> веб-сайт, ssh и т. д.
low-tech-02.example.com
â> публичный IPv4 â> ??? ~> 10.0.0.102
✓> веб-сайт, ssh и т. д.
¦
Спасибо за ваш совет и время.
â
Редактировать: Следующий nginx транслировать
config близок к тому, чего мы пытаемся достичь. Единственным (возможно) недостатком является то, что нам пришлось бы вручную определять порт для каждого низкотехнологичного компьютера вместо того, чтобы обрабатывать это динамически, как для SSL-соединений.
транслировать {
карта $ ssl_preread_server_name $ имя {
пример.com пример.com;
www.example.com пример.com;
low-tech-01.example.com low-tech-01.example.com;
low-tech-02.example.com low-tech-02.example.com;
}
upstream example.com {
сервер 127.0.0.1:8443;
}
восходящий канал low-tech-01.example.com {
сервер 10.0.0.101:443;
}
восходящий канал low-tech-02.example.com {
сервер 10.0.0.102:443;
}
сервер {
слушать 443;
прокси_пароль $имя;
ssl_preread включен;
}
сервер {
слушай 22101;
прокси_пасс 10.0.0.101:22;
}
сервер {
слушай 22102;
прокси_пасс 10.0.0.102:22;
}
¦
}