“Туннель” от одной сети до другого

VPN может решить вашу проблему. Я рекомендую OpenVPN.

Но если вы используете только SSH и SCP, этого будет достаточно, если вы просто настроите параметры NAT на своих пограничных маршрутизаторах.

Например: откройте порт (например) с 2200 по 2210 на вашем пограничном маршрутизаторе на отдельном рабочем месте

следующим образом:

• 2200 преобразуется в порт 22, а адрес 192.168.1.20
• 2201 преобразуется в порт 22 и адрес 192.168. 1.21
• и так далее ..

после этого вы можете подключиться к отдельному рабочему месту:

ssh <wan_ip_of_detached_workplace> -p 2200

это подключится к 192.168.1.20 на вашем отдельном рабочем месте.

Надеюсь, это поможет.

РЕДАКТИРОВАТЬ: Большая часть этого ответа поможет вам легко установить ssh в ящик во внутренней сети. См. Ниже в разделе « Работа с другими сетевыми ресурсами », чтобы узнать больше об этом.

Вы также можете сделать это довольно элегантно с помощью SSH:

Шаг 1 : Настройка / выберите поле перехода

Многие корпоративные сети имеют то, что s обычно называют «бастионным хозяином» или прыжковой коробкой. На этой машине обычно отключены многие сетевые службы, за исключением ssh (и часто на нестандартном порту). Если у вас нет такой машины в вашей «серверной» сети, найдите ящик, доступный через ssh из вашей внутренней сети, чтобы протестировать его.

Шаг 2 : Отредактируйте файл конфигурации ssh

Найдите ваш файл конфигурации ssh (часто в ~ / .ssh / config ) и запустите ваш любимый текстовый редактор. Допустим, ваше окно перехода находится на jump.foo.com , а один из хостов, к которому вы хотите получить доступ, находится на server.foo.com . Включите следующее:

Host server.foo.com
  User <username>
  ProxyCommand /usr/bin/nc -x localhost:1080 %h %p

Host jump.foo.com
  User <username>
  DynamicForward localhost:1080

замените своим именем пользователя. Вам также может потребоваться отредактировать путь к nc (netcat): обратите внимание, что это путь к netcat на вашем локальном хосте. Если конфигурация не имеет 100% смысла, я ее разобью:

Конфигурация jump.foo.com включает директиву для запуска прокси-сервера SOCKS, прослушивающего указанный порт (в мой пример порт 1080). Это означает, что когда вы отправляете ssh на jump.foo.com , вы также автоматически запускаете прокси-сервер SOCKS ... следите за обновлениями.

server.foo.com config говорит: когда я отправляюсь ssh на server.foo.com , выполняю указанную ProxyCommand:

/usr/bin/nc -x localhost:1080 %h %p

, где параметр -x позволяет указать адрес прокси (в данном случае соединение на localhost на только что открытом порту 1080), % h = хост и % p = порт.

Шаг 3 : ssh

ssh на jump.foo.com (я использую tmux , альтернативный экран , и всегда должно быть открыто одно окно с подключением к моему jump.foo.com ). Теперь в отдельном окне / терминале попробуйте просто отправить ssh прямо на server.foo.com . Я должен отметить, что server.foo.com может быть внутренним именем хоста или и внутренним IP-адресом (в сети вашего сервера).

Если вы все поняли правильно, вы должны передается на server.foo.com без проблем.

Есть много способов сделать этот процесс более плавным, с более надежными конфигами ssh и псевдонимами bash. Вот несколько статей, которые я использовал в качестве справочника некоторое время назад, когда впервые настраивал это, и они должны указать вам правильное направление:

http://blog.gidley.co.uk/2009/03/tunnelling-ssh -over-socks-proxy.html http: //blog.electricjellyfish. net / 2006/03 / dynamicforward-where-are-you-been-all.html http://bent.latency.net/bent/git/goto-san-connect-1.85/src/connect.html

Работа с другими сетевыми ресурсами

Допустим, вам нужно подключить удаленный рабочий стол к хосту windows.foo.com в вашей «серверной» сети. В одном окне

ssh -L 3390:windows.foo.com:3389 jump.foo.com

перенаправляется весь трафик с порта 3390 на localhost на порт 3389 (стандартный порт удаленного рабочего стола) на windows.foo.com . Чтобы выполнить удаленный доступ к windows.foo.com , укажите в приложении удаленного рабочего стола localhost: 3390 , и вы сможете прозрачно подключиться к windows.foo.com .

man ssh или Google "ssh port forwarding" для получения дополнительной информации.

Также помните, что вы всегда можете

telnet <server> <port>

убедиться, что можете поговорить с < сервер> на порт , а ля

telnet localhost 3390

Добавление новых хостов в сеть foo.com

Вам не нужно настраивать запись для каждого сервера в вашем окне перехода. Просто

ssh -o "ProxyCommand /usr/bin/nc -x localhost:1080 %h %p" new.server.foo.com

И да, вы должны иметь возможность подключаться к хостам во внутренней сети по имени хоста или IP.

Так же, как мы определили его в нашем конфигурационном файле ssh, вы можете передать аргумент ProxyCommand в ssh с помощью -o вариант. Опять же, это должно направить ваш ssh-трафик на new.server.foo.com через тот же прокси-сервер SOCKS на порт 1080.

Для каждого домена foo.com вы можете просто добавьте правило подстановки в свой файл конфигурации ssh:

Host *.foo.com
      User <username>
      ProxyCommand /usr/bin/nc -x localhost:1080 %h %p

Если вы хотите использовать ssh для хоста, у которого нет записи в вашем файле конфигурации, вы также можете использовать псевдоним bash:

alias ssh-socks='ssh -o "ProxyCommand /usr/bin/nc -x localhost:1080 %h %p"'

ssh-socks newer.server.foo.com

I ' m не уверен, что запрос DNS сделан вашим localhost , или это происходит из окна перехода. Я пробовал tcpdump на localhost при ssh'инге на несколько хостов в моей «серверной» сети

tcpdump port 53

и на самом деле не видел никакого трафика (нет входа в / etc / hosts ... Я бы пришлось сделать DNS-запрос, чтобы попасть на хост). Это может означать, что запросы DNS отправляются из окна перехода, но я не могу быть уверен на 100%.

VPN-туннель - это ответ, с небольшим плохим дополнением ( часть деталей только ниже)

Этот туннель должен быть (ну, намного лучше должно быть , вы можете в крайнем случае использовать p2p VPN-туннель от хоста к хосту), установленный между границами, появится как дополнительный WAN-канал, который маршрутизирует внутри себя все трафик для "удаленной" сети (и да, удаленная сеть может быть видна из локальной сети, это зависит ... но выполнимо).

Это может быть аппаратное решение или чисто программное обеспечение (OpenVPN превратится в SW-решение), но - слишком сложно, чтобы написать здесь все подробности за одну попытку.

Попробуйте начать с документации OpenVPN на месте (если вы можете установить ее с обеих сторон) и разберитесь с примерами для различных типов подключения из нее