SSH bei aufgebautem VPN-Tunnel?

cyberpatch

Junior Member
Hallo,

ich habe hier einen Raspberry (Wheezy) auf den ich ohne Probleme per SSH (von außerhalb) zugreifen kann. Sobald ich allerdings eine VPN-Verbindung (openvpn) damit herstellen (z.B. zu Gigabit-DE). ist der Zugriff per SSH nicht mehr möglich (von außerhalb; im lokalem Netz geht das weiterhin).

Ich denke mal, dass das ein simples Routingproblem ist. Bei aufgebauter VPN-Verbindung wird ja sicherlich alles über den VPN-Tunnel gehen. Leider bin ich nich so bewandert mit diesem Thema, dass ich mir selbst helfen könnt.

Vieleicht kann mir hier jemand erklären, wie ich bei einer VPN-Verbindung zusätzlich per SSH auf meinen Raspberry zugreifen kann. Es soll auch nur die SSH-Verbindung möglich sein. Der restliche Datenverkehr soll selbstverständlich über den VPN-Tunnel laufen.

Danke,

Cyberpatch
 

PP Frank

Staff member
Kannst du denn was pingen? Versuchs da erstmal mit einem Domainnamen und danach mit einer IP. ich vermute mal das ist ein DNS Problem.
 

cyberpatch

Junior Member
PP Frank;n4937 said:
Kannst du denn was pingen? Versuchs da erstmal mit einem Domainnamen und danach mit einer IP. ich vermute mal das ist ein DNS Problem.

Sieht zur zeit wie folgt aus:

Modem/Router: 192.168.1.1 / öffentliche IP 31.50.77.19
Raspberry: 192.168.1.2

Auf dem Router ist eine Portweiterleitung auf Port 22 auf 192.168.1.2 eingerichtet. Über das Internnet kann ich mit einem anderem Rechner per ssh root@31.50.77.19 auf meinem Raspberry zugreifen. Baue ich jetzt mit dem Raspberry allerdings eine VPN-Verbindung zu Gigabit-DE auf komme ich von auserhalb nicht mehr per SSH auf meinen Raspberry. Das ganze ist wohl ein Routingproblem. Die ssh-Verbindung geht vermutlich bei meinem Raspberry ein, die Antwort wird dann aber wohl über den VPN-Tunnel gehen und landet somit nie bei meinem entfernten Rechner.

Sicherlich kann man jetzt eine route auf das Standardgateway 192.168.1.1 einrichten aber damit umgeht man ja dann den VPN-Tunnel. Ich suche also eine Möglichkeit, nur den Verkehr von ssh über die öffentliche IP und nicht über den VPN-Tunnel zu leiten.

Achja, ein DNS Problem habe ich nicht. Ich kann mit und ohne VPN-Verbindung alles pingen und erreichen.
 

JackCarver

Junior Member
Ja das ist ein Routingproblem, da die default Route des Pi nun der VPN Server ist. Du kommst zwar von außerhalb am Pi an, das erledigt ja dein Portforward aber die Antwort findet dich nicht. Du kannst mehr als eine default Route unter Linux haben, das funktioniert allerdings nicht mit den alten Routing Befehlen wie route usw, sondern mit den neuen Linux Advanced Routing and Traffic Control Befehlen, die weit mächtiger sind. Dort kannst du unterschiedlich Routing Tabellen mit jeweils unterschiedlichen default Routen anlegen und das ganze auch nach ner Policy steuern. Zb kannst du Pakete mit Zielport 22 per iptables markieren und diese markierten Pakete dann über ne andere default Route direkt über deinen Router senden. Dann klappt das wieder mit ssh, guck mal hier: http://www.lartc.org/lartc.html
 

JackCarver

Junior Member
Ich hab das mal lokal getestet und das was du erreichen willst ist nicht allzu schwer zu lösen ;-)

Ich geh jetzt mal von folgendem aus:

Dein Netzwerk: 192.168.0.0/24
Dein Router: 192.168.0.1
Dein Pi: 192.168.0.10
Deine Netzwerkschnittstelle: wlan0
Wie ich bereits gesagt habe, hast du unter Linux die Möglichkeit neben der Haupt-Routingtabelle Names main mittels der iproute2 Befehle bis zu 255 weitere Routing Tabellen zu definieren alle mit unterschiedlichen default Routen.
Die Auswahl, welche Tabelle von den Paketen genommen wird stellst du über sogenannte Routing Regeln auf. Das ganze funktioniert folgendermaßen:

Du erstellst zunächst eine neue Routing Tabelle:
echo "252 ohne.vpn" >> /etc/iproute2/rt_tables

Dann erstellst du in dieser Tabelle 2 Standard Regeln für den Pi
1, Default Route in der neuen Tabelle über deinen Router
ip route add default dev wlan0 via 192.168.0.1 table ohne.vpn

2, Route in dein lokales LAN:
ip route add 192.168.0.0/24 dev wlan0 src 192.168.0.10 table ohne.vpn

Nun fügst du als letztes die Regel hinzu, von welchen Paketen die neue Tabelle ohne.vpn genommen werden soll:
ip rule add from 192.168.0.10 lookup ohne.vpn
Das war's schon, sobald du mit OpenVPN verbunden bist hat dein Pi ja 2 IP Adressen, einmal die ihm der Server zuweist und die der Adapter tun0 hat und einmal die, die der Standard Adapter wlan0 hat.
Sobald nun ein Paket von der Adresse von wlan0 des Pi ausgeht greift die Regel mittels from 192.168.0.10 und sieht in der Tabelle ohne.vpn nach. Dort ist die default Route über deinen Router, was du ja auch benötigst, dass die ssh Verbindung zustande kommt.
Alle übrigen Pakete kursieren im VPN Netz mit ner 10er IP und für die gilt die Tabelle main, welche alle Pakete über den VPN Server zwingt, dh alle ausser ssh Pakete.
 

JackCarver

Junior Member
Diese Regeln sind übrigens nicht an nen SSH Server auf dem Pi gebunden, sondern für jeden Serverdienst auf dem Pi, den du von aussen erreichen möchtest. Alles vom Pi selbst aus läuft über VPN, alles worauf ein Serverdienst auf dem Pi auf Anfragen von aussen antwortet läuft direkt über deinen Router.

Im Unterschied zu dem alten Befehl route, der nur auf der Tabelle main arbeitet hast du also mit ip route die Möglichkeit Routen zu den unterschiedlichsten Tabellen hinzuzufügen und über die Policy Regeln mit ip rule zu bestimmen wann welche Tabelle genommen werden soll.

Klassisches Beispiel aus dem LARTC Manual ist zb dafür, dass du zwei DSL Zugänge hast, zb einen ADSL 6 Mbit und einen VDSL 50 Mbit. Du könntest dann zb nen Linux PC als Router mit zwei Netzwerkkarten eth0 und eth1 einrichten, der Anfragen aus dem 192.168.1.0/24er Netz über die ADSL Leitung und Anfragen aus dem 192.168.2.0/24er Netz auf die VDSL Leitung routet.

Simpel mit:
ip rule add from 192.168.1.0/24 lookup table adsl
ip rule add from 192.168.2.0/24 lookup table vdsl

Die Tabellen natürlich vorher in die rt_tables hinzufügen und dann jeweils unterschiedliche Default Routen adden:

ip route add default dev eth0 via 192.168.1.1 table adsl
ip route add default dev eth1 via 192.168.2.1 table vdsl

That's all :)
 
Top