Mac nix basteln:OpenVPN

Aus Attraktor Wiki

Wechseln zu: Navigation, Suche

Einleitung

Um diesen Artikel einigermaßen 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.

Bei VPN geht es grundsätzlich darum, eine verschlüsselte Verbindung zwischen Rechnern über ein Drittnetz aufzubauen, damit sie agieren 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:

  1. Verbinden zweier Rechner über ein anderes Netz, damit sie agieren können, als würden sie im selben Netz hängen. (Wenn es sich lediglich um zwei Rechner handelt, gibt es sicherlich auch einfacherere Wege zum Erfolg)
  2. Einzelne Rechner (Klienten) sollen sich über ein anderes Netz (z.B. dem Internet) mit einem privaten Netz verbinden (z.B. Firmennetz): Klient zu server Verbindung mit routing oder Klient zu server Verbindung mit bridging
  3. Zusätzlich zum Letzteren kann man auch den Internetverkehr der Klienten über das private Netz wieder ins Internet routen. Das kann sinnvoll sein, wenn man sich an einem Ort mit Internetsperren befindet
  4. Verbinden zweier Netze über ein drittes, damit die beiden so agieren können, als wären sie eins. (Z.B. zum Verbinden mehrerer Firmenstandorte)

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. Dieser ist ggf. auf dem Router zum OpenVPN-server durchzuleiten.

Die VPN-Verbindung wird über eine virtuelle Netzwerkkarte getunnelt. Dieses virtuelle Gerät heißt 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 weiß, ob es auch ohne funktionert. Möglicher Weise 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 agieren 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 Subnetz 10.8.0.0/24 erhalten.

klient1.conf

client # Diese Datei konfiguriert einen Klienten

remote openvpn.beispiel.de 1194 # Hostname/externe IP des servers/routers, Port entsprechend anpassen proto udp # Protokoll UDP, für TCP: proto tcp-client dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap
# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/klient1cert.pem key ./Schluessel/klient1key.pem

Die Konfiguration 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

# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/servercert.pem key ./Schluessel/serverkey.pem dh ./dh1024.pem
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

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:
$ sudo openvpn --config server.conf

Auf dem Klienten:
$ sudo openvpn --config klient1.conf

Der Server sollte unter 10.8.0.1 zu erreichen sein
$ ping 10.8.0.1


Klient zu server Verbindung mit routing

Diese 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

remote openvpn.beispiel.de 1194 # Hostname/externe IP des servers/routers, Port entsprechend anpassen proto udp # Protokoll UDP, für TCP: proto tcp-client dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap
# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/klient1cert.pem key ./Schluessel/klient1key.pem

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

# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/servercert.pem key ./Schluessel/serverkey.pem dh ./dh1024.pem
client-to-client # Daten von VPN-Client zu VPN-Client wird direkt in OpenVPN weitergeleitet
push "route 192.168.1.0 255.255.255.0" # Den Client über das Server-LAN informieren (wichtig!)
# float # Nur wenn Clients ihre IPs während der Verbindung wechseln
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

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önnen. 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-Problematik

Leider 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:
$ sudo sysctl -w net.inet.ip.forwarding=1

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.
Beispielsweise will der Rechner 192.168.1.5 aus dem Intranet mit einem VPN-Klienten 10.8.0.6 reden. Er wird seinen router fragen, wo er diesen Rechner findet. Und wenn der router nicht gleichzeitig auch der VPN-server ist, wird dieser Antworten: kenne ich nicht. Es gibt also zwei Möglichkeiten. Entweder muss der router auch der VPN-server sein, oder man muss auf jedem Rechner des Intranets eine Route einrichten die sagt: wenn Du einen Rechner aus dem Netz 10.8.0.0/24 erreichen möchtest, frag bitte nicht deinen Standardrouter sondern den VPN-server, der Hilft dir weiter.
$ sudo route add -net 10.8.0.0 -netmask 255.255.255.0 -gateway 192.168.1.2
In diesem Beispiel wird angenommen, dass die Intranet-Adresse des VPN-servers 192.168.1.2 ist.


Klient zu server Verbindung mit bridging

Im letzten Beispiel hat man also verschiedene Subnetze (das Intranet des VPN servers und das VPN selbst) miteinander Verbunden. Beim bridging agiert 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

remote openvpn.beispiel.de 1194 # Hostname/externe IP des servers/routers, Port entsprechend anpassen proto udp # Protokoll UDP, für TCP: proto tcp-client dev tap0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tap0
# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/klient1cert.pem key ./Schluessel/klient1key.pem

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

port 1194 # Auf Port 1194 horchen proto udp # Protokoll UDP, für TCP: proto tcp-server dev tap0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tap0
# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/servercert.pem key ./Schluessel/serverkey.pem dh ./dh1024.pem
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

Der Server soll also als Brücke agieren, 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 agieren, als würden sie im selben Intranet mit dem VPN-server hängen.


Verbinden mehrerer Netze

Dies 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

remote openvpn.beispiel.de 1194 # Hostname/externe IP des servers/routers, Port entsprechend anpassen proto udp # Protokoll UDP, für TCP: proto tcp-client dev tun0 # Die Verbindung geht über die Virtuelle Netzwerkkarte tun0. Alternativ, tap
# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/klient1cert.pem key ./Schluessel/klient1key.pem

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

# Hier die Pfade anpassen um auf die erstellten Schlüssel zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/servercert.pem key ./Schluessel/serverkey.pem dh ./dh1024.pem
client-config-dir ./ccd route 192.168.1.0 255.255.255.0 # Klientennetz + Maske push "route 192.168.0.0 255.255.255.0" # Den Client über das Server-LAN informieren
# float # Nur wenn Clients ihre IPs während der Verbindung wechseln
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

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 agieren, um die beiden Netzwerke über VPN zusammen zu bringen. Beide müssen also wie oben beschrieben als router konfiguriert werden.

Danach sollten die Rechner unter den IPs des einleitenden Schaubildes pingbar sein.

Diese Seite wurde zuletzt am 16. Oktober 2012 um 11:14 Uhr geändert. Diese Seite wurde bisher 7.151 mal abgerufen.