web-dev-qa-db-fra.com

Connexion SSH sur VPN

Nous avons un serveur AWS EC2 que nous avons configuré pour être uniquement accessible (via SSH) à partir de notre réseau de bureau. Évidemment, ce n'est pas idéal pour les arrangements à distance où quelqu'un doit se connecter à l'instance EC2 et travaille à distance en dehors du bureau, comme lors d'un voyage d'affaires.

J'ai réussi à configurer un VPN via PPTP et je peux me connecter au réseau du bureau (j'ai deux adresses IP locales, une de wlan0 et une de ppp0), peu importe où je me trouve. Cependant, quand je SSH à l'instance EC2, il me rejette toujours très probablement parce qu'il voit que j'essaye toujours de ssh de l'extérieur du réseau.

Je suppose que le problème est que je ne peux pas acheminer le trafic ssh pour passer par le VPN. Des idées comment je peux y arriver?

Mon autre option est de ssh vers une machine dans le réseau du bureau, puis d'utiliser cette machine pour ssh vers l'instance EC2, mais j'ai hésité à le faire car cela semble excessif.

11
turntwo

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 des traductions NAT et, à ce titre, vos PC de bureau sont visibles, sur Internet, avec l'adresse IP "your.office.external.ip ".

Supposons également que vous vous trouviez [~ # ~] en dehors de [~ # ~] 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 serveur distant (une fois que votre tunnel VPN est correctement établi). Supposons que PPP0 est the.local.ppp0.ip avec P2P distant the.remote. 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 il y a votre PPTP accessible, via le VPN , à l'adresse.remote.pptp.

Dans un tel scénario, si vous êtes incapable - depuis votre ordinateur portable-- pour atteindre votre AWS à "votre.ec2.ip.adresse", je parie que le problème est - comme vous le devinez-- le routage : votre trafic SSH dirigé vers "your.ec2.ip.address" est [~ # ~] pas [~ # ~] laissant votre netbook dans le VPN, mais, à la place, laisse le long du chemin commun, VPN externe (alias: 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 le rapport de la deuxième étape PPTP adresses, 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 dans votre bureau: si votre serveur PPTP est [~ # ~] pas [~ # ~] en faisant le transfert IP et les traductions NAT, il y a une forte probabilité que vous rencontriez un "filtrage", en cas de transfert ip manquant ou de "routage asymétrique" (en cas de NAT manquant) entre votre ordinateur portable et votre.ec2.ip.address:

  • le trafic de vous vers Amazon, se déplace le long du VPN vers 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 tcpdump utiles 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;
15
Damiano Verzulli