Supposons que votre AWS soit accessible via SSH sur IP "your.ec2.ip.address". Supposons que votre réseau de bureau dispose d'un accès Internet via un routeur qui applique certaines traductions NAT et, en tant que tel, vos ordinateurs de bureau sont visibles, sur Internet, avec l'IP "your.office.external.ip".
Supposons également que vous vous trouviez À L'EXTÉRIEUR de votre bureau, avec votre ordinateur portable connecté dans le monde entier, avec:
- une adresse IP principale attribuée par votre fournisseur Internet local (supposons que 192.168.0.33 avec le masque de réseau 255.255.255.0 et def-gw 192.168.0.1);
- une adresse PPP0, attribuée à votre ordinateur portable par votre serveur PPTP distant (une fois votre tunnel VPN établi avec succès). Supposons que PPP0 est the.local.ppp0.ip avec P2P distant the.remote.pptp.address. En d'autres termes, votre ordinateur portable sait être the.local.ppp0.ip et sait également que de l'autre côté du tunnel VPN, votre serveur PPTP est accessible, via le VPN, à l'adresse.remote.pptp.address.
Dans un tel scénario, si vous ne parvenez pas - depuis votre ordinateur portable - à atteindre votre AWS à l'adresse "your.ec2.ip.address", je parie que le problème est - comme vous le devinez - le routage: votre trafic SSH dirigé vers " your.ec2.ip.address " ne laisse PAS votre netbook dans le VPN, mais au lieu de cela, le long du chemin commun, VPN externe (aka: est envoyé à votre passerelle locale: 192.168.0.1).
Pour diagnostiquer ce problème, une vérification très simple peut être effectuée avec:
- Linux: la commande tracepath (es .: "tracepath -n your.ec2.ip.address")
- windows: la commande "tracert" (es .: "tracert -d your.ec2.ip.address")
À partir de la sortie, vous pouvez vérifier si la deuxième étape rapporte des adresses PPTP ou non.
Si votre trafic suit le mauvais chemin, la solution simple pour l'acheminer dans le VPN est:
- Linux: "route add -host your.ec2.ip.address gw the.remote.pptp.address"
- Windows: "route ajoutez votre.ec2.ip.address masque 255.255.255.255 the.remote.pptp.address"
Après avoir configuré l'itinéraire ci-dessus, vous pouvez vérifier à nouveau le routage avec tracert / tracepath
Une fois le routage correctement configuré, il y a une faible probabilité que des problèmes surviennent au sein de votre bureau: si votre serveur PPTP ne fait PAS de transfert IP et de traductions NAT, il y a une forte probabilité que vous rencontriez un "filtrage", en cas de IP-forwarding manquant ou "routage asymétrique" (en cas de NAT manquant) entre votre ordinateur portable et votre.ec2.ip.address:
- le trafic de votre part vers amazon, le long du VPN jusqu'à votre bureau et, depuis, vers Amazon;
- renvoyer le trafic d'Amazon vers vous, est acheminé le long du chemin Internet commun et ... les chances sont élevées, il a chuté quelque part.
Encore une fois: tracepath / tracert peut vous aider à vérifier le problème.
Sur les boîtiers Linux, un autre ami très utile est "tcpdump". Certaines commandes utiles de tcpdump sont:
- "tcpdump -n -i interface icmp" pour vérifier la demande / réponse PING entrante / sortante;
- "tcpdump -n -i host an.ip.add.ress " pour vérifier le trafic arrivant / envoyé à an.ip.add.ress;