Mac nix basteln:OpenVPNAus Attraktor WikiVersion vom 29. April 2012, 17:49 Uhr von Andre (Diskussion | Beiträge) InhaltsverzeichnisEinleitungUm diesen Artikel einigermassen sinnvoll nutzen zu können, sei empfohlen vorher die Krypto Grundlagen gelesen zu haben. Darüber hinaus wird es zum Anwenden der aufgelisteten Beispiele erforderlich werden Schlüssel per OpenSSL erzeugt zu haben (mit Außnahme des Testbeispiels). Bei VPN geht es grundsätzlich darum, eine verschlüsselte Verbindung zwischen Rechnern über ein Drittnetz aufzubauen, damit sie aggieren können, als hingen sie im selben Netz. VPN ist jedoch nicht automatisch gleich VPN. Es gibt viele Möglichkeiten ein virtuelles privates Netzwerk aufzusetzen:
Die hier aufgeführten Beispiele sind aus verschiedenen Quellen zusammengetragen. Um einen guten Durchblick zum bekommen, lohnt es sich sie alle zu studieren: Die Installation von OpenVPN ist die selbe, ob man Klient oder server ist. Gesteuert wird das Verhalten des jeweiligen Rechners über Konfigurationsdateien. Genau diese werden hier für verschiedene Beispielkonfigurationen gezeigt und erläutert. Sie sind der Einfachheit halber auf das lauffähige Minimum reduziert. Es gibt durchaus noch weitere Einstellungsmöglichkeiten zum Anpassen individueller Bedürfnisse. Ein guten Ausgangspunkt für individuelle Anpassungen findet man am Ende der OpenVPN Hilfeseiten. Die meisten (alle?) Parameter sind dort enthalten und man kann sie nach Bedarf ein und auskommentieren. Neben den Konfigurationsdateien braucht man zum Betrieb ggf. noch die bereits genannten Schlüssel. Es wird in den Beispielen davon ausgegangen, dass OpenVPN auf dem Port 1194 läuft, diese ist ggf. auf dem Router zum OpenVPN-server durchzuleiten. Die VPN-Verbindung wird über eine virtuelle Netzverkkarte getunnelt. Dieses virtuelle Gerät heisst entweder tun oder tap. Während ein tun-Gerät auf IP-Ebene läuft, läuft das tap-Gerät eine Ebene darunter auf ethernet-Ebene. Möglicher Weise müssen diese Geräte bei OS X nachinstalliert werden. Dafür gibt es TunTap (Möglicher Weise deshalb, weil TunTap auf meinen Testrechnern installiert ist und ich nicht weiss, ob es auch ohne funktionert. Möglicherweise stellt auch OpenVPN selbst tun- & tap-Geräte zur Verfügung).
Klient zu server Verbindung (peer to peer)Hier geht es um das Verbinden zweier (oder mehrer) Rechner über ein anderes Netz, damit sie aggieren können, als würden sie im selben Netz hängen. Es gibt nur einen server, der im VPN unter 10.8.0.1 zu erreichen ist, mit dem sich einer oder mehrere Klienten verbinden können, die dann höhere IPs im subnetzt 10.8.0.0/24 erhalten. klient1.conf client # Diese Datei konfiguriert einen Klienten Die Konfiguartion des Klienten ist also recht simpel: Adresse & Port des servers werden angegeben, das Protokoll ist UDP, das ganze soll über das tun0-Gerät laufen und es wird das Zertifikat der CA, das eigene Zertifikat und der eigene Schlüssel benötigt. Das war's. server.conf server 10.8.0.0 255.255.255.0 # virtuelles VPN-Netzwerk port 1194 # Auf Port 1194 horchen proto udp # Protokoll UDP, für TCP: proto tcp-server dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap Das VPN wird unter 10.8.0.0/24 laufen. Entsprechend ist darauf zu achten, dass dieser IP-Bereich weder im regulären Intranet des Klienten noch des servers vorkommt. Port ist 1194 (ggf. auf der firewall durchleiten nicht vergessen). Es wird UDP verwendet. Wenn in beiden Konfigurationsdateien TCP steht funktioniert es auch. UDP wurde gewählt, da eine der Anleitungen sagt TCP über TCP zu tunneln wäre die schlechteste Idee. Auch hier kommt das tun0-Gerät zum Einsatz und es werden die Zertifikate der CA, des servers sowie der server-Schlüssel als auch die Diffie-Hellmann-Zufallszahlen angegeben. Die Verbindung wird bis zu 3min mit einem keepalive aufrecht erhalten. Nun kann es losgehen. Auf dem server: Auf dem Klienten: Der Server sollte unter 10.8.0.1 zu erreichen sein
Klient zu server Verbindung mit routingDiese Konfiguration entspricht im Wesentlichen der letzten. Zusätzlich wird den Klienten allerdings noch erlaubt die Rechner im Intranet des server-Netzes zu sehen. Dies entspricht also dem was i.d.R. passiert wenn man sich mit seinem Firmenrechner über VPN im Intranet der Firma anmeldet. klient1.conf client # Diese Datei konfiguriert einen Klienten Man sieht, für die Klienten ändert sich nichts. Es ist die selbige Konfiguration, wie im obigen Beispiel. server.conf server 10.8.0.0 255.255.255.0 # virtuelles VPN-Netzwerk port 1194 # Auf Port 1194 horchen proto udp # Protokoll UDP, für TCP: proto tcp-server dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap Beim server ändert sich also auch recht wenig. Neu ist der Befehl client-to-client, der ermöglicht dass die verschiedenen Klienten sich auch untereinander unterhalten können - dies hätte man auch schon bei der obigen Konfiguration machen könenn. Wichtiger noch ist der Befehl push. Erst dieser informiert den Klienten darüber, dass hinter dem VPN-server noch ein Intranet liegt mit dem man kommunizieren kann. In diesem Beispiel wird angenommen, das Intranet des servers sei 192.168.1.0/24. Auch hier ist wieder zu beachten, dass dieses Intranet nicht dem eines Klienten entsprechen darf, denn sonst kommt es zu routing konflikten. Routing-ProblematikLeider ist es mit diesem Befehl allein noch nicht getan. Der server muss außerdem in die Lage versetzt werden, die Daten aus dem Intranet ins VPN zu routen und umgekehrt.
Unter LINUX & Windows geht das folgendermaßen. Unter Mac OS X sollte man sich ggf. eine plist schreiben, damit dieser Befehl beim Start ausgeführt wird: Damit ist man aber leider immer noch nicht durch. Jetzt wissen die Klienten also über das Intranet Bescheid und der server routet auch alles brav durch, doch woher wissen die Intranet-Rechner, wie sie mit den VPN-Klienten kommunizieren? Bisher gar nicht.
Klient zu server Verbindung mit bridgingIm letzten Beispiel hat man also verschiedene Subnetze (das Intranet des VPN servers und das VPN selbst) miteinander Verbunden. Beim bridging aggiert der VPN-server als Brücke, was bedeutet, dass die VPN-Klienten direkt in das Intranet des VPN-servers gehängt werden. Der server wird damit also quasi zum switch. klient1.conf client # Diese Datei konfiguriert einen Klienten Diesmal hat sich klienten-seitig nur die tun-Schnittstelle nach tap geändert. Es gehen also nicht mehr IP-Pakete über das VPN, sondern, eine Ebene tiefer, Ethernetpakete. server.conf server-bridge 192.168.1.2 255.255.255.0 192.168.1.220 192.168.1.230 # Server IP, Subnetzmaske, Start & End IPs für die VPN-Klienten Der Server soll also als Brücke aggieren, hat die IP 192.168.1.2 im Subnetz 192.168.1.2/24 und soll an die Klienten IPs im Bereich zwischen 192.168.1.220 und 192.168.1.230 verteilen. Diese Klienten können dann aggieren, als würden sie im selben Intranet mit dem VPN-server hängen.
Verbinden mehrerer NetzeDies ist ein Beispiel für das Verbinden verschiedener Netze (z.B. verschiedene Firmenstandorte oder befreundete Heimnetzwerke) durch routing. Es entspricht also dem Beispiel Klient zu server Verbindung mit routing, außer dass auf Klienten-Seite nicht nur ein Rechner, sondern ein ganzes Netzwerk hängt. --------------------------- -------------- -------------
| Server 1 | | Rechner 1.1| | R 1.N |
|OVPN-Server | Netzwerk 1: Hamburg | | | |
|eth0: openvpn.beispiel.de|--------------------------|192.168.0.2 |-- ... --|192.168.0.n|
|eth1: 192.168.0.1 | 192.168.0.0/24 | | | |
|tun0: 10.0.0.1 | | | | |
--------------------------- -------------- -------------
| | Internet
| |
| |
| | Netzwerk 3: OpenVPN
| | 10.0.0.0/24
| |
| |
-------------------------- -------------- -------------
| Server 2 | | Rechner 2.1| | R 2.N |
|OVPN-Client | Netzwerk 2: Dortmund | | | |
|eth0: IP von Provider |--------------------------|192.168.1.2 |-- ... --|192.168.1.n|
|eth1: 192.168.1.1 | 192.168.1.0/24 | | | |
|tun0: 10.0.0.6 | | | | |
-------------------------- -------------- -------------
Dementsprechend ist die Klienten-Konfiguration auch die selbe: klient1.conf client # Diese Datei konfiguriert einen Klienten server.conf server 10.0.0.0 255.255.255.0 # virtuelles VPN-Netzwerk port 1194 # Auf Port 1194 horchen proto udp # Protokoll UDP, für TCP: proto tcp-server dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap Diesmal wird noch eine weitere Datei im Klienten-Konfigurations-Verzeichnis (CCD) benötigt. Der Pfad der Datei ist in der server.conf angegeben client-config-dir ./ccd. Der Dateiname des jeweiligen Klienten muss dem common name im Klientenzertifikat klient1cert.pem entsprechen. Ist der common name dort beispielsweise dortmundnetz, muss die Datei ./ccd/dortmundnetz heissen. Der Inhalt: iroute 192.168.1.0 255.255.255.0 # Klientennetz + Maske Es scheint redundant, dass das Klientennetz zweimal angegeben wird (einmal in der server.conf und einmal im CCD). Alerdings sind die Befehle unterschiedlich: route macht das routing zwischen kernel und dem OpenVPN-server über tun0, während iroute das routing zwischen dem server und den Klienten macht. Auch hier ergibt sich wieder die routing-Problematik - und diesmal auf beiden Seiten. Sowohl der server als auch der Klient müssen in diesem Fall als Router in ihrem jeweiligen Netzwerk aggieren, um die beiden Netzwerke über VPN zusammen zu bringen. Beide müssen also wie oben beschrieben als router konfiuguriert werden. Danach sollten die Rechner unter den IPs des einleitenden Schaubildes pingbar sein. |