LINUX.ORG.RU

Как правильно прокинуть IP?

 ,


0

1

Имеется сервис, который должен работать на определённом компьютере. Он делает HTTP-запросы и принимает HTTP-запросы. Исходящие HTTP-запросы должны идти с IP-адреса этого компьютера и входящие HTTP-запросы должны получаться с IP-адреса этого компьютера.

Хочется запускать этот сервис на другом компьютере и перенаправлять входящие и исходящие подключения соответствующим образом. Также хочется минимизировать настройки iptables и подобного и обойтись userspace-софтом.

Простой способ это сделать это ssh. Он может как перенаправлять входящие соединения с удалённого сервера на локальный, так и предоставлять на локальном сервере SOCKS-прокси, который будет перенаправлять исходящие соединения через удалённый сервер. Для разработки именно такой вариант я и использую.

Разумно ли использовать такую конфигурацию в продакшне? Настроить поднятие ssh-соединения через systemd-юнит в принципе несложно, но я никогда не видел, чтобы так делали. Насколько это разумно?

В качестве альтернативы видится поднятие специализированного прокси-сервера на удалённом компьютере, а также http reverse proxy (вроде nginx) на удалённом компьютере. Этот вариант кажется более «продакшн», но несёт с собой уйму дополнительных усилий по управлению всем этим добром, включая безопасность, которая в ssh обеспечивается автоматически.

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

★★★★

В качестве альтернативы видится поднятие специализированного прокси-сервера на удалённом компьютере, а также http reverse proxy (вроде nginx) на удалённом компьютере

Именно так и делают в продакшн :)

Ну или запускают сервис в контейнере, а его в кубере. ingress там есть

router ★★★★★
()
Ответ на: комментарий от cobold

О какой безопасности ты говоришь

Если я сделаю открытую прокси, то все смогут ей пользоваться, это небезопасно. Также популярные прокси-протоколы не шифруются (если не путаю), конечно внутри них трафик шифруется, но всё же некоторая информация утекает, поэтому слушающий трафик сможет узнать что-то. Если я делаю реверс-прокси, опять же надо решать вопрос с шифрованием или проксировать TCP. В общем куча каких-то вопросов, которые в ssh элегантно решены за счёт шифрования канала и взаимной аутентификации по ключам.

vbr ★★★★
() автор топика
Ответ на: комментарий от router

У меня и так кубер, но «сервер с адресом» вне него и это изменить пока нельзя. А приложение, которое должно быть на этом адресе, я как раз и хочу засунуть в кубер.

vbr ★★★★
() автор топика
Ответ на: комментарий от vbr

Так возьми nginx, сделай proxy_pass с него(frontend) на тот сервер, на котором на самом деле крутится твой сервис(backend), если надо шифрование трафика между фронтендом и бэкендом подними https либо на самоподписанных сертификатах либо на certbot. Можешь на бэкенде whitelist еще поднять если нежелательно чтобы ходили на него мимо фронтенда

cobold ★★★★★
()