Connexion SSH sur VPN


11

Nous avons un serveur AWS EC2 que nous avons configuré pour être uniquement accessible (via SSH) à partir de notre réseau de bureau. De toute évidence, 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 IP locales, l'une de wlan0 et l'autre de ppp0), peu importe où je me trouve. Cependant, lorsque je SSH vers l'instance EC2, il me rejette probablement, car il voit que j'essaie 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.


La réponse courte est d'acheminer votre trafic SSH via le VPN. Et utilisez quelque chose d'un peu plus sécurisé que PPTP.
Hyppy

Réponses:


15

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;
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.