Attraktor Wiki - User contributions [en]

Termin:LoRaWAN: Kick-Off The Things Network Hamburg

2017-03-15T06:45:44Z

Andre: Andre moved page Termin:LoRaWAN: Kick-Off The Things Network Hamburg to Termin:LoRaWAN - Kick-Off The Things Network Hamburg

#REDIRECT [[Termin:LoRaWAN - Kick-Off The Things Network Hamburg]]

Termin:LoRaWAN - Kick-Off The Things Network Hamburg

2017-03-15T06:45:44Z

Andre: Andre moved page Termin:LoRaWAN: Kick-Off The Things Network Hamburg to Termin:LoRaWAN - Kick-Off The Things Network Hamburg

{{Termin
|date=2017/03/17 20:00:00
|enddate=2017/03/17 22:00:00
|title=LoRaWAN: Kick-Off The Things Network Hamburg
|url=https://www.eventbrite.de/e/community-kick-off-the-things-network-hamburg-tickets-31873626876
|visible=true
}}
https://www.thethingsnetwork.org/ (TTN) ist ein Projekt, das es sich zum Ziel gesetzt hat, ein globales, für jeden frei zugängliches IoT-Netzwerk aufzubauen. Auch in Hamburg ist eine entsprechende Community im Entstehen.

Hierfür findet am 17. März ein Kick-off Treffen von https://www.thethingsnetwork.org/community/hamburg/ statt. Details findet ihr auf https://www.eventbrite.de/e/community-kick-off-the-things-network-hamburg-tickets-31873626876. Das Treffen findet im Rahmen des Freifunk Hamburg Freitagstreffen im attraktor e.V. statt.

2012-04-29T14:00:37Z

Andre:

Mac nix basteln:OpenVPN

2012-04-29T13:03:03Z

Andre:

<h2>Einleitung</h2>
Um diesen Artikel einigermassen sinnvoll nutzen zu können, sei empfohlen vorher die [[Mac_nix_basteln:Krypto_Grundlagen|Krypto Grundlagen]] gelesen zu haben. Darüber hinaus wird es zum Anwenden der aufgelisteten Beispiele erforderlich werden [[Mac_nix_basteln:OpenSSL|Schlüssel per OpenSSL]] erzeugt zu haben (mit Außnahme des Testbeispiels).

<p>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:</p>
<ol>
<li>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)</li>
<li>Einzelne Rechner (Klienten) sollen sich über ein anderes Netz (z.B. dem Internet) mit einem privaten Netz verbinden (z.B. Firmennetz)</li>
<li>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</li>
<li>Verbinden zweier Netze über ein drittes, damit die beiden so aggieren können, als wären sie eins. (Z.B. zum Verbinden mehrerer Firmenstandorte)</li>
</ol>

Die hier aufgeführten Beispiele sind aus verschiedenen Quellen zusammengetragen. Um einen guten Durchblick zum bekommen, lohnt es sich sie alle zu studieren:
<ul>
<li>[http://openvpn.net/index.php/open-source/documentation/howto.html OpenVPN.net]</li>
<li>[http://wiki.openvpn.eu/ OpenVPN Wiki]</li>
<li>[http://www.online-tutorials.net/security/openvpn-tutorial/tutorials-t-69-209.html OpenVPN Tutorial]</li>
<li>[http://wiki.freifunk.net/OpenVPN_Howto OpenVPN Howto]</li>
</ul>
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 [http://openvpn.net/index.php/open-source/documentation/howto.html#examples 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 [[Mac_nix_basteln:OpenSSL|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 <i>getunnelt</i>. 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 [http://tuntaposx.sourceforge.net/ 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).



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

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

<p>
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.
</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 Schlüssel zu verweisen
ca ./Zertifikate/vpn-ca.pem
cert ./Zertifikate/servercert.pem
key ./Schluessel/serverkey.pem
dh ./dh1024.pem
<br>
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

<p>
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 <i>tun0</i>-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.
</p>

Nun kann es losgehen. Auf dem server:<br>
<code>$ sudo openvpn --config server.conf</code>

Auf dem Klienten:<br>
<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 Schlüssel 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 Schlüssel 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 time out für Klientenverbindung

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

<h3>Routing-Problematik</h3>
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>
</p>

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.

<h2>Klient zu server Verbindung mit bridging</h2>
Im [[https://wiki.attraktor.org/index.php?title=Mac_nix_basteln:OpenVPN&action=submit#Klient_zu_server_Verbindung_mit_routing|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 [http://de.wikipedia.org/wiki/Switch_%28Computertechnik%29 switch].

<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 tap0 # Die Verbindung geht über die Virtuelle Netzwerkkarte <i>tap0</i>
<br>
# 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

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

<i>server.conf</i>
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
<br>
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''
<br>
# 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
<br>
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten time out für Klientenverbindung

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

Mac nix basteln:OpenVPN

2012-04-29T12:13:14Z

Andre:

<h2>Einleitung</h2>
Um diesen Artikel einigermassen sinnvoll nutzen zu können, sei empfohlen vorher die [[Mac_nix_basteln:Krypto_Grundlagen|Krypto Grundlagen]] gelesen zu haben. Darüber hinaus wird es zum Anwenden der aufgelisteten Beispiele erforderlich werden [[Mac_nix_basteln:OpenSSL|Schlüssel per OpenSSL]] erzeugt zu haben (mit Außnahme des Testbeispiels).

<p>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:</p>
<ol>
<li>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)</li>
<li>Einzelne Rechner (Klienten) sollen sich über ein anderes Netz (z.B. dem Internet) mit einem privaten Netz verbinden (z.B. Firmennetz)</li>
<li>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</li>
<li>Verbinden zweier Netze über ein drittes, damit die beiden so aggieren können, als wären sie eins. (Z.B. zum Verbinden mehrerer Firmenstandorte)</li>
</ol>

Die hier aufgeführten Beispiele sind aus verschiedenen Quellen zusammengetragen. Um einen guten Durchblick zum bekommen, lohnt es sich sie alle zu studieren:
<ul>
<li>[http://openvpn.net/index.php/open-source/documentation/howto.html OpenVPN.net]</li>
<li>[http://wiki.openvpn.eu/ OpenVPN Wiki]</li>
<li>[http://www.online-tutorials.net/security/openvpn-tutorial/tutorials-t-69-209.html OpenVPN Tutorial]</li>
<li>[http://wiki.freifunk.net/OpenVPN_Howto OpenVPN Howto]</li>
</ul>
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 [http://openvpn.net/index.php/open-source/documentation/howto.html#examples 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 [[Mac_nix_basteln:OpenSSL|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 <i>getunnelt</i>. 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 [http://tuntaposx.sourceforge.net/ 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).



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

<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>
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.
</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>
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten Timeout fuer Clientverbindung

<p>
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 <i>tun0</i>-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.
</p>

Nun kann es losgehen. Auf dem server:<br>
<code>$ sudo openvpn --config server.conf</code>

Auf dem Klienten:<br>
<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.

2012-02-18T12:06:23Z

Andre:

<h2>S/MIME</h2>
[http://de.wikipedia.org/wiki/SMIME S/MIME] ist eine Methode zum signieren und verschlüsseln von Nachrichten, ähnlich wie das in der Öffentlichkeit vielleicht bekanntere PGP oder seine quelloffene Implementation [http://de.wikipedia.org/wiki/GNU_Privacy_Guard GPG]. Im Gegensatz zu GPG bietet S/MIME einige Komfortvorteile:
<ul>
<li>S/MIME wird standardmäßig von allen (gängigen) email-Programmen unterstützt (vielleicht mal mit der Ausnahme mobiler Plattformen). D.h. man muss sich nicht um irgendwelche plugins oder sonstige Extraprogramme kümmern, die dann bei der nächsten Aktualisierung des email-Progs nicht mehr laufen</li>
<li>Schlüssel werden automatisch durch das Versenden signierter Nachrichten verteilt. Man brauch sich also nicht um Schlüsselserver kümmern, oder jemanden seinen öffentlichen Schlüssel zusenden und diesem dann erklären, dass er ihn bei sich im Schlüsselbund hinzufügen muss</li>
<li>Man bracht nicht jedem Schlüssel sagen, dass man ihm vertraut. Vertraut man dem Wurzelzertifikat, vertraut man allen Schlüsseln, die dagegen gezeichnet wurden</li>
</ul>

Nachteile:
<ul>
<li>Das System besteht auf Vertrauen gegenüber den Zertifikatsstellen (Certification Authorities = CAs), bzw. deren Wurzelzertifikaten</li>
<li>Es scheint, dass die CA auch den privaten Schlüssel des Nutzers hat</li>
</ul>

<h4>Digitale Signatur</h4>
Eine Signatur stellt sicher, dass der Absender der ist, der er vorgibt zu sein und dass die Nachricht unterwegs nicht verändert wurde. Sie entspricht also in etwa einem Siegel auf einem konventionellen Brief.

<h4>Verschlüsselung</h4>
Verschlüsselung stellt sicher, dass nur designierte Empfänger die Nachricht lesen kann. Sie entspricht also grob dem Umschlag eines konventionellen Briefes. Eine unverschlüsselte Nachricht entspricht also in etwa einer Postkarte: Jeder unterwegs kann sie lesen und auch drin rum kritzeln.

<h4>Zertifikate</h4>
Das Unterschreiben und Verschlüsseln erfolgt durch sog. Zertifikate. Dabei gibt es verschiedene [http://en.wikipedia.org/wiki/Public_key_certificate#Classification Typen]. Man kann nämlich nicht nur Strompost verschlüsseln, sondern auch Quelltext unterschreiben und der Gleichen. Da wir hier von Strompost reden, reicht uns ein Klasse 1 Zertifikat. Doch woher bekommt man das? Dies kann von den oben genannten Zertifikatsstellen ausgestellt werden. Derer gibt es sehr viele: z.B. Verisign, thawte... oder auch große Firmen haben ihre eigenen Wurzelzertifikate (Telekom, Visa....). Diese ganzen Wurzelzertifikate sind bei den Betriebsystemen bzw. den Mozillaprodukten (Firefox und Thunderbird - welche im Gegensatz zu den anderen Browsern und email-Progs nicht auf die Schlüsseldatenbank des Betriebssystems zurückgreifen) idR. vorinstalliert. Das Problem ist, dass die meisten Geld für die Ausstellung eines Zertifikats für den Anwender haben möchten. Der nicht gewinnorientierte Verein [https://www.cacert.org/ CAcert] stellt sie kostenlos aus.

<p> <br></p>
<h3>CAcert</h3>
Das Problem mit [https://www.cacert.org/ CAcert] ist, dass deren Wurzelzertifikate im Gegensatz zu den anderen genannten nicht vorinstalliert ist. Diese sollte man sich also zunächst einmal installieren. (Vorweg: Alle Schritte muss man nur einmal machen. Danach hat man keinerlei Mühe mehr)

<br>
<h4>Wurzelzertifikate installieren</h4>
Die [http://en.wikipedia.org/wiki/Public_key_certificate#Classification Klasse 1 & 3] Wurzelzertifikate findet man unter [https://www.cacert.org/index.php?id=3 https://www.cacert.org/index.php?id=3]. Dort klickt man einfach <i>Root-Zertifikat (PEM Format)</i> und <i>Zwischen Zertifikat (PEM Format)</i> an. Was nun folgt ist stark vom eigenen System abhängig.

<ul>
<li><b>OS X (Safari / Apple Mail)</b>: Safari wird die Zertifikate einfach nur speichern. Man klickt dann die gespeicherten Dateien <i>root.crt</i> und <i>class3.crt</i> im <i>Downloads</i>-Verzeichnis an. Worauf sie der OS X Schlüsselbundverwaltung hinzugefügt werden. Das Zertifikat ist nun installiert und Systemweit verfügbar. Also beispielsweise auch für <i>Apple Mail</i>.</li>
<li><b>Windows (Internet Explorer / Outlook)</b>: Der Internet Explorer unter Windows wird ein Fenster mit Zertifikatsinformationen öffnen. Man klickt unten auf den Knopf <i>Zertifikat installieren...</i> und klickt solange <i>OK</i> und <i>Weiter</i> bis der Dialog durch ist. Das Zertifikat ist nun installiert und Windows-Systemweit verfügbar. Also beispielsweise auch für <i>Outlook</i>.</li>
<li><b>Firefox / Thunderbird (egal welches Betriebssystem)</b>: Firefox fragt, wofür man das jeweilige Zertifikat nutzen möchte: um Websites zu identifizieren ([http://de.wikipedia.org/wiki/Https https]), um Email-Nutzer zu identifizieren (S/MIME) oder um software-Entwickler zu identifizieren. Man kann alles drei anhaken, OK und fertig. Die Anleitung um Zertifikate in Thunderbird zu nutzen findet sich [http://www.thunderbird-mail.de/wiki/Mailverschl%C3%BCsselung_mit_S/MIME#Wie_installiere_ich_ein_X.509-Zertifikat_in_TB.3F hier].</li>
<li><b>Chrome, Opera, Konquerer...</b>: Nicht ausprobiert. Wird aber wahrscheinlich irgendwie ähnlich wie die obigen Lösungen laufen.</li>
</ul>

<br>
<h4>Eigenes Zertifikat erzeugen</h4>
<ul>
<li><b>Registrieren:</b> Zunächst [https://www.cacert.org/index.php?id=1 registriert man sich an]. Hier empfiehlt es sich, im Gegensatz zu den meisten anderen Orten im Netz, seine echten persönlichen Daten anzugeben. Schliesslich möchte man das Zertifikat benutzen, um sich zu identifizieren.</li>
<li><b>email-Adressen hinzufügen:</b> jetzt meldet man sich rechts im Menü auf der [https://www.cacert.org/index.php?id=4 CAcert-Seite] an und gelangt so in sein persönliches Konto. Man wählt wiederum rechts im Menü <i>+ E-Mail-Konto</i>, klappt es aus und geht auf <i>Hinzufügen</i>. Hier sollte man alle Adressen hinzufügen mit denen man vorhat zu unterschreiben. Vorsicht bei googlemail: auch wenn man selbst nur <i>name</i>@gmail.com verwendet, verschickt googlemail die emails immer als <i>name</i>@googlemail.com. Man muss also sowohl <i>name</i>@gmail.com als auch <i>name</i>@googlemail.com hinzufügen, sonst kommt es zu Fehlern.</li>
<li><b>Zertifikat ausstellen:</b> Man klickt rechts im Menü auf <i>+ Client-Zertifikate</i> und dann auf <i>neu</i>. Nun wählt man die email-Adressen aus, für die das Zertifikat gelen soll (die Auswahlmöglichkeit besteht aus den eben hinzugefügten), klickt <i>Signieren mit dem Klasse 1 Root Zertifikat</i> und setzt einen Haken bei <i>Zertifikats-Anmeldung mit diesem Zertifikat aktivieren</i>. Mit <i>weiter</i> geht's auf die nächste Seite. Dort wählt man unter <i>Schlüsselgröße</i> hochgradig aus (entspricht z.Z. 4096bit) und klickt auf erstellen. Je nach System fügt man den Schlüssel nun seinem System hinzu, wie man es schon für das [[http://wiki.attraktor.org/Mac_nix_basteln:SMIME#Wurzelzertifikate_installieren Wurzelzertifikat]] getan hat.</li>
</ul>

Das war's auch schon. Nun sollte das jeweilige email-Programm in der Lage sein Nachrichten zu signieren und auch zu verschlüsseln. Letzteres vorausgesetzt man hat den öffentlichen Schlüssel des Empfängers - was man automatisch hat sobald man einmal eine signierte Nachricht von demjenigen empfangen hat.

Mac nix basteln:SMIME

2012-02-18T11:43:48Z

Andre:

<h2>S/MIME</h2>
[http://de.wikipedia.org/wiki/SMIME S/MIME] ist eine Methode zum signieren und verschlüsseln von Nachrichten, ähnlich wie das in der Öffentlichkeit vielleicht bekanntere PGP oder seine quelloffene Implementation [http://de.wikipedia.org/wiki/GNU_Privacy_Guard GPG]. Im Gegensatz zu GPG bietet S/MIME einige Komfortvorteile:
<ul>
<li>S/MIME wird standardmäßig von allen (gängigen) email-Programmen unterstützt (vielleicht mal mit der Ausnahme mobiler Plattformen). D.h. man muss sich nicht um irgendwelche plugins oder sonstige Extraprogramme kümmern, die dann bei der nächsten Aktualisierung des email-Progs nicht mehr laufen</li>
<li>Schlüssel werden automatisch durch das Versenden signierter Nachrichten verteilt. Man brauch sich also nicht um Schlüsselserver kümmern, oder jemanden seinen öffentlichen Schlüssel zusenden und diesem dann erklären, dass er ihn bei sich im Schlüsselbund hinzufügen muss</li>
<li>Man bracht nicht jedem Schlüssel sagen, dass man ihm vertraut. Vertraut man dem Wurzelzertifikat, vertraut man allen Schlüsseln, die dagegen gezeichnet wurden</li>
</ul>

Nachteile:
<ul>
<li>Das System besteht auf Vertrauen gegenüber den Zertifikatsstellen (Certification Authorities = CAs), bzw. deren Wurzelzertifikaten</li>
<li>Es scheint, dass die CA auch den privaten Schlüssel des Nutzers hat</li>
</ul>

<h4>Digitale Signatur</h4>
Eine Signatur stellt sicher, dass der Absender der ist, der er vorgibt zu sein und dass die Nachricht unterwegs nicht verändert wurde. Sie entspricht also in etwa einem Siegel auf einem konventionellen Brief.

<h4>Verschlüsselung</h4>
Verschlüsselung stellt sicher, dass nur designierte Empfänger die Nachricht lesen kann. Sie entspricht also grob dem Umschlag eines konventionellen Briefes. Eine unverschlüsselte Nachricht entspricht also in etwa einer Postkarte: Jeder unterwegs kann sie lesen und auch drin rum kritzeln.

<h4>Zertifikate</h4>
Das Unterschreiben und Verschlüsseln erfolgt durch sog. Zertifikate. Dabei gibt es verschiedene [http://en.wikipedia.org/wiki/Public_key_certificate#Classification Typen]. Man kann nämlich nicht nur Strompost verschlüsseln, sondern auch Quelltext unterschreiben und der gleichen. Da wir hier von Strompost reden, reicht uns ein Klasse 1 Zertifikat. Doch woher bekommt man das? Dies kann von den oben genannten Zertifikatsstellen ausgestellt werden. Derer gibt es sehr viele: z.B. Verisign, thawte... oder auch große Firmen haben ihre eigenen Wurzelzertifikate (Telekom, Visa....). Diese ganzen Wurzelzertifikate sind bei den Betriebsystemen idR. bzw. den Mozillaprodukten (Firefox und Thunderbird - welche im Gegensatz zu den anderen Browsern und email-Progs nicht auf die Schlüsseldatenbank des Betriebssystems zurückgreifen) vorinstalliert. Das Problem ist, dass die meisten Geld für die Ausstellung eines Zertifikats für den Anwender haben möchten. Der nicht gewinnorientierte Verein [https://www.cacert.org/ CAcert] stellt sie kostenlos aus.

<p> <br></p>
<h3>CAcert</h3>
Das Problem mit [https://www.cacert.org/ CAcert] ist, dass deren Wurzelzertifikate im Gegensatz zu den anderen genannten nicht vorinstalliert ist. Diese sollte man sich also zunächst einmal installieren. (Vorweg: Alle Schritte muss man nur einmal machen. Danach hat man keinerlei Mühe mehr)

<br>
<h4>Wurzelzertifikate installieren</h4>
Die [http://en.wikipedia.org/wiki/Public_key_certificate#Classification Klasse 1 & 3] Wurzelzertifikate findet man unter [https://www.cacert.org/index.php?id=3 https://www.cacert.org/index.php?id=3]. Dort klickt man einfach <i>Root-Zertifikat (PEM Format)</i> und <i>Zwischen Zertifikat (PEM Format)</i> an. Was nun folgt ist stark vom eigenen System abhängig.

<ul>
<li><b>OS X (Safari / Apple Mail)</b>: Safari wird die Zertifikate einfach nur speichern. Man klickt dann die gespeicherten Dateien <i>root.crt</i> und <i>class3.crt</i> im <i>Downloads</i>-Verzeichnis an. Worauf sie der OS X Schlüsselbundverwaltung hinzugefügt werden. Das Zertifikat ist nun installiert und Systemweit verfügbar. Also beispielsweise auch für <i>Apple Mail</i>.</li>
<li><b>Windows (Internet Explorer / Outlook)</b>: Der Internet Explorer unter Windows wird ein Fenster mit Zertifikatsinformationen öffnen. Man klickt unten auf den Knopf <i>Zertifikat installieren...</i> und klickt solange <i>OK</i> und <i>Weiter</i> bis der Dialog durch ist. Das Zertifikat ist nun installiert und Windows-Systemweit verfügbar. Also beispielsweise auch für <i>Outlook</i>.</li>
<li><b>Firefox / Thunderbird (egal welches Betriebssystem)</b>: Firefox fragt, wofür man das jeweilige Zertifikat nutzen möchte: um Websites zu identifizieren ([http://de.wikipedia.org/wiki/Https https]), um Email-Nutzer zu identifizieren (S/MIME) oder um software-Entwickler zu identifizieren. Man kann alles drei anhaken, OK und fertig. Die Anleitung um Zertifikate in Thunderbird zu nutzen findet sich [http://www.thunderbird-mail.de/wiki/Mailverschl%C3%BCsselung_mit_S/MIME#Wie_installiere_ich_ein_X.509-Zertifikat_in_TB.3F hier].</li>
<li><b>Chrome, Opera, Konquerer...</b>: Nicht ausprobiert. Wird aber wahrscheinlich irgendwie ähnlich wie die obigen Lösungen laufen.</li>
</ul>

<br>
<h4>Eigenes Zertifikat erzeugen</h4>
<ul>
<li><b>Registrieren:</b> Zunächst [https://www.cacert.org/index.php?id=1 registriert man sich an]. Hier empfiehlt es sich, im Gegensatz zu den meisten anderen Orten im Netz, seine echten persönlichen Daten anzugeben. Schliesslich möchte man das Zertifikat benutzen, um sich zu identifizieren.</li>
<li><b>email-Adressen hinzufügen:</b> jetzt meldet man sich rechts im Menü auf der [https://www.cacert.org/index.php?id=4 CAcert-Seite] an und gelangt so in sein persönliches Konto. Man wählt wiederum rechts im Menü <i>+ E-Mail-Konto</i>, klappt es aus und geht auf <i>Hinzufügen</i>. Hier sollte man alle Adressen hinzufügen mit denen man vorhat zu unterschreiben. Vorsicht bei googlemail: auch wenn man selbst nur <i>name</i>@gmail.com verwendet, verschickt googlemail die emails immer als <i>name</i>@googlemail.com. Man muss also sowohl <i>name</i>@gmail.com als auch <i>name</i>@googlemail.com hinzufügen, sonst kommt es zu Fehlern.</li>
<li><b>Zertifikat ausstellen:</b> Man klickt rechts im Menü auf <i>+ Client-Zertifikate</i> und dann auf <i>neu</i>. Nun wählt man die email-Adressen aus, für die das Zertifikat gelen soll (die Auswahlmöglichkeit besteht aus den eben hinzugefügten), klickt <i>Signieren mit dem Klasse 1 Root Zertifikat</i> und setzt einen Haken bei <i>Zertifikats-Anmeldung mit diesem Zertifikat aktivieren</i>. Mit <i>weiter</i> geht's auf die nächste Seite. Dort wählt man unter <i>Schlüsselgröße</i> hochgradig aus (entspricht z.Z. 4096bit) und klickt auf erstellen. Je nach System fügt man den Schlüssel nun seinem System hinzu, wie man es schon für das [[http://wiki.attraktor.org/Mac_nix_basteln:SMIME#Wurzelzertifikate_installieren Wurzelzertifikat]] getan hat.</li>
</ul>

Das war's auch schon. Nun sollte das jeweilige email-Programm in der Lage sein Nachrichten zu signieren und auch zu verschlüsseln (letzteres vorausgesetzt man hat den öffentlichen Schlüssel des Empfängers).