Обратный туннель для доступа к внешнему API на межсетевом сервере, доступном только через бастион

792
Trevor Hartman

Если название звучит запутанно, это так, и я очень запутался. Вот ситуация:

  1. У меня есть prod-сервер, prod1который блокирует входящий / исходящий трафик из / во весь внешний Интернет
  2. Кроме того, единственный способ, которым я могу использовать SSH на этом сервере, - это сначала SSHing к внутреннему бастиону bastion.foo.com, а затем ssh с sshconfig, например ProxyCommand ssh -W %h:%p bastion.foo.com.

На prod1Я хочу быть в состоянии поразить API конечных точек, например, curl -I https://api.com(который использует порт 443, как это HTTPS) по каким - то туннелирование через мой SSH подключение к этому серверу (только тогда, когда я подключен конечно). Прочитав несколько постов в блоге, я подумал, что RemoteForward был ответом:

Host prod1 HostName ... User ... IdentityFile ... RemoteForward 443 api.com:443 ProxyCommand ssh -W %h:%p bastion.foo.com 

Но когда я ssh prod1первым делом, сервер говорит:

Предупреждение: переадресация удаленного порта для прослушивающего порта 443 не удалась

Как мне сделать то, что я пытаюсь сделать? Я на правильном пути?

1

1 ответ на вопрос

1
Jakuje

There is really cute drawing which explains RemoteForward in openssh. But the remote forwarding is probably more complicated in your use case than you describe.

You would need to change at least /etc/hosts to make it at least a bit transparent to your application:

127.0.0.1 api.com 

Or change your application to connect to localhost directly instead of api.com.

And please note, that

Privileged ports can be forwarded only when logging in as root on the remote machine.

from man ssh_config(5). This means, that you can't bind port 443 without root privileges (or even other mechanisms like SELinux can block you from doing so). You need these privileges or rather you should choose different local port and it makes it even less transparent for your application.

Отличная схема; гораздо полезнее, чем документы и сообщения в блоге! Использование вашего предложения `/ etc / hosts` и переключение на порт 4433 сделали эту работу! Благодарю. Я думал, что бастион / прокси помешает, но, видимо, это никак не отразилось. Trevor Hartman 8 лет назад 0

Похожие вопросы