AWSがSSH経由でIP "your.ec2.ip.address"に到達できると仮定しましょう。オフィスのネットワークが、NAT変換を適用するルーターを介してインターネットにアクセスしていて、オフィスのPCがインターネット上にIP "your.office.external.ip"で表示されているとします。
また、オフィスの外にいて、世界中でラップトップが接続されているとします。
- ローカルインターネットプロバイダーによって割り当てられたメインIPアドレス（ネットマスク255.255.255.0とdef-gw 192.168.0.1を含む192.168.0.33であるとします）。
- リモートPPTPサーバーによってラップトップに割り当てられたPPP0アドレス（VPNトンネルが正常に確立された後）。PPP0がリモートP2P the.remote.pptp.addressを持つthe.local.ppp0.ipであるとしましょう。つまり、ラップトップはthe.local.ppp0.ipであることがわかり、VPNトンネルの反対側には、VPN経由で.remote.pptp.addressに到達可能なPPTPサーバーがあることも知っています。
あなたがある場合は、そのようなシナリオでは、できないあなたのSSHトラフィックがに向け"：「your.ec2.ip.address」であなたのAWSに到達する--fromあなたnotebook--私はこの問題は、あなたがルーティングguess-- --asで賭けますyour.ec2.ip.address」は、VPN内でネットブックを離れませんが、代わりに、共通の外部VPNパスに沿って離れます（別名：はローカルゲートウェイに送信されます：192.168.0.1）。
この問題を診断するには、次の方法で非常に簡単なチェックを実行できます。
- Linux：tracepathコマンド（es .: "tracepath -n your.ec2.ip.address"）
- Windows： "tracert"コマンド（例： "tracert -d your.ec2.ip.address"）
出力から、2番目のステップが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サーバーがされている場合、NOT IP転送およびNAT-の翻訳をやって、あなたがの場合には、「フィルタリング」を体験しましょう確率が高いのですノートブックとyour.ec2.ip.address間のip-forwardingまたは "asymetric routing"（NATがない場合）がない：
- あなたからアマゾンへのトラフィックは、VPNに沿ってオフィスへ、そしてその後はアマゾンへと移動します。
- アマゾンからあなたへの戻りトラフィック、一般的なインターネットパスに沿ってルーティングされます。
繰り返しますが、tracepath / tracertは問題のチェックに役立ちます。
Linuxボックスでは、もう1つの非常に便利な友達が「tcpdump」です。いくつかの便利なtcpdumpコマンドは次のとおりです。
- 「tcpdump -n -i interface icmp」。着信/発信PING要求/応答をチェックします。
- "tcpdump -n -i host an.ip.add.ress "は、an.ip.add.ressに到着/送信されたトラフィックをチェックします。