VPN Debian Etch

VPN am Fachbereich unter Debian Etch ab Kernel 2.6.15

Kernel (für Kernel-Selbstbauer)

Kernel ≥ 2.6.15 enthalten die nötige MPPE-Encryption bereits, die muss unter Device Drivers / Network / PPP (point-to-point protocol) support / PPP MPPE compression (encryption) aktiviert sein.

Benötigte Software

Zunächst einmal werden folgende Debian-Pakete benötigt:

• ppp pptp-linux iproute bash sed

sofern sie nicht schon längst installiert sind.

Userspace

Es ist am einfachsten für das VPN des Fachbereich ein sogenanntes Callfile für den pppd unter /etc/ppp/peers/ anzulegen. Zum Beispiel /etc/ppp/peers/mi-vpn mit einem Editor der Wahl anzulegen und mit folgendem Inhalt füllen:

# benutze ppp11 für das VPN zum FB Mathematik/Informatik
unit 11
ipparam mi-vpn
# usernamen setzen (ACHTUNG, HIER DEN EIGENEN ACCOUNT-NAMEN EINSETZEN!)
user mi-username
password HierBitteDasImWebErhaltenePasswort
noauth
# pptp für verbindung verwenden
pty "pptp vpn.mi.fu-berlin.de --nolaunchpppd"
# mppe verschlüsselung
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
nomppe-stateful
nodeflate
nobsdcomp
# remote Seite muss sich nicht autentisieren
noauth
# mtu/mru für pptp über pppoe 
# ggf streichen oder auf eigene MTU anpassen
# 16byte für gre +20byte für ip +8byte für pppoe
# dazu noch etwas luft für extensions
# dass macht eine um 48 byte kleine mtr/mru 
mtu 1452
mru 1452
# bei einem reconnect 90sc warten
holdoff 90
# nach 40 Versuchen (1h) aufgeben
maxfail 40
# nicht alles über das vpn routen 
nodefaultroute

ACHTUNG:

• STATT "mi-username" DEN EIGENEN ACCOUNT-NAMEN
• STATT "HierBitteDasImWebErhaltenePasswort" das Passwort von MIPortal eintragen!

Der Tunnel kann nun einfach mit pppd persist call mi-vpn aufgebaut werden. Problem: Es werden so noch keine Daten darüber übertragen (geroutet). (Von der Benutzung der defaultroute pppd option ist abzuraten, da diese leider die bestehende defaultroute auch für den Tunnel durch den Tunnel leitet (und das kann nicht funktionieren…). )

Lösung: Stattdessen sollten die Routen in einem "ip-up Script" (liegen meist in /etc/ppp/ip-up.d/) entsprechend gesetzt werden (z.B. /etc/ppp/ip-up.d/mi-vpn):

#!/bin/bash
#/etc/ppp/if-up.d/mi-vpn
PPP_IFACE="$1"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
OLDDEFAULT=$(ip route list | grep default | sed 's/.*default[\ \t]*\([dv][ei][va]\)[\ \t]\([a-zA-Z0-9\.]*\).*/\1 \2/' | head -1)
PPTP_REMOTE=$(getent hosts vpn.mi.fu-berlin.de|awk '{print $1}')

if [ "mi-vpn" == "$PPP_IPPARAM" ] 
then
  ip route add $PPTP_REMOTE $OLDDEFAULT
  ip route change default via $PPP_REMOTE dev $PPP_IFACE
fi
#last line intentionally left blank

Um die Defaultroute nach dem Tunnelabbau wiederherzustellen empfielt sich folgenes:

#!/bin/bash
#/etc/ppp/if-down.d/mi-vpn
PPP_IFACE="$1"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
PPTP_REMOTE=$(getent hosts vpn.mi.fu-berlin.de|awk '{print $1}')
PREVDEFAULT=$(ip route list $PPTP_REMOTE | head -1 | sed 's/.*[\ \t]*\([dv][ei][va]\)[\ \t]\([a-zA-Z0-9\.]*\).*/\1 \2/')

if [ "mi-vpn" == "$PPP_IPPARAM" ]
then
    ip route replace default $PREVDEFAULT
fi

---

Kommentare

Äh - das zweite Skript ist ja sehr schön, oder offensichtlich ist es nicht dafür gedacht von Hand gestartet zu werden (warum sollte man auch drei unbenutzte dummy-Argumente übergeben). Also was muß ich tun, damit dieses Skript ausgeführt wird. Oder: wenn ich es von Hand starte, was benutzt man als Argument für PPP_REMOTE?

-- cscharfe@PCPOOL/MI/FU-BERLIN.DE - 12 Oct 2007

Ok, also etwas klärung zum 2. Script:

Dieses wird vom pppd aurgerufen, sobald die ip-verbindung oben ist. Dabei speichert es sich die alte Defaultroute, also die, die nicht durch den Tunnel geht, in OLDDEFAULT , in PPTP_REMOTE speichert er die IP von VPN-Server (nicht durch den Tunnel), und in PPP_REMOTE die VPN-Gegenseite (durch den Tunnel).

Anschließend setzt es eine Host-Route zum VPN-Server über die alte Default-Route (merke Tunnel durch Tunnel zu routen geht schief - genau wie Induktion ohne Induktionsanker), setzt eine neue Defaultroute über durch den Tunnel (also für alles, für das keine speziellere Route existiert).

Die Kommentare von sulfrian@PCPOOL/MI/FU-BERLIN.DE - 15 Oct 2007 und winkelma@PCPOOL/MI/FU-BERLIN.DE - 15 Oct 2007 habe ich gelöscht (da partiell inkorrekt)

-- PhilippSchmidt - 16 Oct 2007

Da ich Ersti bin habe ich etwas Scheu hier gleich etwas im Wiki zu veraendern, deshalb frage ich lieber vorher. Das ip-up script funktionierte bei mir leider nicht, beide Regexps haben sowohl bei Sarge(pool) als auch bei Ubuntu 7.04 falsche Sachen zurueck gegeben. Hier meine Veraenderungen:

OLDDEFAULT=$(ip route list | grep default | sed 's/.*default[\ \t]*[dv][ei][va][\ \t]\([a-zA-Z0-9\.]*\).*/\1/')

(die Klammer wurde nur an eine andere Stelle gepackt)

PPTP_REMOTE=$(host -t A vpn.mi.fu-berlin.de | tail -1 | sed 's/^.*[\ \t]\([0-9\.]*\)$/\1/')

Bitte überprüft das und belehrt mich ggf eines Besseren. Ich habe vorhin zum ersten mal intensiver auf Regular Expressions geschaut

-- mikrause@PCPOOL/MI/FU-BERLIN.DE - 18 Oct 2007

Danke Michael für den Tipp, in der Tat weichen Ubuntu und Debian da deutlich voneinander ab. Mit der neuen Version (siehe oben) sollte es jetzt distributionsübergreifend klappen. Bitte testen!

-- GeroEggers - 18 Oct 2007

klappt bei ubuntu 6.06, 7.10 und sarge. dankeschön

-- mikrause@PCPOOL/MI/FU-BERLIN.DE - 20 Oct 2007

Naja fast! Bei mir unter Opensuse 10.3 hat soweit alles funktioniert nur nach dem Beenden der VPN-Verbindung hatte ich keine defaultroute mehr. Ich habe das folgendermaßen gelößt:

#/etc/ppp/if-up.d/mi-vpn #!/bin/bash PPP_IFACE="$1" PPP_REMOTE="$5" PPP_IPPARAM="$6" PPTP_REMOTE=$(getent hosts vpn.mi.fu-berlin.de|awk '{print $1}')

if [ "mi-vpn" == "$PPP_IPPARAM" ] then ip route list | grep default > /etc/ppp/altdefault ip route add $PPTP_REMOTE via $OLDDEFAULT ip route change default via $PPP_REMOTE dev $PPP_IFACE fi

#/etc/ppp/if-down.d/mi-vpn #!/bin/bash PPP_IFACE="$1" PPP_REMOTE="$5" PPP_IPPARAM="$6" OLDDEFAULT=$(ip route list | grep default | sed 's/.*default[\ \t]*[dv][ei][va][\ \t]\([a-zA-Z0-9\.]*\).*/\1/') PPTP_REMOTE=$(getent hosts vpn.mi.fu-berlin.de|awk '{print $1}')

if [ "mi-vpn" == "$PPP_IPPARAM" ] then ip route add `cat /etc/ppp/altdefault` fi

so klappts auch mit der defaultroute ohne vpn

-- halfbrod@PCPOOL/MI/FU-BERLIN.DE - 13 Nov 2007

#/etc/ppp/if-down.d/mi-vpn
#!/bin/bash
PPP_IFACE="$1"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
OLDDEFAULT=$(ip route list | grep default | sed 's/.*default[\ \t]*[dv][ei][va][\ \t]\([a-zA-Z0-9\.]*\).*/\1/')
PPTP_REMOTE=$(getent hosts vpn.mi.fu-berlin.de|awk '{print $1}') 

if [ "mi-vpn" == "$PPP_IPPARAM" ]
then
  ip route add `cat /etc/ppp/altdefault`
fi

Ich hoffe jetzt klappts auch mit dem Zeilenumbruch.

-- halfbrod@PCPOOL/MI/FU-BERLIN.DE - 13 Nov 2007

Zeienumbuch durch Einfuegen von darueber '<verbatim>' und darunter ' </verbatim>' repariert

-- stucki@mi.fu-berlin.de 10 Jan 2008

Das Kernel Modul ppp_mppe wird benötigt, sonst schlägt die Anmeldung fehl. Das Modul kann man mit

modprobe ppp_mppe

laden.

Ausserdem kann man unter Debian das starten und stoppen deutlich vereinfachen.

a) es gibt die Programme pon und poff pon mi-vpn (starten) poff mi-vpn (stoppen)

b) man kann unter /etc/network/interfaces folgenden Eintrag hinzu fügen: iface mi-vpn inet ppp provider mi-vpn pre-up modprobe ppp_mppe

jetzt kann man mi-vpn wie jedes andere Netzwerk Device mit

ifup mi-vpn ifdown mi-vpn

starten und stoppen. Ausserdem wird automatisch das Kernel Modul geladen

-- engwer@PCPOOL/MI/FU-BERLIN.DE - 17 Mar 2008

Tipp von Ch. Mehlis:

wenn man hier in der config in der Zeile: pty "pptp vpn.mi.fu-berlin.de --nolaunchpppd" ans ende noch --nobuffer und -loglevel 0 anhängt, ist das Problem nicht mehr sichtbar (gelöst). (http://linux.die.net/man/8/pptp) Dies hat bei mir die Performance um 40% erhöht (kein Aufwand mehr fürs Loggen…)

-- IngmarCamphausen - 15 Dec 2009

problem bei mir war: Dec 8 22:52:33 blue kern.notice pptp[1085]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 17071 (expecting 17056, lost or reordered) Dec 8 22:52:33 blue kern.notice pptp[1085]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 17072 (expecting 17056, lost or reordered) Dec 8 22:52:33 blue kern.notice pptp[1085]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 17073 (expecting 17056, lost or reordered) Dec 8 22:52:33 blue kern.notice pptp[1085]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 17074 (expecting 17056, lost or reordered) Dec 8 22:52:33 blue kern.notice pptp[1085]: anon log[decaps_gre:pptp_gre.c:404]: buffering packet 17075 (expecting 17056, lost or reordered)

es könnte auch helfen, wenn ihr die mtu auf 1400 setzt

chris

-- Main.mehlis - 15 Dec 2009