= VPN mit PPTP =

PPTP ist ein Protokoll für ein VirtualPrivateNetwork, das unter
anderem schon lange von Microsoft benutzt wird. Daher ist es
relativ einfach, VPN-Verbindungen z.B. zu älteren Win98-Rechnern
aufzunehmen.

== Was brauchen wir? ==
Es gibt verschiedene Protokolle, um VPNs zu realisieren. Davon
habe ich PPTP ausgewählt. Dieses Protokoll soll nicht das
allersicherste sein, dürfte aber für den normalen Gebrauch genügen.
Es hat dabei den Vorteil, dass ein PPTP-Client serienmäßig bei
Windows dabei ist, so dass auch ein plattformübergreifendes VPN-Netz
denkbar ist.

Unter Debian gibt es zwei Pakete zu dem Thema:

* '''pptp-linux''' - Dieses Paket enthält ein Client-Programm, das
die ppp-Verbindung über den Tunnel aufbaut.
* '''pptpd''' - Dies ist ein Daemon, der als Server auf eingehende
Verbindungen wartet.

== Vorab-Überlegungen ==

Vorab sollte man sich überlegen, wie das gesamte entstehende Netz
nachher aussehen soll. Im Prinzip ist der VPN-Server ein Router,
der Verbindungen zu Sub-Netzen herstellt. Dabei ist es durchaus
möglich, mehrere verschiedene Clients gleichzeitig zu haben. Im
Grunde genommen ist das vergleichbar mit einem Dialin-Server, der
ganz viele Eingangsleitungen mit Modems hat.

Da alle Clients normalerweise sicherheitstechnisch der gleichen
Klasse zuzuordnen sind, sollte man sie in ein eigenes Subnetz
packen. Dieses kann man dann z.B. in einer Firewall oder bei
anderen Zugriffsbeschränkungen benutzen.

Wenn sich ein Client per ppp anmeldet, bekommt er normalerweise
eine Nummer aus einem Nummernpool zugewiesen. Man kann jedoch über
die Authentifizierung in der Datei ''/etc/ppp/chap-secets'' auch
dafür sorgen, dass ein bestimmter Benutzer immer die gleiche Nummer
bekommt. Dies ist aus Sicherheitsgründen immer zu empfehlen.
Außerdem kann man so auch feste Nameserver-Einträge für die Clients
machen. Es ist übrigens möglich, dass die verschiedenen
PPP-Interfaces, die im Server erzeugt werden, alle die gleiche
IP-Nummer haben. Man braucht also nicht für jede Verbindung zwei
IP-Adressen.

Also könnte man in einem gedachten Netzwerk folgenden Plan machen:

* 192.168.1.x - normales, internes Netz
* 192.168.2.x - interne DMZ (demilitarisierte Zone)
* 192.168.3.1 - PPP-Interface des Servers
* 192.168.3.2 - VPN-Client test1
* 192.168.3.3 - VPN-Client test2
* 192.168.3.4-254 - ggf. Nummernpool für Clients ohne feste Nummer

Dann stellt sich die Frage, auf welchem Rechner im Netz man den
VPN-Server installiert. Steht hierzu kein eigener, dedizierter
Server zur Verfügung, so sollte dringend davon abgeraten werden,
"irgendwo" auf einem anderen Server oder einem Client diese
zusätzlichen Netzwerkverbindungen zu erstellen. Dadurch wird nur
das Routing und damit auch das Sicherheitskonzept
unübersichtlicher. Am besten sind die VPN-Interfaces da
untergebracht, wo auch ansonsten das Routing erledigt wird, also
z.B. am Router zwischen internem Netz und DMZ bzw. Internet. Die
Firewall-Einstellungen sollten dann im Prinzip denen der DMZ
entsprechen. Man sollte die VPN-Clients auch nicht direkt mit einem
Server in der DMZ verbinden. Dann läuft man Gefahr, dass bei einer
"Übernahme" der DMZ der gesamte Verkehr mit den VPN-Clients in die
falschen Hände gerät.

== Server-Konfiguration ==

Nach Installation des Paketes muss zuerst die Konfigurationsdatei
von pptpd erweitert werden. hier habe ich folgendes eingetragen:

 localip 192.168.3.1
 remoteip 192.168.3.2-254

Die angegebenen Remote-IPs werden nur verwendet, wenn in der Datei
''pap-secrets'' keine Adresse angegeben ist.

Die eigentliche Verbindung mit Authentifizierung etc. ist eine
normale PPP-Verbindung. Deshalb gelten hierfür die normalen
ppp-Optionen. Diese stehen global in der Datei ''/etc/ppp/options''
und speziell für die pptpd-Verbindung in ''/etc/ppp/pptpd-options''
(diese zweite Datei wird pppd auf der Kommandozeile übergeben.)
. Auf jeden Fall kann man keine sicherheitsrelevanten
Einstellungen, die in ''/etc/ppp/options'' stehen, nachträglich
entschärfen. Wenn man also testweise erstmal ohne Authentifizierung
arbeiten will, muss man den Eintrag "auth" in dieser Datei
auskommentieren. (nicht vergessen, das sp?ter wieder
einzuschalten!)

Nun zur Datei ''/etc/ppp/pptpd-options'', in der die eigentlichen
ppp-Optionen stehen. Für einen ersten Test kann man diese auf
folgenden Stand bringen. Achtung! Hier ist jede Authentifizierung
und/oder Verschlüsselung abgeschaltet.

 debug
 name pptpgate
 ms-dns 192.168.1.1    # ggf. anpassen auf eigenen Nameserver
 netmask 255.255.255.0
 nodefaultroute

Dann kann man den PPTP-Server neu starten mit:

 /etc/init.d/pptpd restart

Jetzt müsste man eine Testverbindung aufbauen können. Wenn man das
geschafft hat, kann man sich daran machen, die Sache sicherer zu
machen. Hierzu sollte die Datei ''/etc/ppp/pptpd-options'' so
aussehen:

 name pptpgate
 auth
 require-chap
 ms-dns 192.168.1.1    # ggf. anpassen auf eigenen Nameserver
 netmask 255.255.255.0
 nodefaultroute

Jetzt müssen die chap-Passwörter in die Datei
''/etc/ppp/chap-secrets'':

 test1 ppptpgate passwort1 192.168.3.2
 test2 ppptpgate passwort2 192.168.3.3

Jetzt nochmal den ppptp neu gestartet und ab jetzt kann keiner mehr
ohne Passwort eine Verbindung aufbauen. Die Clients bekommen
automatisch die angegebene IP-Nummer, so dass man sie sogar in seinen
Nameserver aufnehmen kann. Außerdem lassen Sie sich so auch von
Diensten im Netz über diese Nummer identifizieren und
auseinander halten.

== Client-Konfiguration ==

Wenn man das Paket installiert hat, hat man eigentlich schon alles
geschafft. Man muss ebenfalls ''/etc/ppp/options'' ändern, wenn man
vom Server keine Authentifizierung verlangen will. Wie gesagt
sollte man später überlegen, das wieder zurückzunehmen!

Jetzt startet man mit

 pptp server-name.domain.bla

die Verbindung. Fertig! Auf beiden Seiten ist ein pppx-Device
dazugekommen und der Tunnel steht.

Leider geht das mit dem Debian-pptp-Paket nicht ganz so einfach.
Hier wird offensichtlich ein Dateiname bei den Pseudo-TTYs
verdreht. Wer damit kämpft, kann mich (ThomasBayen) nochmal fragen.
Ich arbeite allerdings noch an der Lösung des Problems und hoffe,
diesen Absatz dann entfernen zu können. :-)

Man kann weitere pppd-Parameter in der Kommandozeile angeben.
Insbesondere kann man diese Parameter auch in einer peers-Datei
speichern. Sind die Einstellungen in ''/etc/ppp/peers/vpn2home'',
so kann man den Aufruf so machen:

 pptp server-name.domain.bla call vpn2home

In dieser Datei kann man dann z.B. mit ''name'' den Login-Namen
angeben. Man kann auch ein ip-up-Skript angeben, das ggf. den
Nameserver, Routing zum internen Netz, etc. richtig einstellt. Der
Nameserver wird brigens nicht automatisch eingestellt, auch wenn
man usepeerdns angibt, da ja bereits ein Nameserver im System
eingetragen ist (ohne den würde man den Zielhost ja gar nicht
finden). Also entweder die wichtigen Sachen nach ''/etc/hosts''
oder ein Startskript, das ''/etc/resolv.conf'' anpasst.

Interessant könnte auch sein, bei der Haupt-Internet-Verbindung des
Clients ein ip-up-Skript einzurichten, das dann immer sofort und
automatisch ein VPN aufbaut. Wen sowas interessiert, kann mich
gerne fragen: Bei mir läufts. :-)

Die häufigsten Probleme, von denen berichtet wird, sind nun
übrigens Routing-Probleme. Dies hängt vor allem damit zusammen, dass
man jetzt im Prinzip zwei Routen zum Zielsystem hat. Eine direkte
und eine durch den Tunnel. Man sollte sich also bei Schwierigkeiten
genau überlegen, welches Paket wann wohin läuft. Dies wird
insbesondere interessant, wenn ich nicht die direkte Gegenstelle
der VPN-Verbindung anspreche, sondern hinter dem Tunnel durch den
PPTP-Server noch weitergeroutet werden muss.

== Windows-Client-Konfiguration ==

Zuerstmal muss das Device für VPN installiert werden. Dazu geht man
so vor:

* Start / Systemsteuerung
* Software anwählen
* Registerkarte "Windows Setup"
* Komponente "Verbindungen" ausw?hlen
* komponente "Virtuelles Privates Netzwerk" anwählen (Häkchen machen)
* Jetzt zweimal auf OK klicken


Jetzt ist die benötigte Software installiert. Als nächstes muss
eine Verbindung eingerichtet werden. Hierzu geht man
folgendermassen vor:

* Start / Programme / Zubehör / Kommunikation / DFÜ-Netzwerk
* "Neue Verbindung einrichten" anklicken
* Als Namen gibt man eine Bezeichnung an, unter der man die Verbindung nachher auswählen kann
* Als Gerät muss "Microsoft VPN Adapter" ausgewählt werden
* Als Hostnamen gibt man den Namen oder die IP-Adresse des Servers an, zu dem man Kontakt aufnehmen will

Nach der Grundeinrichtung hat man einen Eintrag im Ordner der
DFÜ-Verbindungen. Zu den restlichen Einstellungen klickt man jetzt
auf diesen mit der rechten Maustaste und geht im erscheinenden
Kontextmenü auf "Einstellungen". Auf der zweiten Registerkarte muss
man jetzt noch ein paar Kästchen beglücken:

* Netzwerkverbindung herstellen sollte ausgeschaltet sein. Windows versucht sonst, über das VPN mit einem NT-Domänencontroller Verbindung aufzunehmen, der normalerweise nicht da ist, wenn die Gegenstation ein Linux-Rechner ist (und Samba nicht speziell dafür konfiguriert ist). Das dauert beim Verbindungsaufbau eine ganze Zeit.
* Passwort-Verschlüsselung sollte eingeschaltet werden. Das kann nie schaden.
* Datenkomprimierung kann eingeschaltet werden, ist bei mir offensichtlich aber nie benutzt worden. Da scheinen sich Linux und Windows nicht auf ein Kompressionsverfahren einigen zu können.
* Die Verschlüsselung funktioniert nicht so einfach (siehe unten), also ausschalten.
* Die Protokolle können bis auf TCP/IP abgeschaltet werden

Auf die Seite mit den TCP/IP-Einstellungen kann man auch mal
klicken. Normalerweise ist dort nichts zu ändern. Eventuell ist die
Frage interessant, ob das VPN zur Default-Route werden soll. Falls
auf dem Client während der Verbindung z.B. gesurft wird, wird das
alles über den VPN-Server geroutet.

In der Dokumentation zum pppt-Server stand, dass man, um Passworte
und Verschlüsselung mit Windows-Clients zu benutzen, den pppd
patchen muss. Passworte (auch verschlüsselt) klappen bei mir
jedoch. Vielleicht habe ich ja eine neuere pppd-Version.
Verschlüsselung konnte ich allerdings nicht einschalten. Dazu muss
man dann ggf. eine entsprechend gepatchte pppd-Version herstellen.

== dynamische IP beim Server ==

Bleibt noch die Frage, was ich beim Client als Hostnamen des
Servers angebe, wenn ich mich z.B. übers Internet in das heimische
Netzwerk einwählen will, der heimische Rechner aber über eine
preiswerte Flatrate am Netz hängt und daher keine feste IP-Adresse
geschweige denn einen Domain-Namen hat. Hierbei hilft
DynamischesDNS, das Thema eines anderen Artikels ist.

== Firewall-Konfiguration ==

=== Tunnel durch die Firewall =====

Die Firewall-Konfiguration ist im Grunde genommen ganz einfach.
Dabei gehe ich davon aus, dass der PPTP-Server nicht hinter einer
Masquerading-Router sitzt. Falls doch, sollte man einen Blick ins
VPN-Masquerading-HOWTO werfen. Die entsprechenden Kernelmodule
scheint es aber noch nicht für das Kernel 2.4-NAT zu geben.

Es werden zwei verschiedene Verbindungen benutzt. Die
Steuerverbindung ist eine simple TCP-Verbindung mit Port 1723 des
Servers. Der Datenverkehr geht allerdings über eine Verbindung, die
auf dem ''GRE''-Protokoll aufbaut. Das ist kein Port, sondern ein
'''Protokoll'''. Dieser Umstand macht ein bisschen Ärger, da alte
Firewalls damit gar nichts anfangen können. Die Kernel-2.4-Firewall
kann das zwar, sie kann aber nicht in die Pakete hereinschauen und
sehen, ob diese zu einer bestimmten Verbindung gehören (stateful
filtering). Man muss also die Firewall generell für gre-Pakete
öffnen. An sich ist das nicht schlimm, weil die sonst nie benutzt
werden und PPTP seine eigenen Pakete gut erkennt. Sollte ein
Cracker allerdings im System sein, könnte er per GRE einen eigenen
Kommunikationskanal aufbauen. Allerdings hat man sowieso ein
Problem, wenn ein Cracker den PPTP-Server erobert hat. Ob es dann
noch darauf ankommt, muss jeder selber wissen...

Ein anderes Problem ist, wenn Client oder Server sogar hinter einer
Masquerading Firewall sitzen. Hier müssen "intelligente"
Filtermodule eingesetzt werden, die den obigen Nachteil ausgleichen
und die Pakete Ihrer Verbindung zuordnen können. Leider habe ich
ein solches Modul für den Kernel 2.4 (noch) nicht gefunden.

Abhängig vom verwendeten Firewall-Skript und den verwendeten chains
könnten die Firewall-Befehle so ähnlich aussehen:

 # VPN-Experiment
 # PPTP control channel
 iptables -A fweingang -j ACCEPT -p tcp --dport 1723
 iptables -A fwausgang -j ACCEPT -p tcp --sport 1723
 # PPTP Datenverkehr
 iptables -A fweingang -j ACCEPT -p gre
 iptables -A fwausgang -j ACCEPT -p gre

=== Die Firewall am Ende des Tunnels ===

Natürlich ist nicht außer acht zu lassen, dass man sich durch einen
Tunnel ein relativ fremdes und unsicheres System ins Netz holt.
Also sollte man hier darauf achten, dass man entsprechende Regeln
für die VPN-Verbindungen erstellt. Im Prinzip handelt es sich um
Rechner, die noch am ehesten mit denen in einer demilitarisierten
Zone (DMZ) vergleichbar sind. Also sollte man auch ähnliche Regeln
darauf anwenden. Aber das ist eher Thema eines Firewall-Artikels
(so wie FireWallScript oder ShoreWall).

=== ShoreWall-Firewall ===

Unter der Adresse http://www.shorewall.net/PPTP.htm findet man das
Kapitel der ShoreWall-Dokumentation, das sich mit PPTP beschäftigt.
Dort ist auch nochmal eine komplette PPTP-Installation beschrieben
(auch mit Verschlüsselung etc.). Das ist sehr zu empfehlen.
Ansonsten hier meine eigenen ShoreWall-Einträge für PPTP in Kürze:

'''interfaces'''
 net     ppp0    -                 noping,dropunclean,norfc1918
 ...
 vpn     ppp+    192.168.3.0/24    dropunclean

'''hosts'''
 vpn     ppp+:192.168.4.0/24

'''rules'''
 # Regeln, damit das VPN überhaupt funktioniert:
 ACCEPT  net   fw                tcp   1723
 ACCEPT  net   fw                gre
 ACCEPT  fw    net               gre
 # Regeln, die den Verkehr durch das VPN steuern:
 ACCEPT  vpn   loc               tcp  ssh,www,pop3,smtp,wasauchimmer
 # Der Nameserver sitzt z.B. in loc
 ACCEPT  vpn   loc:192.168.1.6   tcp   domain
 ACCEPT  vpn   loc:192.168.1.6   udp   domain

== Links ==

* ~PoPToP-HOWTO (/usr/doc/pptpd/html/HOWTO-~PoPToP.txt.gz)
* http://www.poptop.org/
* http://www.shorewall.net/PPTP.htm

[{Tag VPN Windows}]