Supongamos que se puede acceder a su AWS a través de SSH en IP "your.ec2.ip.address". Supongamos que la red de su oficina tiene acceso a Internet a través de un enrutador que aplica algunas traducciones NAT y, como tal, las PC de su oficina se ven, en Internet, con IP "your.office.external.ip".
Supongamos también que se encuentra FUERA de su oficina, con su computadora portátil conectada en todo el mundo, con:
- una dirección IP principal asignada por su proveedor de Internet local (supongamos 192.168.0.33 con netmask 255.255.255.0 y def-gw 192.168.0.1);
- una dirección PPP0, asignada a su computadora portátil por su servidor PPTP remoto (una vez que su túnel VPN se haya establecido con éxito). Supongamos que PPP0 es the.local.ppp0.ip con P2P remoto the.remote.pptp.address. En otras palabras, su computadora portátil sabe que es the.local.ppp0.ip y también sabe que al otro lado del túnel VPN hay un servidor PPTP accesible, a través de la VPN, en la dirección .remote.pptp.address.
En tal situación, si no puede, desde su computadora portátil, alcanzar su AWS en "your.ec2.ip.address" Apuesto a que el problema es, como adivina, enrutamiento: su tráfico SSH dirigido a " your.ec2.ip.address " NO deja su netbook dentro de la VPN, sino que abandona la ruta común de la VPN externa (también conocida como: se envía a su puerta de enlace local: 192.168.0.1).
Para diagnosticar este problema, se puede hacer una verificación muy fácil con:
- Linux: el comando tracepath (es .: "tracepath -n your.ec2.ip.address")
- windows: el comando "tracert" (es .: "tracert -d your.ec2.ip.address")
Desde el resultado puede verificar si el segundo paso informa las direcciones PPTP, o no.
Si su tráfico viaja por el camino equivocado, la solución fácil para enrutarlo dentro de la VPN es:
- Linux: "route add -host your.ec2.ip.address gw the.remote.pptp.address"
- Windows: "ruta agregue su máscara.ec2.ip.address 255.255.255.255 the.remote.pptp.address"
Después de configurar la ruta anterior, puede verificar nuevamente la ruta con tracert / tracepath
Una vez que el enrutamiento está configurado correctamente, existe una pequeña probabilidad de que surjan problemas dentro de su oficina: si su servidor PPTP NO está haciendo reenvío de IP y traducciones NAT, existe una alta probabilidad de que experimente "filtrado", en caso de falta de reenvío de IP o "enrutamiento asimétrico" (en caso de falta de NAT) entre su computadora portátil y su dirección.ec2.ip.
- tráfico de usted a Amazon, viaja a través de la VPN a su oficina y, desde entonces, a Amazon;
- devuelve el tráfico de Amazon a usted, se enruta a lo largo de la ruta común de Internet y ... es muy probable que se caiga en algún lugar.
Nuevamente: tracepath / tracert puede ayudarlo a verificar el problema.
En las cajas de Linux, otro amigo muy útil es "tcpdump". Algunos comandos útiles de tcpdump son:
- "tcpdump -n -i interface icmp" para verificar la solicitud / respuesta PING entrante / saliente;
- "tcpdump -n -i host an.ip.add.ress " para verificar el tráfico que llega / enviado a an.ip.add.ress;