Ich hatte mal vor Ewigkeit einen Artikel über PPTP geschrieben. Vielleicht kannst du was mit anfangen.. Es muss nicht alles richtig sein, was dort steht.
Hier der Artikel:
Wieso macht man sowas?
Nach meinem Artikel "
Strom sparen, durch geschicktes scripten" habe ich mir überlegt, was ich als nächstes mit meinem Server testen kann. Da ich zwischendurch noch Probleme mit dem Dienst "Anacron" hatte, der verzögert Aufgaben ausführt, wollte ich erst ein Python-Script schreiben, welches wie der Crontab aufgebaut ist und eine bessere Logik verwendet. Das musste jetzt erstmal hinten anstehen, da ich mir noch ein VPN einrichten wollte. Da ich mittlerweile meinen Server mit WOL über das Internet aufwecken kann und vor ein paar Tagen von Außen nicht auf meinen MLDonkey kam, hatte ich die Idee einfach ein VPN einzurichten, worüber man sich mit jedem Windows-Client ohne zusätzliche Software einwählen kann.
Durch ein VPN wird der komplette Verkehr getunnelt. Nebeinbei hat es noch den Vorteil, dass alles verschlüsselt wird. So hat der VPN-Client direkten Zugriff auf das interne Netzwerk.
Den Aufbau hatte ich mir so vorgestellt
View attachment 503
Installation
Nachdem ich die Idee dazu hatte, ging es um die Umsetzung. Da ich wie immer für meine Server Debian einsetze, ist das Finden von Anleitungen und Paketen recht schnell erledigt. Die einfachste Möglichkeit ein VPN einzurichten, ist das verwenden von Point to Point Tunneling Server. Unter Debian heißt das Paket "pptpd". Das kleine d steht für Daemon wie bei fast jedem Serverdienst.
Die Installation des Pakets findet wie gewöhnlich über apt-get statt:
Konfiguration von pptpd
Nach der Installation muss der Dienst konfiguriert werden. Die beiden Konfigurationsdateien sind '/etc/pptpd.conf', '/etc/ppp/pptpd-options' und 'cat /etc/ppp/chap-secrets'.
pptpd.conf
Code:
#lädt die Datei /etc/ppp/pptpd-options für zusätzliche Optionen des Servers
option /etc/ppp/pptpd-options
#Logt Verbindungen über wtmp. D.h. man kann mit dem Befehl "w" sehen, wer zur Zeit über VPN, Terminals und SSH eingeloggt ist.
logwtmp
#Lokale IP des PPTPD-Servers (nicht verwechseln mit der IP der Netzwerkkarte!)
localip 10.0.0.1
#IP-Bereich, der den Clienten automatisch zugewiesen wird.
remoteip 10.0.0.10-200
pptpd-options
Code:
#Name des Dienstes, am besten so belassen
name pptpd
# Weist die Verfahren pap, chap und mschap ab. Diese sind unsicher und unverschlüsselt
refuse-pap
refuse-chap
refuse-mschap
# Es wird mschap-v2 mit einer 128-Bit-Verschlüsselung benötigt
require-mschap-v2
require-mppe-128
# leitet Anfragen vom VPN auf das lokale Netz weiter
proxyarp
# ersetzt nicht die Default-Route. Welchen Sinn diese Einstellung genau hat, kann ich nicht sagen.
# Clientseitig wird die Default-Route auf den VPN-Server gesetzt, damit der komplette Traffic getunnelt wird.
# Das lässt sich aber auch Clientseitig einstellen bzw. selbst konfigurieren.
nodefaultroute
# Lockfile für exklusiven Zugriff
lock
# deaktiviert die BSD-Kompression
nobsdcomp
chap-secrets
Code:
# Secrets for authentication using CHAP
# client server secret IP addresses
deadeye pptpd supersicherespasswort *
Zusätzlich kann man in der Datei festlegen, welche feste IP der Teilnehmer zugewiesen bekommt. Ich habe es so belassen, dass der Client eine freie IP aus dem zuvor festgelegten Bereich zugewiesen bekommt.
IP-Zuweisung
Es kann sinnvoll sein, das eigene Netzwerk in einen IP-Bereich zu legen, dass nicht in 192.168.0.0, 192.168.172.0 oder 192.168.1.0 liegt. Nutzt man z.B. intern das Netzwerk 10.0.0.0 und die VPN-Clients bekommen eine IP aus dem gleichen Netzwerk zugewiesen, kann man ohne Probleme auf die anderen Teilnehmer im LAN über VPN zugreifen. Derzeitig habe ich meine Konfiguration noch so, dass ich im internen Netzwerk 192.168.0.0. Weiter Versuche werde das dafür aber von einem externen Anschluss aus machen müssen.
Der erste Test im LAN
Da nun pptpd konfiguriert ist, kann man den Dienst einmal neustarten:
Code:
/etc/init.d/pptpd restart
Die Verbindung kann man einmal mit Windows testen. Dazu eine Neue Verbindung erstellen (VPN), die LAN-IP vom Server angeben und sich mit Buntzernamen und Kennwort einloggen. Unter Windows 7 muss nichts weiter eingestellt werden, da in der Standard-Einstellung alle möglichen Protokolle durchprobiert werden. Da der Server so konfiguriert ist, dass nur verschlüsselte Verbindungen akzeptiert werden, ist man auf der sicheren Seite. Sollte der Login klappen, wird man feststellen, dass die Internetverbindung weg ist. Das liegt daran, dass die Default-Route ersetzt wird. Unter Windows hat man dann zwei Routen, wovon aber nur die Route des VPN genutzt wird. Da beim Server nichts weiter eingestellt worden ist, leitet dieser den Traffic an IPs außerhalb des Netzes nicht weiter.
NAT einrichten
Damit das weiterleiten des Traffics ins Internet funktioniert, muss beim Server das Standardgateway eingetragen. In meinem Fall ist es der D-Link-Router, der bei mir zur Zeit noch auf 192.168.0.0.1 läuft. Da es unter anderem auch Probleme der Verbindung zu Internetseiten gibt, musste ich für die Lösung etwas länger googeln. Letztendlich habe ich aber einen Weg gefunden, auch das Routing ins Internet über das VPN in den Griff zu bekommen. Anfangs habe ich mir ein Script in /etc/ppp/ip-up.d/ und /etc/ppp/ip-down.d/ gelegt, welches unter anderem das Forwarding im Kernel aktivier und mit iptables NAT aktiviert. Sobald aber zwei User über VPN eingewählt sind und einer wieder die Verbindung trennt, wurde durch mein Script die Regel für NAT gelöscht und das Forwarding deaktiviert. Das hatte dann zur Folge, dass auch meine Verbindung zum Internet gekappt wurde. Ich habe mich für die einfachere Lösung entschieden. Bei Debian gibt es die Datei '/etc/rc.local' welche im Multiuserrunlevel als allerletztes ausgeführt wird.
/etc/rc.local
Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
iptables=/sbin/iptables
# NAT einrichten, in meinem Fall verwende ich eine Bridge. Deswegen auch -o br0
# Anstelle der Bridge solltet ihr euren NIC einsetzen (z.B. eth0).
$iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
# fix fuer MTU
# http://pptpclient.sourceforge.net/howto-diagnosis.phtml#connections_freeze
$iptables -A FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu
echo 1 > /proc/sys/net/ipv4/ip_forward
exit 0
Sollte man auf seinem Server keine Firewall eingerichtet haben, kann man das Script bis auf "br0" übernehmen.
Der 2. Test - diesmal mit Internet
Nachdem nun das Script gespeichert ist, sollte man dieses einmal ausführen. Nach einem Neustart des Servers braucht man das nicht mehr manuell auszuführen.
Nachdem nun die Regeln geladen worden sind und ip_forward aktiviert ist, kann man sich über das VPN nochmals erneut einwählen. Man sollte dann Seiten wie ebay.com, gmx.de und google.de ausprobieren. Die beiden ersten sind dafür bekannt, dass sie nicht gehen, wenn der MTU-Wert zu hoch eingestellt ist. Durch das Tunneling ensteht Overhead, welches die maximale Paketgröße weiter einschränkt.
VPN von Außen errechbar - VPN Pass-Through
Sollte alles funktionieren, kann man bei seinem Router VPN Passthrough aktivieren. Bei meinem DI-524 von D-Link gibt es die Option im Webinterface unter Tools -> Verschiedenes -> VPN Pass-Through -> PPTP (Aktiviert). Diese Einstellung speichern. Danach muss der Port TCP 1723 zum VPN-Server weitergeleitet werden. Dafür auf die Erweitert -> "Virtueller Server" klicken und dann Port 1723 bei "Privater Port" und "Öffentlicher Port" eintragen. Im Feld "Private IP-Adresse" wird die LAN-IP des VPN-Servers eingetragen. Name ist natürlich frei wählbar. Die Regel noch aktivieren und dann abspeichern.
Danach am besten jemanden bitten sich einmal mit der öffentlichen IP und den zuvor festgelegtem Benutzernamen und Kennwort einzuloggen. Aus dem eigenen LAN kann man die Funktion nicht ausprobieren.
PS:
http://creativecommons.org/licenses/by/4.0/
