SSH przez połączenie VPN

Mamy serwer AWS EC2, który skonfigurowaliśmy tak, aby był dostępny tylko (przez SSH) z naszej sieci biurowej. Oczywiście nie jest to idealne rozwiązanie do zdalnych ustaleń, w których ktoś musi połączyć się z instancją EC2 i pracuje zdalnie poza biurem, na przykład podczas podróży służbowej.

Udało mi się skonfigurować VPN przez PPTP i mogę połączyć się z siecią biurową (mam dwa lokalne adresy IP, jeden z wlan0 i jeden z ppp0) niezależnie od tego, gdzie jestem. Jednak gdy przesyłam SSH do instancji EC2, najprawdopodobniej nadal mnie odrzuca, ponieważ widzi, że wciąż próbuję ssh spoza sieci.

Myślę, że problem polega na tym, że nie mogę skierować ruchu ssh, aby przejść przez VPN. Jakieś pomysły, jak to osiągnąć?

Inną opcją jest połączenie ssh z komputerem w sieci biurowej, a następnie użycie tego komputera do ssh do instancji EC2, ale byłem niezdecydowany, aby to zrobić, ponieważ wydaje się to nadmierne.

Załóżmy, że Twój AWS jest osiągalny przez SSH pod adresem IP „twój.ec2.ip.adres”. Załóżmy, że twoja sieć biurowa ma dostęp do Internetu za pośrednictwem routera, który stosuje niektóre translacje translacji NAT, i dlatego komputery biurowe w biurze są widoczne w Internecie z adresem IP „two.office.external.ip”.

Załóżmy również, że znajdujesz się NA ZEWNĄTRZ swojego biura, z laptopem podłączonym na całym świecie, z:

• główny adres IP przypisany przez lokalnego dostawcę Internetu (załóżmy 192.168.0.33 z maską sieci 255.255.255.0 i def-gw 192.168.0.1);
• adres PPP0, przypisany do laptopa przez zdalny serwer PPTP (po pomyślnym ustanowieniu tunelu VPN). Załóżmy, że PPP0 to lokalny.ppp0.ip ze zdalnym P2P adres.remote.pptp. Innymi słowy, twój laptop wie, że jest to.lokalny.ppp0.ip, a także wie, że po drugiej stronie tunelu VPN znajduje się twój serwer PPTP, dostępny przez VPN, pod adresem .remote.pptp.

W takim scenariuszu, jeśli jesteś w stanie --from Twój notebook-- aby osiągnąć swoje AWS w „your.ec2.ip.address” Założę się, problem jest --as ty guess-- routingu: ruch skierowany do SSH " twój.ec2.ip.address ” NIE opuszcza twojego netbooka w sieci VPN, ale zamiast tego wychodzi wzdłuż wspólnej, zewnętrznej ścieżki VPN (inaczej: jest wysyłany do lokalnej bramy: 192.168.0.1).

Aby zdiagnozować ten problem, można bardzo łatwo sprawdzić za pomocą:

• Linux: polecenie tracepath (es .: "tracepath -n your.ec2.ip.address")
• Windows: polecenie „tracert” (np .: „tracert -d twój.ec2.ip.address”)

Na podstawie danych wyjściowych możesz sprawdzić, czy w drugim kroku zgłaszane są adresy PPTP, czy nie.

Jeśli ruch odbywa się niewłaściwą ścieżką, łatwym rozwiązaniem w celu jego trasowania w sieci VPN jest:

• Linux: „route add -host your.ec2.ip.address gw the.remote.pptp.address”
• Windows: „route dodaj maskę.ec2.ip.address 255.255.255.255 the.remote.pptp.address”

Po skonfigurowaniu powyższej trasy możesz ponownie sprawdzić routing za pomocą tracert / tracepath

Po prawidłowym skonfigurowaniu routingu istnieje niewielkie prawdopodobieństwo wystąpienia problemów w biurze: jeśli serwer PPTP NIE wykonuje przekazywania IP i translacji NAT, istnieje duże prawdopodobieństwo, że wystąpi „filtrowanie” w przypadku brak przekazywania IP lub „routing asymetryczny” (w przypadku braku NAT) między notebookiem a adresem.ec2.ip.:

• ruch od ciebie do Amazon, podróżuje wzdłuż VPN do twojego biura, a następnie do Amazon;
• zwrócić ruch z Amazon do ciebie, zostaje poprowadzony wspólną ścieżką internetową i ... są duże szanse, że gdzieś spadł.

Ponownie: tracepath / tracert może pomóc w sprawdzeniu problemu.

W Linuksie innym bardzo przydatnym przyjacielem jest „tcpdump”. Niektóre przydatne polecenia tcpdump to:

• „tcpdump -n -i interface icmp”, aby sprawdzić przychodzące / wychodzące żądanie / odpowiedź PING;
• „tcpdump -n -i host an.ip.add.ress ”, aby sprawdzić ruch przychodzący / wysyłany na adres an.ip.add.ress;