SSH Tunnel – Virtual Private Networing with SSH

Saturday, 20. November 2010

Auch mit SSH ist es möglich ein VPN aufzuziehen. Dieses Howto versteht sich als Erweiterung zu ISA Firewall/Proxy sucks! -or- How to make it disappear! Es ermöglicht auf das Portforwarding und den OpenVPN Tunnel zu verzichten und das VPN gleich mittels SSH aufzuziehen! (die ssh Verbindung müsste in diesem Falle natürlich zum localhost : 1443 aufgenommen werden auf welchem cntlm lauscht – siehe ISA Firewall/Proxy sucks! -or- How to make it disappear! )

———————————————–

 

Client B (Default Gateway: 10.1.1.1) —> Server A (WAN IP: 1.2.3.4 [myserver.com] SSH Port: 443) Vorbereitung: Auf beiden Maschinen wird das IP forwarding aktiviert:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
ssh root@myserver.com -p 443 'echo 1 |tee /proc/sys/net/ipv4/ip_forward'
 

Die SSH Daemons müssen über die Datei /etc/ssh/sshd_config so konfiguriert werden, dass ein VPN Tunnel sowie der root Login erlaubt ist:

PermitRootLogin yes
PermitTunnel yes

(Im Optimalfall hat man für weiteres Vorgehen sshd so konfiguriert, dass man ohne Password mit Zertifikat einloggen kann) Jetzt baut man den SSH Tunnel auf. Die folgende Konfiguration sorgt dafür, dass der Tunnel zum Server geschlagen wird, auf dem Client wie auch am Server ein Device namens “tun0” erstellt wird und im gleichen Terminal weitergearbeitet werden kann. Wer sich tatsächlich zum Server verbinden will verzichtet auf N T und f .

sudo ssh -NTCf -w 0:0 root@myserver.com -p 443

Jetzt haben wir zwei unkonfigurierte “virtuelle” Netzwerkinterfaces (tun0) die nun für den Tunnel konfiguriert werden müssen:

local:

sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111

remote:

ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222

zu diesem Zeitpunkt kann man tun0 des Servers (10.0.0.111) bereits pingen (und vice versa). Jetzt binden wird das ganze Netz ein:

sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0

Durch diese Anweisung verwendet das 10er Netz das virtuelle Device tun0 als Gateway in die Freiheit.

ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub

Dies stellt im Netz des Servers sicher, dass Pakete die für 10.0.0.222 gedacht sind auch an den Server gesendet werden (damit dieser sie forwarden kann) Im letzten Schritt definieren wir für das gesamte 10er netz des Clients tun0 als default Gateway. Damit wird dem SSH Tunnel nicht den Ast absägen auf dem dieser gerade sitzt müssen wir aber zuerst für diese spezielle Verbindung eine eigene Route legen.

sudo route add 1.2.3.4 gw 10.1.1.1 eth0

Jetzt können wir einen neuen default Gateway setzen:

sudo route add default gw 10.0.0.111 tun0
und den alten löschen:
sudo route del default gw 10.1.1.1 eth0

Abschließend muss noch auf beiden Maschinen “masquerading” aktiviert werden

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Fertig! Wer sein Werk nun überprüfen will kann testweise mit folgendem Befehl den Verlauf der Pakete über das VPN verfolgen:

tracepath gmx.net

Im übrigen Netz kann man nun die IP des Client B als default Gateway eintragen um auch diese durch den VPN Tunnel zu schleusen.
glhf

Noch einmal alle Shellbefehle auf einem Fleck:

ssh root@myserver.com -p 443 'echo 1 | tee /proc/sys/net/ipv4/ip_forward'
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo ssh -NTCf -w 0:0 root@myserver.com -p 443
sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111
ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222
sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0
ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub
sudo route add 1.2.3.4 gw 10.1.1.1 eth0
sudo route add default gw 10.0.0.111 tun0
sudo route del default gw 10.1.1.1 eth0
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

PS: Man sollte sich bewusst sein, dass ein Umgehen der Sicherheitsvorkehrungen in den meisten Fällen nicht erwünscht ist und sogar ein Kündigungsgrund sein kann!

One Response to “SSH Tunnel – Virtual Private Networing with SSH”



  1. xapient Says:

    die ganze sache hat einen kleinen aber nicht unwesentlichen hacken…

    damit die vpn verbindung aufrecht bleiben kann muss zumindest eine eizige route gesetzt bleiben die über den ISA firewall/proxy geht.. nämlich die zum server.. das heisst dass alle angebote des servers selbst weiterhin ausgefiltert werden 🙁

    waahhhhhh.. grrrrrr.. hmpf.. 🙁

    Man kann diese selbstverständlich erreichen in dem man anstelle der externen IP des servers die interne virtuelle anspricht: zb.: ftp://10.0.0.111 da der server ja jetzt im lokalen netz liegt ^^ (da der apache server in der regel aber am externen interface lauscht wird dieser wohl meistens unerreichbar bleiben)