rss feed articles activities all_comments

indeedgeek.de

Florian Eitel

VPN Schmerzlos

Jedes mal wenn man es verwenden muss ärgert man sich erneut: Immer dann wen man es am wenigsten brauchen kann bricht die VPN Verbindung zusammen und der laufende Download, die SSH Verbindung oder was auch immer grade wichtig war, bricht zusammen. Oder anders herum: Man scheut das Einwählen da man ein Wechseln der IP Adresse grade nicht gebrauchen kann. Viele Applikationen reagieren darauf sehr ärgerlich.

Heute hat es mich einmal zu viel aufgeregt und ich habe beschlossen etwas dagegen zu tun!

Wo ist das Problem?

Schaut man sich ohne VPN seine Routing Table an schaut alles wunderbar aus. Netzinterner Verkehr (192.168.188.0/24) wird direkt ohne Router über das wlan0 Interface gerouted. 127.0.0.0/8 geht über das loopback Device und alles andere wird über wlan0 an den Router bei 192.168.188.1 geschickt.


# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.188.0   0.0.0.0         255.255.255.0   U     2000   0        0 wlan0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.188.1   0.0.0.0         UG    2000   0        0 wlan0

Wählt man sich nun ins VPN ein bekommt man folgendes Bild zu sehen:


# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
193.197.62.114  192.168.188.1   255.255.255.255 UGH   0      0        0 wlan0
141.7.73.73     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.188.0   0.0.0.0         255.255.255.0   U     2000   0        0 wlan0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         192.168.188.1   0.0.0.0         UG    2000   0        0 wlan0

Was ist nun passiert? Zum einen wurde ein neues Device hinzugefügt (tun0). Alles zu der IP Adresse 192.197.62.144 geht über wlan0. Ich nehme mal an dies ist der Eintrittspunkt ins Netz. 141.7.73.73 geht über das tun0 Device. Dies ist der VPN Server auf dem man sich anmeldet. Nun kommen die bereits gekannten Regeln mit einer Ausnahme: Vor der default Route über meinen Router kommt eine andere Route die alles über das tun0 Device leitet. Das heißt so viel wie alles was nicht an 193.197.62.114, 192.168.188.0/24 oder 127.0.0.0/8 geht wird auf tun0 geleitet und geht somit nicht mehr über meinen Router raus. Möchte ich nun eine Webseite wie indeedgeek.de anschauen muss ich erst über VPN ins Hochschulnetzt gehen und dann von dort wieder raus zu indeedgeek.de. Als Beweis ein Traceroute (wer sich wundert: Das Tool heißt tcptraceroute und geht einfach auf Port 80 da ein normaler traceroute geblockt wird).


# tcptraceroute indeedgeek.de
Selected device tun0, address 141.7.73.73, port 34815 for outgoing packets
Tracing the path to indeedgeek.de (92.51.129.99) on TCP port 80 (http), 30 hops max
1  141.7.75.254  57.261 ms  56.569 ms  56.535 ms
2  FH-Heilbronn1.belwue.de (129.143.124.33)  57.533 ms  56.640 ms  56.714 ms
3  Ulm1.belwue.de (129.143.1.70)  63.486 ms  62.116 ms  61.594 ms
4  Stuttgart1.belwue.de (129.143.1.161)  64.684 ms  73.933 ms  62.531 ms
5  Stuttgart2.belwue.de (129.143.1.25)  62.430 ms  63.443 ms  64.647 ms
6  Frankfurt1.belwue.de (129.143.1.130)  68.713 ms  68.232 ms  70.087 ms
7  xe-0-3-0.cr-merak.fra2.hosteurope.de (80.81.193.239)  78.019 ms  74.123 ms  71.746 ms
8  * xe-0-1-0.cr-altair.cgn2.hosteurope.de (80.237.129.86) 74.100 ms  74.901 ms
9  xe-0-3-0.cr-pollux.cgn3.hosteurope.de (80.237.129.65)  74.367 ms  72.913 ms  75.388 ms
10  xe-16-1.cs-master.r1.cgn3.hosteurope.de (80.237.129.118)  80.181 ms  81.041 ms  74.501 ms
11  * * *
12  indeedgeek.de (92.51.129.99) [open]  81.123 ms  80.154 ms  82.230 ms
Das heißt ich habe von außen nicht mehr die IP Adresse meines DSL-Anschlusses sondern die IP Adresse des Hochschulnetzes. Dieser Wechsel der IP wird von den meisten Programmen sehr übel genommen. Vor allem da er zwei mal auftritt: Einmal beim Einwählen und dann wieder beim Trennen der Verbindung.

Die Lösung

Wenn man sich innerhalb des Hochschulnetzes befindet (z.B. Wlan) dann hat man keine andere Wahl: Wenn Internet dann nur über VPN. Da ist das Einwählen nicht so tragisch da zuvor ja noch keine Internetverbindung bestanden hat. Möchte man aber von Außen auf Dienste innerhalb der Hochschule zugreifen kommt mein Kritikpunkt ins Spiel. Dann hat bereits eine Verbindung bestanden die nun im Grunde getrennt wird und von einer anderen IP erneut aufgebaut werden muss.

Und genau dagegen möchte ich etwas tun. Die Lösung ist einfach. Wir lenken einfach nur den Verkehr über tun0 der auch darüber fließen muss. Der Rest nutzt einfach weiter wie vorher meinen Router. Erreichen kann man dies über zwei kleine Befehle:


route del default dev tun0
route add -net 141.7.0.0 netmask 255.255.0.0 dev tun0

Der erste Befehl löscht die default Route über tun0 und der zweite fügt eine neue Route ein. Diese soll jeden Verkehr an 141.7.0.0/16 über tun0 routen. Schauen wir uns nun die Routingtable an sieht man schön die Änderungen.


route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
193.197.62.114  192.168.188.1   255.255.255.255 UGH   0      0        0 wlan0
141.7.73.73     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.188.0   0.0.0.0         255.255.255.0   U     2000   0        0 wlan0
141.7.0.0       0.0.0.0         255.255.0.0     U     0      0        0 tun0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.188.1   0.0.0.0         UG    2000   0        0 wlan0

Zur Vollständigkeit noch der funktionierende traceroute:


tcptraceroute indeedgeek.de
Selected device wlan0, address 192.168.188.22, port 35522 for outgoing packets
Tracing the path to indeedgeek.de (92.51.129.99) on TCP port 80 (http), 30 hops max
1  192.168.188.1  1.855 ms  6.856 ms  1.530 ms
2  lo1.br63.dus.de.hansenet.net (213.191.64.107)  39.948 ms  47.024 ms  39.611 ms
3  ae0-101.cr02.dus.de.hansenet.net (62.109.110.62)  39.143 ms  38.726 ms  38.570 ms
4  so-0-1-0-0.cr02.fra.de.hansenet.net (213.191.66.34)  42.411 ms  51.295 ms  44.529 ms
5  ae1-0.pr03.decix.de.hansenet.net (62.109.109.236)  48.808 ms * 42.657 ms
6  xe-0-3-0.cr-polaris.fra1.hosteurope.de (80.81.192.239)  43.630 ms  43.009 ms  43.116 ms
7  xe-0-2-0.cr-nashira.cgn4.hosteurope.de (80.237.129.109)  45.807 ms  47.210 ms  72.683 ms
8  xe-2-1-0.cr-pollux.cgn3.hosteurope.de (80.237.129.10)  45.310 ms  45.984 ms  45.996 ms
9  xe-16-1.cs-master.r1.cgn3.hosteurope.de (80.237.129.118)  48.070 ms  46.861 ms  51.865 ms
10  * * *
11  indeedgeek.de (92.51.129.99) [open]  45.604 ms  46.741 ms  47.159 ms

Wie erreicht man nun dies am einfachsten? Zwei Möglichkeiten: Entweder man hindert vpnc daran die default Route zu ändern oder man gibt nach dem Verbindungsaufbau die beiden Befehle ein. Die erste Möglichkeit ist zwar die Elegantere da gar kein Abbruch statt findet. Allerdings war es mir zu nervig in der 530 Zeilen langen Bash Datei (/etc/vpnc/vpnc-script) herumzufummeln. (Zeile 467 ist der Verbrecher). Man müsste ein Schalter einbauen der die default Route im Hochschulnetz setzt und außerhalb eben nicht. Wer sich versuchen möchte nur zu, ich würde mich freuen!

Deshalb die zweite Lösung: Die beiden Zeilen einfach nach Verbindungsaufbau eingeben. Die Programme verkraften meistens eine kurze Trennung und so sollte diese Methode ausreichen.

vpnc in gentoo

Um die Pause möglichst kurz zu halten habe ich die Ausführung automatisiert. Ich glaube so funktioniert es nur in Gentoo aber andere Distributionen werden sich wohl ähnlich verhalten.

Ich habe zwei vpnc Profile angelegt einmal fhhn und einmal fhhn-int (intern). Unter gentoo reicht es einfach die Startscripte und Konfigdateien zu verlinken:


cd /etc/init.d/
ln -s vpnc vpnc.fhhn-int
ln -s vpnc vpnc.fhhn
cd /etc/vpnc/
ln -s default.conf fhhn.conf
ln -s default.conf fhhn-int.conf

Anschließend kann man über /etc/init.d/vpnc.fhhn und /etc/init.d/vpnc.fhhn-int vpnc starten. Es wird automatisch die korrekte Konfigdatei genutz (wobei beide sowieso identisch sind). Nun hat man zwei identische Verbindungen und jetzt kommt das Beste: Wir legen einfach die Datei /etc/vpnc/scripts.d/fhhn-postup.sh an. Diese wird nur bei fhhn aufgerufen (sonst müsste sie fhhn-int-postup.sh heißen). Dort scheiben wir nun unsere beiden route Befehle rein und machen sie ausführbar.

Nun kann ich einfach entscheiden ob ich die Routen umgeschrieben haben möchte (fhhn-int) oder eben nicht (fhhn). Leider bleibt immer noch das Problem, dass die Verbindung ab und zu abbricht. Daran kann ich leider nichts tun aber zumindest sind so nicht mehr alle Dienste davon betroffen.

Vielleicht konnte euch etwas helfen und auch Klaus kann nun Baseline testen ;-).

Disclaimer: Ich hoffe mal ich habe keine geheimen IP Adressen verraten. Ich denke an die Infos kommt jeder mit etwas motivation ran.

Comments:

(howto comment?)

Sehr geniale Sachen! Vielen Dank fürs Teilen und Berichten!