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