SSH über VPN-Verbindung

Wir haben einen AWS EC2-Server, den wir so konfiguriert haben, dass er nur über SSH innerhalb unseres Büronetzwerks zugänglich ist. Offensichtlich ist dies nicht ideal für Remote-Vereinbarungen, bei denen jemand eine Verbindung zur EC2-Instanz herstellen muss und remote außerhalb des Büros arbeitet, z. B. während einer Geschäftsreise.

Ich habe es geschafft, ein VPN über PPTP einzurichten und kann eine Verbindung zum Büronetzwerk herstellen (ich habe zwei lokale IPs, eine von wlan0 und eine von ppp0), unabhängig davon, wo ich mich befinde. Wenn ich jedoch eine SSH-Verbindung zur EC2-Instanz herstelle, lehne ich dies höchstwahrscheinlich immer noch ab, da ich immer noch versuche, von außerhalb des Netzwerks zu sshen.

Ich denke, das Problem ist, dass ich den SSH-Verkehr nicht weiterleiten kann, um über das VPN zu gehen. Irgendwelche Ideen, wie ich das erreichen kann?

Meine andere Option besteht darin, auf einen Computer innerhalb des Büronetzwerks zu sshen und diesen Computer dann zu verwenden, um auf die EC2-Instanz zu ssh, aber ich habe gezögert, dies zu tun, da dies übertrieben erscheint.

Angenommen, Ihr AWS ist über SSH unter der IP-Adresse "your.ec2.ip.address" erreichbar. Angenommen, Ihr Büronetzwerk verfügt über einen Internetzugang über einen Router, der einige NAT-Übersetzungen anwendet. Daher werden Ihre Büro-PCs im Internet mit der IP-Adresse "your.office.external.ip" angezeigt.

Nehmen wir außerdem an, Sie befinden sich AUSSERHALB Ihres Büros und Ihr Laptop ist weltweit verbunden mit:

• eine von Ihrem lokalen Internetanbieter zugewiesene Haupt-IP-Adresse (nehmen wir an, 192.168.0.33 mit Netzmaske 255.255.255.0 und def-gw 192.168.0.1);
• Eine PPP0-Adresse, die Ihrem Laptop von Ihrem Remote-PPTP-Server zugewiesen wurde (sobald Ihr VPN-Tunnel erfolgreich eingerichtet wurde). Angenommen, PPP0 ist die.local.ppp0.ip mit der Remote-P2P-Adresse.remote.pptp.address. Mit anderen Worten, Ihr Laptop ist die.local.ppp0.ip und weiß auch, dass sich auf der anderen Seite des VPN-Tunnels Ihr PPTP-Server über das VPN unter der.remote.pptp.address befindet.

Wenn Sie in einem solchen Szenario von Ihrem Notebook aus nicht in der Lage sind, Ihr AWS unter "your.ec2.ip.address" zu erreichen, liegt das Problem - wie Sie vermuten - im Routing: Ihr SSH-Verkehr wird an "geleitet. your.ec2.ip.address " verlässt Ihr Netbook NICHT im VPN, sondern auf dem gemeinsamen Pfad für externes VPN (auch bekannt als: wird an Ihr lokales Gateway gesendet: 192.168.0.1).

Um dieses Problem zu diagnostizieren, kann eine sehr einfache Überprüfung durchgeführt werden mit:

• Linux: der Befehl tracepath (es.: "Tracepath -n your.ec2.ip.address")
• windows: der Befehl "tracert" (es.: "tracert -d your.ec2.ip.address")

An der Ausgabe können Sie überprüfen, ob im zweiten Schritt PPTP-Adressen gemeldet werden oder nicht.

Wenn Ihr Datenverkehr auf dem falschen Weg verläuft, können Sie ihn einfach innerhalb des VPN weiterleiten:

• Linux: "route add -host your.ec2.ip.address gw the.remote.pptp.address"
• Windows: "route add your.ec2.ip.address mask 255.255.255.255 the.remote.pptp.address"

Nachdem Sie die obige Route konfiguriert haben, können Sie das Routing erneut mit tracert / tracepath überprüfen

Sobald das Routing richtig konfiguriert ist, besteht eine geringe Wahrscheinlichkeit, dass Probleme in Ihrem Büro auftreten: Wenn Ihr PPTP-Server KEINE IP-Weiterleitung und NAT-Übersetzungen ausführt, besteht eine hohe Wahrscheinlichkeit, dass im Falle von "Filterung" auftritt fehlende IP-Weiterleitung oder "asymetrisches Routing" (bei fehlendem NAT) zwischen Ihrem Notebook und Ihrer.ec2.ip.-Adresse:

• Der Datenverkehr von Ihnen nach Amazon wird über das VPN zu Ihrem Büro und von da an zu Amazon geleitet.
• Geben Sie den Datenverkehr von Amazon an Sie zurück, werden Sie über den üblichen Internetpfad weitergeleitet und ... die Wahrscheinlichkeit ist hoch, dass er irgendwo abgelegt wird.

Nochmals: tracepath / tracert kann Ihnen bei der Überprüfung des Problems helfen.

Ein weiterer sehr nützlicher Freund auf Linux-Boxen ist "tcpdump". Einige nützliche tcpdump-Befehle sind:

• "tcpdump -n -i interface icmp" zum Überprüfen der eingehenden / ausgehenden PING-Anforderung / Antwort;
• "tcpdump -n -i host an.ip.add.ress ", um den an an.ip.add.ress ankommenden / gesendeten Datenverkehr zu überprüfen;