Назад | Перейти на главную страницу

SSH через VPN-соединение

У нас есть сервер AWS EC2, который мы настроили для доступа (через SSH) только из нашей офисной сети. Очевидно, что это не идеально для удаленных устройств, когда кто-то должен подключиться к экземпляру EC2 и работает удаленно вне офиса, например, во время деловой поездки.

Мне удалось настроить VPN через PPTP и я могу подключиться к офисной сети (у меня есть два локальных IP-адреса, один от wlan0 и один от ppp0) независимо от того, где я нахожусь. Однако, когда я подключаюсь к экземпляру EC2 по SSH, он все равно отклоняет меня, скорее всего, потому, что видит, что я все еще пытаюсь подключиться к ssh извне.

Думаю, проблема в том, что я не могу направить ssh-трафик через VPN. Есть идеи, как я могу это сделать?

Другой вариант - подключиться по ssh к машине в офисной сети, а затем использовать эту машину для ssh с экземпляром EC2, но я не решался сделать это, поскольку это кажется чрезмерным.

Предположим, ваш AWS доступен через SSH по IP-адресу your.ec2.ip.address. Предположим, ваша офисная сеть имеет доступ в Интернет через маршрутизатор, который применяет некоторые преобразования NAT, и поэтому ваши офисные ПК видны в Интернете с IP-адресом your.office.external.ip.

Также предположим, что вы находитесь ВНЕ вашего офиса, с вашим ноутбуком, подключенным по всему миру, с:

  • основной IP-адрес, назначенный вашим локальным интернет-провайдером (предположим, 192.168.0.33 с сетевой маской 255.255.255.0 и def-gw 192.168.0.1);
  • адрес PPP0, назначенный вашему ноутбуку вашим удаленным сервером PPTP (после успешного установления VPN-туннеля). Предположим, что PPP0 - это.local.ppp0.ip, а удаленный P2P - адрес.remote.pptp. Другими словами, ваш ноутбук знает, что это.local.ppp0.ip, а также знает, что на другой стороне туннеля VPN есть доступный через VPN сервер PPTP по адресу.remote.pptp.address.

В таком сценарии, если вы неспособный - с ноутбука - чтобы добраться до AWS по адресу your.ec2.ip.address, держу пари, что проблема - как вы думаете - в маршрутизации: ваш SSH-трафик, направленный на your.ec2.ip.address, является НЕ оставляя свой нетбук в пределах VPN, но вместо этого уходит по общему пути внешнего VPN (он же: отправляется на ваш локальный шлюз: 192.168.0.1).

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

  • Linux: трассировка команда (например: "tracepath -n your.ec2.ip.address")
  • windows: команда "tracert" (например: "tracert -d your.ec2.ip.address")

Из выходных данных вы можете проверить, сообщает ли второй шаг адреса PPTP или нет.

Если ваш трафик движется по неверному пути, простое решение для его маршрутизации в VPN:

  • Linux: "route add -host your.ec2.ip.address gw the.remote.pptp.address"
  • Windows: "route add your.ec2.ip.address mask 255.255.255.255 the.remote.pptp.address"

После настройки указанного выше маршрута вы можете еще раз проверить маршрутизацию с помощью tracert / tracepath.

После правильной настройки маршрутизации существует небольшая вероятность того, что проблемы могут возникнуть в вашем офисе: если ваш PPTP-сервер НЕ при IP-переадресации и NAT-трансляции высока вероятность того, что вы испытаете «фильтрацию» в случае отсутствия ip-forwarding или «асимметричной маршрутизации» (в случае отсутствия NAT) между вашим ноутбуком и your.ec2.ip .адрес:

  • трафик от вас к Amazon, идет по VPN к вашему офису, а затем - к Amazon;
  • возвращает трафик от Amazon к вам, направляется по общему интернет-пути и ... высока вероятность, что он куда-то упал.

Еще раз: tracepath / tracert может помочь вам определить проблему.

В Linux-боксах еще одним очень полезным другом является tcpdump. Вот несколько полезных команд tcpdump:

  • "tcpdump -n -i интерфейс icmp "для проверки входящих / исходящих запросов / ответов PING;
  • "tcpdump -n -i хост an.ip.add.ress«проверять трафик, приходящий / отправляемый на an.ip.add.ress;