通过VPN连接的SSH

我们有一个AWS EC2服务器，我们已经configuration为只能通过我们的办公networking访问（通过SSH）。很明显，这对于远程安排来说并不理想，因为有些人必须连接到EC2实例，并且在办公室之外远程工作，例如在出差期间。

我设法通过PPTPbuild立一个VPN，并且可以连接到办公室networking（我有两个本地IP，一个来自wlan0，一个来自ppp0），无论我在哪里。但是，当我SSH到EC2的实例，它仍然拒绝我最有可能的，因为它看到我仍然试图从networking外ssh。

我想问题是，我不能路由SSH通信通过VPN。任何想法我可以做到这一点？

我的另一个select是ssh到办公室networking内的一台机器，然后使用该机器ssh到EC2的实例，但我一直在做，因为它似乎过度。

假设您的AWS可以通过IP“your.ec2.ip.address”上的SSH访问。假设你的办公室networking通过一个应用了一些NAT转换的路由器来访问互联网，因此，你的办公室PC可以在互联网上看到IP“your.office.external.ip”。

假设你位于你办公室的外面，你的笔记本电脑连接到世界各地：

由本地Internet提供商分配的主IP地址（让我们假设192.168.0.33的networking掩码为255.255.255.0，def-gw为192.168.0.1）;
一个PPP0地址，通过远程PPTP服务器分配给你的笔记本电脑（一旦你的VPN隧道成功build立）。假设PPP0是远程P2P the.remote.pptp.address的.local.ppp0.ip。换句话说，您的笔记本电脑知道是.local.ppp0.ip，并且知道在VPN隧道的另一端，您的PPTP服务器可以通过VPN访问.remote.pptp.address。

在这种情况下，如果您无法从笔记本电脑上以“your.ec2.ip.address”的forms访问您的AWS，我敢打赌问题是 – 您猜测 – 路由：您的SSHstream量指向“ your.ec2.ip.address“ 不会离开您的上网本，而是离开公共的外部VPNpath（又名：发送到您的本地网关：192.168.0.1）。

为了诊断这个问题，可以通过以下方式进行非常简单的检查：

Linux： tracepath命令（例如：“tracepath -n your.ec2.ip.address”）
windows：“tracert”命令（例如：“tracert -d your.ec2.ip.address”）

从输出你可以检查是否第二步报告PPTP地址，或不。

如果您的stream量沿着错误的path行进，那么在VPN内简单修复它的path是：

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”

configuration上述路由后，可以使用tracert / tracepath重新检查路由

一旦路由configuration正确，你的办公室里出现问题的可能性很小：如果你的PPTP服务器不做IP转发和NAT转换，那么很有可能你会遇到“过滤”的情况在笔记本和your.ec2.ip.address之间缺lessip-forwarding或“非对称路由”（如果缺lessNAT）

从你到亚马逊的stream量，沿着VPN到你的办公室，然后到亚马逊;
返回从亚马逊stream量到你，得到沿着普通的互联网path和…机会很高，这是放弃的地方。

再一次：tracepath / tracert可以帮助你检查问题。

在Linux上，另一个非常有用的朋友是“tcpdump”。一些有用的tcpdump命令是：

“tcpdump -n -i interface icmp”检查入局/出局PING请求/响应;
“tcpdump -n -i host an.ip.add.ress ”来检查到达/发送到an.ip.add.ress的stream量;