Conexão SSH sobre VPN

Temos um servidor AWS EC2 que configuramos para ser acessível apenas (via SSH) de dentro da rede do escritório. Obviamente, isso não é ideal para arranjos remotos em que alguém precisa se conectar à instância do EC2 e está trabalhando remotamente fora do escritório, como durante uma viagem de negócios.

Eu consegui configurar uma VPN por meio de PPTP e posso conectar-me à rede do escritório (eu tenho dois IPs locais, um da wlan0 e um da ppp0), independentemente de onde eu estiver. No entanto, quando eu SSH para a instância do EC2, ele ainda está me rejeitando, provavelmente porque percebe que ainda estou tentando fazer ssh de fora da rede.

Acho que o problema é que não consigo rotear o tráfego ssh para passar pela VPN. Alguma idéia de como posso fazer isso?

Minha outra opção é ssh para uma máquina dentro da rede do escritório e depois usá-la para ssh para a instância do EC2, mas tenho hesitado em fazer isso, pois parece excessivo.

Suponhamos que sua AWS possa ser acessada via SSH no IP "your.ec2.ip.address". Suponhamos que a rede do seu escritório tenha acesso à Internet por meio de um roteador que aplique algumas traduções NAT e, como tal, os PCs do seu escritório sejam vistos na Internet com o IP "your.office.external.ip".

Suponhamos também que você esteja localizado FORA do seu escritório, com o laptop conectado ao redor do mundo, com:

• um endereço IP principal atribuído pelo seu provedor de Internet local (suponha 192.168.0.33 com máscara de rede 255.255.255.0 e def-gw 192.168.0.1);
• um endereço PPP0, atribuído ao seu laptop pelo servidor PPTP remoto (depois que seu túnel VPN for estabelecido com êxito). Suponhamos que o PPP0 seja o.local.ppp0.ip com o P2P remoto o endereço.remote.pptp. Em outras palavras, seu laptop sabe ser o.local.ppp0.ip e também sabe que, do outro lado do túnel da VPN, seu servidor PPTP pode ser acessado, através da VPN, no endereço.remote.pptp.

Nesse cenário, se você não conseguir - do seu notebook - acessar a AWS em "your.ec2.ip.address", aposto que o problema é - como você acha - roteamento: seu tráfego SSH direcionado para " your.ec2.ip.address " NÃO está deixando seu netbook na VPN, mas está deixando o caminho comum de VPN externa (também conhecido como: é enviado para o gateway local: 192.168.0.1).

Para diagnosticar esse problema, uma verificação muito fácil pode ser feita com:

• Linux: o comando tracepath (es .: "tracepath -n your.ec2.ip.address")
• windows: o comando "tracert" (es .: "tracert -d your.ec2.ip.address")

Na saída, você pode verificar se a segunda etapa relata endereços PPTP ou não.

Se o seu tráfego estiver percorrendo o caminho errado, a solução fácil para rotea-lo na VPN é:

• Linux: "route add -host your.ec2.ip.address gw the.remote.pptp.address"
• Windows: "rota adicione sua máscara.ec2.ip.address 255.255.255.255 the.remote.pptp.address"

Depois de configurar a rota acima, você pode verificar novamente o roteamento com tracert / tracepath

Depois que o roteamento estiver configurado corretamente, há uma pequena probabilidade de que possam surgir problemas no seu escritório: se o servidor PPTP NÃO estiver encaminhando IP e traduções NAT, há uma alta probabilidade de que você experimentará "filtragem", no caso de encaminhamento de ip ausente ou "roteamento assimétrico" (no caso de falta de NAT) entre o notebook e o endereço your.ec2.ip.

• o tráfego de você para a amazon, viaja ao longo da VPN para o seu escritório e, a partir de então, para a amazon;
• devolva o tráfego da Amazon para você, é roteado ao longo do caminho comum da Internet e ... as chances são altas, caiu em algum lugar.

Novamente: tracepath / tracert pode ajudá-lo a verificar o problema.

Nas caixas Linux, outro amigo muito útil é "tcpdump". Alguns comandos úteis do tcpdump são:

• "tcpdump -n -i interface icmp" para verificar solicitação / resposta de entrada / saída de PING;
• "tcpdump -n -i host an.ip.add.ress " para verificar o tráfego que chega / é enviado para an.ip.add.ress;