FritzBox Labor. Linux VPN Client

[pfeffer]

Du scheinst Dich mit Linux ja nun ziemlich schlecht auszukennen. Wenn man nicht weiß, wie die Befehle heißen, kann man mit
man -k stichwort
nach allen Befehlen suchen, bei denen in der Beschreibung in den manpages das Stichwort enthalten ist.
Zum Herausfinden der IP verwendet man normalerweise nslookup oder dig. Aus der Ausgabe kannst Du dann mittels Pipe (="|") und grep Dir die IP extrahieren.
Lies mal die manpages zu den Befehlen.

Gruß,
Pfeffer.

 

[starbright]

Ich dachte immer die ersten Stufen schon übersprungen zu haben, aber offensichtlich nicht
So dafür und alle anderen dummys meine Zusammenfassung:

#!/bin/sh
echo VERBINDUNG aufbauen
sudo route add -net <dyndns_der_fritzbox> netmask 255.255.255.255 gw 192.168.178.1
sudo route del default
/usr/bin/ikea

echo VERBINDUNG rückbauen
sudo route del -host <dyndns_der_fritzbox>
sudo route add default gw 192.168.178.1 wlan0

Ist noch verbesserbar - das gw müßte ausgelesen und gespeichert werden, damit man das script in jedem Fremdnetz nutzen kann

ip=$(dig local-server | grep SERVER | cut -c12-24)
ist zwar ein Abfang aber weit entfernt von allgemein.
Jemand noch nen besseren Trick? Bin überrascht, dass es mit ifconfig nicht angezeigt wird.

 

[pfeffer]

1.
probiere mal, ob Du die default route wirklich löschen musst. Schließlich wird die ja von Shrew automatisch neu gesetzt - vermutlich fügt Shrew auch einfach eine weitere default route mit einier niedrigeren Metric hinzu. Dann braucht man sich das alte Standard-Gateway nicht zu merken. In Windows XP klappt das.

2.
kann man bei route add den dyndns-namen als Namen eingeben? - das wäre ja praktisch, aber ich vermute, es geht nicht.

3.
aus einer Zeile bestimmte Teile extrahieren macht man vermutlich am besten mit einem Regulären Ausdruck ( http://de.wikipedia.org/wiki/Regulärer_Ausdruck ). Sie sind in Linux allgegenwärtig und werden auf englisch Regular Expression, kurz RegEx genannt. Aber vielleicht guckst Du erst nochmal, ob man nicht dig oder nslookup mittels Optionen dazu bekommt, nichts als die gesuchte IP auszugeben. Für die Auswertung von RegExen kann man awk oder sed verwenden. Ich habe ein Bsp. dazu schnell für Dich ergooglet fileversion=$(echo $filename | sed s/^.*\([0-9]{4}\).*$/\1/g) siehe http://www.linuxquestions.org/questions/linux-general-1/bash-regex-file-name-parsing-547407/

Gruß,
Pfeffer.

 

[pfeffer]

den gleichen Beitrag 2mal schreiben ist noch so gern gesehen. (auch nicht, wenn man 1 Zeile hinzugefügt hat)

Gruß,
Pfeffer.

 

[starbright]

Sorry, ausversehen passiert:
ohne das löschen der default route sieht es so aus:

0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 tap0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 wlan0

ist da nicht wieder das Problem, das nicht alles durch den Tunnel geht?

Den dyndns Namen kann man direkt angeben Das script ist schon erprobt!

Ich probiere weiter. Danke für Hilfe!

star@ubu:~$ nslookup server
Server:		192.168.178.1
Address:	192.168.178.1#53

** server can't find server: NXDOMAIN

... sieht schon sauberer aus.

 

[pfeffer]

Es läuft dadurch nicht alles durch den Tunnel. Oder funktioniert es so nicht?
Du musst aber weiterhin die Host-Route setzen. Brauchst aber die default route nicht zu löschen.
In Deiner Ausgabe ist die host route zum VPN-Server nicht enthalten. Das musst Du schon machen.

wenn route add wirklich einen DNS-Namen akzeptiert, dann verstehe ich nicht, wozu Du noch irgendwas mit nslookup machen willst.

Gruß,
Pfeffer.

 

[starbright]

Ob es alles so läuft wie gedacht (alles durch den Tunnel) ist noch nicht wirklich geprüft, da ich nicht weiß wie. Ich hab mich bisher beholfen, in dem ich nen Download aus dem Netz gemacht hab, isser langsam, gehts zumindest erst mal über die Fritzbox daheim. (obs aber auch durch den Tunnel geht ist damit nicht gewiss, oder?)

Die Host route zum Server setzt meines Erachtens Shrew, denn während der Tunnel aufgebaut ist, sieht es so aus. Ich hoffe ich hab es verstanden und die Zeile die du meinst ist die unterste. Sonst ist bei mir wohl Hopfen und Malz verloren

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
88.66.x.x     192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 tap0

Wozu ich noch den nslookup brauche?
In meinem Script muß ich neben der IP meiner Fritzbox daheim auch das Gateway, von dem Netz in dem ich mich grad befinde, eintragen und dann hinterher (nachdem der Tunnel abgebaut ist) wieder gesetzt werden.
Sonst kann ich hinterher nicht mehr normal weitersurfen.
Am extrahieren der magischen Ziffern der IP aus der nslookup arbeite ich noch.

Ich hoffe ich stelle mich nicht zu dämlich an, aber einfach ist das Thema wirklich nicht (für mich).

 

[pfeffer]

die Host Route zum VPN Server ist die erste Zeile in Deiner Routing tabelle, die mit der netmaske 255.255.255.255. Die Maske 255.255.255.255 bedeutet, dass nicht in ein ganzen Netz (mit 1.2.3.x) groutet wird, sondern nur an einen Host, deswegen der Name "Host-Route". Sie ist etwas anderes als die Default-Route, die die Netzmaske 0.0.0.0 hat.
Wird die Host-Route von Shrew automatisch gesetzt? in Windows jedenfalls nicht. Irgendwie musst Du lernen, genauer zu lesen und dann Begriffe, die Du nicht verstehst nachschlagen (google) oder nachfragen. Das ist nicht leicht, aber wenn man sich darauf konzentriert, nicht unbedingt im ersten Anlauf alles zu verstehen, sondern herauszubekommen, warum man es nicht versteht, dann lernt man danach erheblich viel schneller.

Wie Du überprüfen kannst, ob der Verkehr durch den Tunnel läuft? - Indem Du www.wieistmeineip.de aufrufst. Wenn dort die IP von Deiner FritzBox, die Du als VPN-Server verwendest, angezeigt wird, dann läuft der Verkehr durch den Tunnel.

EDIT:
Wenn Du die IP von Deinem Default gateway herausbekommen möchtest, dann musst Du das aus der routing tabelle auslesen. Oder woher kennst Du den DNS-Namen Deines Default gateways? Evtl. geht es auch über traceroute.

Gruß,
Pfeffer.

 

[starbright]

Klar, hast recht. Danke für die Geduld.
Die Host route zum VPN muß ich natürlich manuell setzen. Steht ja auch hier
http://www.ip-phone-forum.de/showpost.php?p=1438611&postcount=136
und in dem Script in
http://www.ip-phone-forum.de/showpost.php?p=1438611&postcount=142

Und tatsächlich brauche ich nur einen Befehle nach dem Abbau des VPNs, nämlich die manuell gesetzte Route wieder zu löschen.
Da hat mich der PC verar***, weil die Ausgabe von "route -n" einfach zu früh kam. Wartet man kurz, sieht die Tabelle wieder aus wie am Anfang - ganz ohne weiteres.

Tatsählich seh ich mit www.wieistmeineip.de die IP meiner entfernten Fritzbox.
Die Übertragungsraten im angebotenen Test sind natürlich mau,:
Down 66kByte/s, Up 15KB/s

Wenn ich Shrew schließe, dann seh ich auch wieder eine andere IP.
Auch die Übertragungsraten gehen hoch auf
Down 243kByte/s, Up 18KB/s


Nur um sicherzugehen:
Kann es denn sein, dass zwar der der Verkehr zwar vom lokalen Netz zu meiner FB daheim (VPN Server) geht und von da weiter, aber eben nicht gesichert. Ich hoffe ich verwende das richtig, aber sozusagen als transparenter Proxy? Dann würde doch wohl auch die IP meiner FB daheim angezeigt werden, oder?

 

[pfeffer]

Nur um sicherzugehen:
Kann es denn sein, dass zwar der der Verkehr zwar vom lokalen Netz zu meiner FB daheim (VPN Server) geht und von da weiter, aber eben nicht gesichert. Ich hoffe ich verwende das richtig, aber sozusagen als transparenter Proxy? Dann würde doch wohl auch die IP meiner FB daheim angezeigt werden, oder?

Gesichert ist nur die Verbindung von Dir zu Deiner Fritzbox. Die Fritzbox entschlüsselt Deine Pakete und sendet sie unverschlüsselt weiter.

Nun gibt es theoretisch einen Modus von IPSec, bei dem nicht verschlüsselt wird, sondern nur sichergestellt wird, dass der Absender des IP-Paketes derjenige ist, für den der Empfänger des IPSec-Paketes ihn hält.

Dieses Protokoll heißt Authentication Header, abgekürtzt AH. Das Protokoll zur Verschlüsselung heißt Encapsulating Security Payload (ESP).

Wenn ich die Auswahl in Shrew für Phase 2 richtig deute, dann kann Shrew nicht unverschlüsselt eine Verbindung nur mit AH herstellen.

Gruß,
Pfeffer.

 

[starbright]

Alles klar, danke. Ich hoffe ich finde noch die Zeit und fasse das alles noch mal zusammen in einem kleinen Howto.

 

[da-chiller]

Hallo Ihr alle,

nachdem ich den Thread jetzt gefühlte 100 mal gelesen habe, komme ich zu dem Schluss dass ich auch einen "tap0"-Adapter in meiner ifconfig stehen haben sollte. Ich denke mal dass das ein virtueller Netzwerkadapter ist, mit dem ich mich in die FB verbinden muss.

Leider habe ich diesen Adapter nicht und google kann mir anscheinend auch nicht weiterhelfen. Installiert habe ich einmal über das repository, einmal habe sogar eine beta kompiliert. Ich kann alles machen. Aber der Adapter taucht nicht auf. Daher habe ich -wahrscheinlich- folgende Meldung:

config loaded for site 'knoxxxlankn.selfhost.me'
attached to key daemon ...
peer configured
iskamp proposal configured
esp proposal configured
ipcomp proposal configured
client configured
local id configured
remote id configured
pre-shared key configured
bringing up tunnel ...
negotiation timout occurred
tunnel disabled
detached from key daemon ...

In der iked.log steht folgendes:

10/01/29 17:42:33 ## : IKE Daemon, ver 2.2.0
10/01/29 17:42:33 ## : Copyright 2008 Shrew Soft Inc.
10/01/29 17:42:33 ## : This product linked OpenSSL 0.9.8g 19 Oct 2007
10/01/29 17:42:33 K! : failed to read policy address info
10/01/29 17:42:33 K! : failed to read policy address info
10/01/29 17:42:33 K! : failed to read policy address info
10/01/29 17:42:33 K! : failed to read policy address info

Von einem Windows-Client mit Shrew klappts einwandfrei. Muss also an meinem Linux liegen.

Danke schonmal an alle Antworter

 

[pfeffer]

was sagt "ifconfig -a"?
selbst kompilieren wird Dir nicht helfen, falls das fehlende TAP-Device tatsächlich das Problem ist. Helfen wird da eher, über die Paketverwaltung zu installieren, die die notwendigen Konfigs erledigt.

Evtl. musst Du das tap-device mit "mknode" anlegen.

Außerdem denke ich, dass sowohl Tap-devie erzeugen als auch Tunnel aufbauen nur als root geht.

Gruß,
Pfeffer.

 

[da-chiller]

Soo,

jetzt bin ich wenigstens so weit, dass er das tap-device während dem Versuch die Verbindung auf zu bauen mit

ifconfig -a

anzeigt. Was allerdings keine Verbesserung der Situation herbeigeführt hat.

Habe jetzt die neueste Beta durch die 2.1.4 aus der Paketverwaltung ersetzt, jedoch steht im /var/log/iked.log immer noch das selbe. (Siehe Beitrag vom 29.01.2010). Nur eben mit einem aktuelleren Zeitstempel. Müsste von der Installation gewesen sein.
Gibt es noch ein anderes Logfile?
Bzw. hat sonst noch jmd Ideen?

thx

 

[pfeffer]

es könnte ja sein, dass die Fehlermeldung stimmt -> was hast Du denn in der Policy eingetragen?

Gruß,
Pfeffer.

PS: bitte verrate uns, wie Du nun das TAP-Device angelegt hast, damit auch andere von Deinen Erfahrungen profitieren können.

 

[da-chiller]

In der Policy habe ich beide Häkchen rausgemacht und das Zielnetz eingetragen:

192.168.193.0 / 255.255.255.0

Das tap-device wurde erstmals nach der installation des Clients über die Paketverwaltung während dem Verbindungsaufbau dann angezeigt.
Weiterhin habe ich nichts machen müssen.
Sollte es auch ohne Aufbau, also nach einem Neustart schon drinstehen?

 

[pfeffer]

das ist richtig.

welche IP hat Dein Rechner? Versuchst Du vielleicht innerhalb Deines lokalen Netzes noch die VPN-Verbindung aufzubauen? - Das klappt nicht. Es geht nur von außerhalb und wenn die IP-Adressen in dem lokalen Netz von außerhalb andere sind als die IP-Adressen, die die FritzBox intern vergibt (genauer in einem anderen Subnetz sind).

Ich habe das gerade mal probiert: Ich bekommen genau die Ausgaben wie Du, wenn ich es innerhalb des lokalen Netzes versuche. Iked.log habe ich jetzt allerdings noch nicht verglichen.

Gruß,
Pfeffer.

 

[da-chiller]

Tja das mit dem Subnetz ist leider nicht das Problem.
Ich studiere an einer FH und um von dort aus ins INet zu gelangen muss man ebenfalls eine VPN im internen Netzwerk aktivieren. Auch hier funktioniert die Verbindung über Windows problemlos. Da der FH-Server quasi dafür offfen ist.

Ich probier das am Wochenende mal von einem anderen DSL-Anschluss aus. Vielleicht klappts ja da!?

Witzigerweise kann ich wenn ich zu Hause die FH-VPN aktiviere (und mich somit in einem anderen Netzwerk befinde) mit dem AVM-Client, auf meine FritzBox einwählen.

 

[da-chiller]

Sooo...
also hab es jetzt auch an einem normalen privaten DSL-Anschluss probiert. Allerdings gibt es keine Veränderung.
Ich glaub ich hab da ein generelles Problem mit dem virtuellen Netzwerkadapter. Könnte evtl jmd mal seine iked.log hier posten, damit ich einen Vergleich zu meiner habe.

Zu finden unter: /var/log/iked.log

thx

 

[pfeffer]

Du versuchst es unter Linux? - Da hatte ich mal festgestellt, dass ein einmaliger Fehler beim Verbindungsaufbau dazu führen kann, dass auch bei korrekter Konfiguration nur nach einem Reboot der Tunnelaufbau wieder funktioniert. Aber das hast Du bestimmt schon getestet...

Gruß,
Pfeffer.