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