Tipps & Tricks: VPN Kaskade unter Linux

JackCarver

Well-known Member
Hallo Community,
da die Frage danach aufkam möchte ich euch hier mal eine Methode vorstellen, mit der man auch unter Linux eine VPN Kaskade nutzen kann. Ich geh in dieser Anleitung nur auf das Routing ein, das dazu nötig ist. Wie man sich zu den jeweiligen Servern verbindet (GUI/Terminal) bleibt jedem selbst überlassen. Im Test hatte ich das Terminal zum Verbinden genutzt.

Diese Methode ist vom Routing her etwas aufwändiger, hat aber den Vorteil, dass man die Kaskade auch wieder Stück für Stück abbauen kann und dabei stets über einen VPN Server verbunden ist, bis man zu guter Letzt wieder über den Router surft. Die hinzugefügten Routen werden dabei alle wieder selbständig gelöscht, mit Ausnahme einer einzigen, die per Hand zu löschen ist. Dazu später mehr. Die Kaskade soll bei max 4 Servern liegen, dabei können natürlich auch kürzere Kaskaden genutzt werden.

Vorbereitung:
Zunächst einmal lädt man sich die Linux PP Configs herunter, ich hatte im Test die Config ppConfig_linux.zip genutzt.

Im Test hatte ich folgende Kaskade aufgebaut:
1, Prag
2, Steinsel
3, Paris
4, Huenenberg

Zu diesen 4 genannten Verbindungen editiert man die jeweilige .ovpn Datei danach, dass in allen die Option:
Code:
route-noexec
hinzugefügt wird. Diese verhindert das automatische Anpassen der Routen durch OpenVPN, das wir selbst erledigen müssen.

1, Verbindung:
Man verbindet sich zu PP Prag und notiert sich die externe IP des Servers (kann aus dem Log entnommen werden), sowie die interne VPN IP des Servers (via ifconfig über die IP bei tun0).
Dazu gibt es folgende Möglichkeiten:

Hat der Client unter tun0 die IP 10.41.12.n mit n < 128, so ist die interne Server-IP die 10.41.12.1.
Hat der Client die IP 10.41.12.n mit n > 129, so ist die interne Server-ip die 10.41.12.129.

Server-IP (extern): 1.2.3.4
Server-IP (interne VPN): 10.41.12.129
Router-IP: 192.168.1.1

Routing:
Code:
sudo route add 1.2.3.4/32 gw 192.168.1.1
sudo route add -net 0.0.0.0/1 gw 10.41.12.129
sudo route add -net 128.0.0.0/1 gw 10.41.12.129

Nun testet man zb unter www.whoer.net ob sich die IP nun auf Prag geändert hat.

2, Verbindung:
Man verbindet sich zu PP Steinsel und notiert sich wieder die externe Server-IP, sowie die interne VPN IP des Servers:

Server-IP (extern): 5.6.7.8
Server-IP (interne VPN): 10.14.21.129
Server-IP (interne VPN IP des Vorgängers): 10.41.12.129

Routing:
Code:
sudo route add 5.6.7.8/32 gw 10.41.12.129
sudo route add -net 0.0.0.0/2 gw 10.14.21.129
sudo route add -net 64.0.0.0/2 gw 10.14.21.129
sudo route add -net 128.0.0.0/2 gw 10.14.21.129
sudo route add -net 192.0.0.0/2 gw 10.14.21.129

Auch hier sollte sich über whoer nun eine Lux-IP zeigen.

3, Verbindung:
Man verbindet sich zu PP Paris und notiert sich wieder die externe Server-IP, sowie die interne VPN IP des Servers:

Server-IP (extern): 9.10.11.12
Server-IP (interne VPN): 10.17.12.1
Server-IP (interne VPN IP des Vorgängers): 10.14.21.129

Routing:
Code:
sudo route add 9.10.11.12/32 gw 10.14.21.129
sudo route add -net 0.0.0.0/3 gw 10.17.12.1
sudo route add -net 32.0.0.0/3 gw 10.17.12.1
sudo route add -net 64.0.0.0/3 gw 10.17.12.1
sudo route add -net 96.0.0.0/3 gw 10.17.12.1
sudo route add -net 128.0.0.0/3 gw 10.17.12.1
sudo route add -net 160.0.0.0/3 gw 10.17.12.1
sudo route add -net 192.0.0.0/3 gw 10.17.12.1
sudo route add -net 224.0.0.0/3 gw 10.17.12.1

4, Verbindung:
Man verbindet sich zu PP Huenenberg und notiert sich wieder die externe Server-IP, sowie die interne VPN IP des Servers:

Server-IP (extern): 13.14.15.16
Server-IP (interne VPN): 10.24.13.1
Server-IP (interne VPN IP des Vorgängers): 10.17.12.1

Routing:
Code:
sudo route add 13.14.15.16/32 gw 10.17.12.1
sudo route add -net 0.0.0.0/4 gw 10.24.13.1
sudo route add -net 16.0.0.0/4 gw 10.24.13.1
sudo route add -net 32.0.0.0/4 gw 10.24.13.1
sudo route add -net 48.0.0.0/4 gw 10.24.13.1
sudo route add -net 64.0.0.0/4 gw 10.24.13.1
sudo route add -net 80.0.0.0/4 gw 10.24.13.1
sudo route add -net 96.0.0.0/4 gw 10.24.13.1
sudo route add -net 112.0.0.0/4 gw 10.24.13.1
sudo route add -net 128.0.0.0/4 gw 10.24.13.1
sudo route add -net 144.0.0.0/4 gw 10.24.13.1
sudo route add -net 160.0.0.0/4 gw 10.24.13.1
sudo route add -net 176.0.0.0/4 gw 10.24.13.1
sudo route add -net 192.0.0.0/4 gw 10.24.13.1
sudo route add -net 208.0.0.0/4 gw 10.24.13.1
sudo route add -net 224.0.0.0/4 gw 10.24.13.1
sudo route add -net 240.0.0.0/4 gw 10.24.13.1

Damit hat man zum Schluss die Kaskade über 4 Server. Trennt man nun die Verbindung zu Huenenberg, so surft man wieder über Paris, trennt man Paris so ruft man wieder über Steinsel usw. Beim Trennen der einzelnen Verbindungen werden alle Routen, die über irgendeine interne VPN Server IP gehen automatisch gelöscht, übrig bleibt nur die Route die über den Router nach PP Prag geht. Man kann sich das über ein:
Code:
route -n
anzeigen lassen.

Diese Route löscht man über ein:
Code:
sudo route del 1.2.3.4/32 gw 192.168.1.1

Damit ist die Routing Tabelle von allen Einträgen wieder bereinigt.

Man kann sich die ganze Schreibarbeit der Routing Befehle auch in einem Skript automatisieren. Die Routing Befehle oben kann man ja fest skripten und lässt externe Server-IP, die interne Server VPN IP sowie die interne VPN IP des Vorgängers jeweils als Kommandozeilenparameter $2, $3, $4. Der erste Parameter $1 könnte zb die Anzahl der Verbindungen sein, so kann man im Skript über ne if/else Auswahl die jeweiligen Routing Befehle ausführen.

Zum Bspl für die erste Verbindung:
Code:
sudo skriptname 1 1.2.3.4 192.168.2.1 10.41.12.129

Die 1 leitet in der if/else Anweisung zu den ersten Routing Befehlen, wie oben unter 1, Verbindung gezeigt.

Beispiel zweite Verbindung:
Code:
sudo skriptname 2 5.6.7.8 10.41.12.129 10.14.21.129

Die 2 leitet zu den Routing Befehlen der zweiten Verbindung mit den nötigen IPs. Das ganze nur als Möglichkeit das zu automatisieren.

Falls Fragen sind, fragen :)

Gruß Jack
 
@JackCarver
Saubere Arbeit:)

Meine Fragen:

Wie verhält sich die Kaskade bei einem Reconnect?
Die IP's der VPN-Server ändern sich doch immer, oder?

Man kann sich die ganze Schreibarbeit der Routing Befehle auch in einem Skript automatisieren. Die Routing Befehle oben kann man ja fest skripten und lässt externe Server-IP, die interne Server VPN IP sowie die interne VPN IP des Vorgängers jeweils als Kommandozeilenparameter $2, $3, $4. Der erste Parameter $1 könnte zb die Anzahl der Verbindungen sein, so kann man im Skript über ne if/else Auswahl die jeweiligen Routing Befehle ausführen.

Da verstehe ich nur Bahnhof:(

Am Wochenende werde ich die Kaskade in die Tat umsetzen.
Da ich den PP-Manager für Linux nutze, muss ich mich erst mal schlau machen, wie das ohne den PP-Manager funktioniert.

@PP Frank
Achja, wie schön wäre es, wenn Perfect Privacy dieses Future auch für den Linux PP-Manager anbieten würde.
Ich verwende Linux, weil ich Microsoft nicht vertraue.
Linux Profi bin ich nicht.
 
Bei einem reconnect ist es natürlich in der jetzigen Form problematisch, weil sich wie du schon bemerkt hast, die IPs ändern können. Dabei wird man um ne Automatisierung nicht herum kommen, möchte man zb ein Skript immer mit den aktuellen IPs versorgen.
Mit etwas Aufwand könnte man ein Skript auch so bauen, dass es vom OpenVPN Befehl aufgerufen wird, es sich dann aus dem Log bzw ifconfig die nötigen IPs holt und das dann vom Routing her automatisch anpasst.
 
Mit etwas Aufwand könnte man ein Skript auch so bauen, dass es vom OpenVPN Befehl aufgerufen wird, es sich dann aus dem Log bzw ifconfig die nötigen IPs holt und das dann vom Routing her automatisch anpasst.

So ein Script wäre ein Traum :)
 
openvpn liefert die meisten Tunnel Daten als env-Variablen mit, sodaß man sie im script zur Verfügung hat. Ich hab bei mir einfach alle externen IPs des neuen Tunnels durch den alten Tunnel geroutet - dann passt es immer, egal welche externe verwendet wird. Das log benutze ich nur, um festzustellen, ob der Tunnel aufgebaut wird oder ob ein timeout kommt. Ein checkscript prüft alle 5 Minuten duch Zugriff auf google.com, ob der Tunnel noch steht und baut ihn ggf. automatisch wieder auf. Das ist mit bash alles so easy zu machen - wüßte nicht, wie man das unter Windows hinkriegen würde.
 
Man verbindet sich zu PP Prag und notiert sich die externe IP des Servers (kann aus dem Log entnommen werden)

Wie erkenne ich die externe IP des Servers?
Das Log ist sehr umfangreich.

@theoth
Vielleicht könntest du mit @JackCarver solch ein Script erstellen.
Damit so "Linux Dau's", wie ich, auch eine VPN-Kaskade nutzen können.:)
 
Du brauchst die externe IP des Servers nicht zu ermitteln, einfach alle externen IPs durch den Tunnel routen. Sieht bei mir so aus:
Code:
# route_via Rotterdam
#
# the following for pp-moscow:
#
echo "######################################"
echo "  PP-Moscow"

IP_routes=(192.162.100.213 192.162.101.15)
# alternative: IP_routes=$(dig +short moscow.perfect-privacy.com)
#Number_routes="${#IP_routes[@]}"

for route_ip in ${IP_routes[*]}
do
  /sbin/route add -host $route_ip gw $route_vpn_gateway
  echo "/sbin/route add -host $route_ip gw $route_vpn_gateway"
done

Korrektur:
das scriptlet wird aus dem jeweiligen .conf aufgerufen, über das man moscow routen will, also hier aus der Rotterdam.conf:

Code:
...
ping-restart 120
replay-window 512 60
mute-replay-warnings
route-delay 2
route-up /etc/openvpn/scripts/Rotterdam.sh <=============
log-append /var/log/openvpn-Rotterdam.log
user nobody
group nogroup

Ist bei mir noch etwas komplexer, weil ich auch noch IP-based routing habe, und mein gateway unterschiedliche Rechner über unterschliedliche pp-Tunnel routen kann.
Dazu schreibe ich nur noch in meine Config:
Code:
# route_via Kiev 192.168.0.60 eth0
und schon wird alles von und zu 192.168.0.60 über Kiev geroutet (Das 192.168.0 subnet ist bei mir über eth0 angebunden).
Ich hab leider so gut wie keine Zeit, um so ein script zu machen - habe gefühlte 1 Millionen Projekte, wo ich nicht hinterher komme...
Meine Lösung ist leider zu speziell, als daß sie einfach umzustricken wäre, sonst würde ich die scripte einfach zur Verfügung stellen.
Ist Stück für Stück gewachsen und inzwischen ein Monstrum mit Status-Seite auf einem internen Webserver, squid-Weiterleitung etc. geworden.
 
Last edited:
Die Idee von @theoth ist gut, ich werd mir das mal ansehen und wenn Zeit ist was stricken. Diese Anleitung war jetzt auch nur zum Prinzip der VPN Kaskade unter Linux gedacht, dass das jeder mal für sich testen kann, das ich auch recht schnell fertig hatte, das in ein Skript zu verpacken ist etwas testaufwändiger.
 
Back
Top