(В этом примере я предполагаю, что порт 2222 перейдет на ваш внутренний хост. $ Externalip и $ internalip - это ip-адреса или имена хостов видимого и внутреннего компьютера соответственно.)
У вас есть несколько вариантов, в зависимости от того, как долго вы хотите, чтобы прокси был:
Какой-то TCP-прокси. В Linux основная идея состоит в том, что до входящего пакета обрабатывается, вы хотите изменить его назначение - т.е. NAT назначения предварительной маршрутизации:
iptables -t nat -A PREROUTING -p tcp -i eth0 -d $externalip --dport 2222 --sport
1024:65535 -j DNAT --to $internalip:22
Использование SSH для установления временной переадресации портов. Отсюда у вас снова есть два варианта:
Прозрачный прокси, где клиент думает, что ваш видимый хост (на порту 2222) является просто обычным сервером SSH и не понимает, что он проходит через него. В то время как вы теряете некоторый детальный контроль, вы получаете удобство (особенно если вы хотите использовать SSH для пересылки VNC или X11 вплоть до внутреннего хоста).
- с внутренней машины:
ssh -g -R 2222:localhost:22 $externalip
- Тогда из внешнего мира:
ssh -p 2222 $externalip
Обратите внимание, что «внутренние» и «внешние» машины не обязательно должны находиться в одной локальной сети. Таким образом, вы можете перемещаться вперед по всему миру.
Сначала принудительный вход на внешнюю машину. Это действительно «пересылка», а не «проксирование»; но основная идея заключается в следующем: вы заставляете людей входить на внешнюю машину (чтобы вы могли контролировать, кто может войти и когда, и вы получаете журналы активности), и оттуда они могут пройти через SSH внутрь. Это звучит как рутина, но если вы настроили простые сценарии оболочки на внешнем компьютере с именами ваших внутренних хостов, в сочетании с паролями SSH без пароля , то для пользователя очень просто войти в систему Итак:
- На внешней машине вы создаете простой скрипт
/usr/local/bin/internalhost, который просто запускает ssh $internalip
- Из внешнего мира пользователи делают:
ssh $externalip internalhost и, как только они входят в систему на первом компьютере, они сразу же перенаправляются на внутренний.
Еще одним преимуществом этого подхода является то, что люди не испытывают проблем с управлением ключами, поскольку запуск двух служб SSH на одном IP-адресе разозлит клиента SSH.
К вашему сведению, если вы хотите подключиться к серверу по SSH и не хотите беспокоиться о ключах, сделайте это
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
В моей оболочке есть псевдоним "nossh", поэтому я могу просто сделать nossh somehost, и он будет игнорировать все ключевые ошибки. Просто поймите, что при этом вы игнорируете информацию о безопасности, поэтому существует теоретический риск.
Большая часть этой информации взята из разговора, который я дал в Barcamp Bangkok о причудливых трюках с SSH. Вы можете видеть мои слайды , но я рекомендую текстовую версию , так как слайды S5 являются глючными. Проверьте информацию в разделе «Forward Anything: Simple Port Forwarding». Также есть информация о создании SOCKS5 прокси с OpenSSH. Да, вы можете сделать это. OpenSSH такой замечательный.
(Наконец, если вы много работаете с внутренней сетью, подумайте о настройке VPN. Звучит страшно, но OpenVPN довольно прост и работает во всех ОС. Я бы сказал, что это излишне только для SSH; но как только вы начнете переадресацию портов через переадресацию портов для получения VNC, HTTP или других вещей, или если у вас есть множество внутренних хостов, о которых стоит беспокоиться, это может быть проще и проще в обслуживании.)