Я уверен, что ответ на этот вопрос будет доступен в Google, но я действительно не знаю, для чего я использую Google.
У нас есть две сети; наша собственная внутренняя сеть (192.168.0. [0-255]) и наша «серверная» сеть (внутренние адреса: 192.168.1. [0-255]). Наша серверная сеть расположена в удаленном центре обработки данных, и наши серверы наняты dedis (т.е. у нас есть полный контроль над серверным программным обеспечением, смесью RedHat 5/6 и FreeBSD, но нет контроля над сетевым оборудованием или серверным оборудованием). Наша серверная сеть находится за брандмауэром, ограничивающим определенные внешние порты, над которыми мы также имеем полный программный контроль, но его функции ограничиваются только этим, брандмауэром / NAT (без всяких причудливых VPN и т. Д.). Наша внутренняя сеть достаточно проста, у нас есть линия 20 Мбит / с от нашего провайдера, подключенная к довольно типичному домашнему маршрутизатору Netgear. У нас также есть сервер Mac OS / X, на котором работают наши сетевые службы (DNS, DHCP и т. Д.)
Мы хотели бы иметь возможность из этих совершенно разных сетей иметь доступ к серверам в другой сети, просто используя IP-адрес или внутреннее имя хоста (такая же разница).
Итак, я сижу за своей рабочей станцией 192.168.0.10 в нашей внутренней сети. Если я открою свой терминал и ssh 192.168.1.20 он будет подключаться к серверу по адресу 192.168.1.20 в нашей серверной сети, как если бы он находился в комнате *. Точно так же, если бы я подключился к серверу по SSH и хотел что-то вытащить с нашего Mac-сервера во внутреннюю сеть, я мог бы просто scp 192.168.0.100:file ./.
Это распространяется и на другие вещи, такие как установка диска NFS на сервере на наши рабочие столы *, подключение к нашим базам данных без необходимости открывать порты на брандмауэре (мы привязываем их к нашему статическому внешнему IP-адресу, но это все еще раздражает).
Я вроде как знаю, чего хочу, но не совсем уверен, с чего начать. Я предполагаю, что самым простым способом было бы какое-то VPN-соединение между двумя сайтами, а затем мы направили бы определенные IP-адреса через VPN-туннель, я понятия не имею, возможно ли это вообще.
Есть ли что-то только программное (мы можем получить новое оборудование в нашей внутренней сети, но, как я уже сказал, у нас нет физического доступа к нашей серверной инфраструктуре), которое могло бы достичь этого?
Вероятно, это глупый вопрос с очевидным ответом, но я все еще в тупике.
* Производительность может быть ужасной, но не хуже, чем удаленное подключение.
РЕДАКТИРОВАТЬ: большая часть этого ответа поможет вам ssh в ящик во внутренней сети без проблем. См. Ниже в разделе "Работа с другими сетевыми ресурсами"чтобы узнать об этом подробнее.
Вы также можете сделать это довольно элегантно с помощью SSH:
Шаг 1: Установить / выбрать коробку прыжка
Во многих корпоративных сетях есть то, что обычно называют «бастионным хостом» или переходным блоком. На этой машине обычно отключены многие сетевые службы, за исключением 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
замена <username> с вашим именем пользователя. Вам также может потребоваться отредактировать путь к nc (netcat): обратите внимание, что это путь к netcat на вашем локальном хосте. Если конфиг не имеет 100% смысла, я его разобью:
В jump.foo.com config включает директиву для запуска 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-have-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>
чтобы убедиться, что ты можешь поговорить с <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
Я не уверен, что DNS-запрос сделан вашим localhost, или если это происходит из окна прыжка. Я пробовал tcpdump на localhost когда ssh'ing к нескольким хостам в моей "серверной" сети
tcpdump port 53
и на самом деле не видел никакого трафика (нет входов в / etc / hosts ... Мне пришлось бы сделать DNS-запрос, чтобы попасть на хост). Это может означать, что DNS-запросы отправляются из окна перехода, но я не могу быть уверен на 100%.
VPN может решить вашу проблему. Я рекомендую OpenVPN.
Но если вы используете только SSH и SCP, этого будет достаточно, если вы просто настроите параметры NAT на своих пограничных маршрутизаторах.
Например: откройте порт (например) с 2200 по 2210 на пограничном маршрутизаторе на отдельном рабочем месте.
как это:
после этого вы можете подключиться к отдельному рабочему месту:
ssh <wan_ip_of_detached_workplace> -p 2200
это подключится к 192.168.1.20 на вашем отдельном рабочем месте.
Надеюсь, это поможет.
VPN-туннель - это ответ с небольшим плохим дополнением (часть деталей только ниже)
Этот туннель должно быть (ну а намного лучше должно бытьвы можете как Крайнее средство использовать p2p VPN-туннель от хоста к хосту), установленный между границами, появится как дополнительный WAN-канал, который маршрутизирует внутри себя весь трафик для «удаленной» сети (и да, удаленная сеть может быть видна из локальной, это зависит ... но выполнимо).
Это может быть аппаратное решение или чисто программное обеспечение (OpenVPN превратится в SW-решение), но - слишком сложное, чтобы писать здесь все детали за один раз.
Попробуйте начать с локальной документации OpenVPN (если вы можете установить ее с обеих сторон) и понять образцы для разных типов подключения из нее.