Mac nix basteln:OpenVPN: Unterschied zwischen den Versionen

Aus Attraktor Wiki

Wechseln zu: Navigation, Suche
Zeile 26: Zeile 26:
  
  
 +
<!--
 
<h2>Testkonfiguration</h2>
 
<h2>Testkonfiguration</h2>
 
Dieser Absatz stellt den denkbar einfachsten Aufbau dar, ist aber nicht wirklich praxistauglich. Der Absatz kann übersprungen werden.
 
Dieser Absatz stellt den denkbar einfachsten Aufbau dar, ist aber nicht wirklich praxistauglich. Der Absatz kann übersprungen werden.
Zeile 117: Zeile 118:
 
</table>
 
</table>
 
Die IP 10.8.0.1 ist also dem Tunnelgerät zugeordnet worüber die beiden Rechner nun kommunizieren können.
 
Die IP 10.8.0.1 ist also dem Tunnelgerät zugeordnet worüber die beiden Rechner nun kommunizieren können.
 +
-->
  
  
 +
<h2>Klient zu server Verbindung (peer to peer)</h2>
 +
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.
  
<h2>Klient zu Netz Verbindung</h2>
+
<i>klient1.conf</i>
 
+
<i>klient.conf</i>
+
 
  client # Diese Datei konfiguriert einen Klienten
 
  client # Diese Datei konfiguriert einen Klienten
 
  <br>
 
  <br>
Zeile 135: Zeile 137:
  
 
<p>
 
<p>
Die Konfiguartion des Klienten ist also recht simpel: Adresse &amp; 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.
+
Die Konfiguartion des Klienten ist also recht simpel: Adresse &amp; 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.
 
</p>
 
</p>
  
Zeile 160: Zeile 162:
  
 
Auf dem Klienten:<br>
 
Auf dem Klienten:<br>
<code>$ sudo openvpn --config klient.conf</code>
+
<code>$ sudo openvpn --config klient1.conf</code>
 +
 
 +
Der Server sollte unter 10.8.0.1 zu erreichen sein<br>
 +
<code>$ ping 10.8.0.1</code>
 +
 
 +
 
 +
<h2>Klient zu server Verbindung mit routing</h2>
 +
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.
 +
 
 +
<i>klient1.conf</i>
 +
client # Diese Datei konfiguriert einen Klienten
 +
<br>
 +
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 <i>tun0</i>. Alternativ, tap
 +
<br>
 +
# Hier die Pfade anpassen um auf die erstellten Keys zu verweisen
 +
ca ./Zertifikate/vpn-ca.pem
 +
cert ./Zertifikate/klient1cert.pem
 +
key ./Schluessel/klient1key.pem
 +
 
 +
<p>
 +
Man sieht, für die Klienten ändert sich nichts. Es ist die selbige Konfiguration, wie im obigen Beispiel.
 +
</p>
 +
 
 +
<i>server.conf</i>
 +
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
 +
<br>
 +
# Hier die Pfade anpassen um auf die erstellten Keys zu verweisen
 +
ca ./Zertifikate/vpn-ca.pem
 +
cert ./Zertifikate/servercert.pem
 +
key ./Schluessel/serverkey.pem
 +
dh ./dh1024.pem
 +
<br>
 +
client-to-client # Daten von VPN-Client zu VPN-Client wird direkt in OpenVPN weitergeleitet
 +
<br>
 +
push "route 192.168.1.0 255.255.255.0" # Den Client über das Server-LAN informieren (wichtig!)
 +
<br>
 +
# float # Nur wenn Clients ihre IPs während der Verbindung wechseln
 +
<br>
 +
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten Timeout fuer Clientverbindung
 +
 
 +
<p>
 +
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.<br>
 +
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.
 +
</p>
 +
Unter LINUX & Windows geht das [http://wiki.openvpn.eu/index.php/Config_ServerNET_Routing#Forwarding_am_Server_aktivieren folgendermaßen]. Unter Mac OS X sollte man sich ggf. eine plist schreiben, damit dieser Befehl beim Start ausgeführt wird:<br>
 +
<code>$ sudo sysctl -w net.inet.ip.forwarding=1</code>
 +
 
 +
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.<br>
 +
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.<br>
 +
<code>$ sudo route add -net 10.8.0.0 -netmask 255.255.255.0 -gateway 192.168.1.2</code><br>
 +
In diesem Beispiel wird angenommen, dass die Intranet-Adresse des VPN-servers 192.168.1.2 ist.

Version vom 29. April 2012, 12:13 Uhr

Einleitung

Um 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:

  1. Verbinden zweier Rechner über ein anderes Netz, damit sie aggieren 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)
  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 aggieren 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, 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

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 Keys zu verweisen ca ./Zertifikate/vpn-ca.pem cert ./Zertifikate/klient1cert.pem key ./Schluessel/klient1key.pem

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

# Hier die Pfade anpassen um auf die erstellten Keys 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 Timeout fuer Clientverbindung

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 Keys 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 Keys 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 Timeout fuer Clientverbindung

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.
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.