OpenVPN als Bridge aufsetzen

Der Blog ist aus Performancegründen umgezogen nach: http://greplacement.fherb.de (Link zu diesem Artikel)
Dieser Artikel wird hier nicht mehr aktualisiert.

 

Hier auf einem RasPi ausgeführt.

Mein(e) Client(s) läuft(laufen) derzeit auf Windoof. Wenn ich einen Linux-Client am Laufen habe, melde ich mich in einem anderen Beitrag.

Ziel

OpenVPN-Server und -Clientkonfiguration für einen

Server-Multi-Client Tunnel mit Bridging

Die Bridge

Jedes System, ob lokal oder über VPN, ist in einem überbrückten Netzwerk als gleichwertig zu betrachten. Das kann die klassische OpenVPN-Konfiguration mittels tun-Device nicht. Siehe nächstes Kapitel.

Tun und Tap

Die meisten Veröffentlichungen beziehen sich auf einen OpenVPN-Tunnel, bei dem mittels Tun-Device ein Client bzw. mehrere Clients für normale, z.B. Office-Bedingungen, Zugriff auf’s lokale Netz haben. (Zugang über OpenVPN als NAT-Router.) Es gibt aber auch Ethernet-Pakete, die sich hiermit nicht übertragen lassen. Ich möchte für mich und in diesem Beitrag aber eine vollwertige Brücke konfigurieren.

Angeblich sei die OpenVPN-Bridge schwieriger oder aufwändiger im Server zu implementieren, als der gewöhnliche Tunnel mit dem tun-Device. Das ist absoluter Quatsch! Erstens ist beides gleich einfach und mittelmäßig aufwändig. Und zweitens, falls es nicht auf Anhieb funktioniert, beides gleichermaßen schwierig! 😉

Immer ist es sinnvoll, wenn man versteht, was man tut. Aus diesem Grund ein paar einführende Links:

Ich habe jetzt hin und her überlegt, ob ich es übersetze oder nur verlinke: Diese Seite ist jedoch auch im Englischen sehr gut lesbar. Ich spare mir deshalb die Übersetzung: https://www.grc.com/vpn/routing.htm

Auch diese Seite liegt mir als Einführung am Herzen: http://www.heise.de/netze/artikel/Bridge-Modus-224072.html

Und die offizielle Bridging-Seite von openvpn.net: https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Vorab auch schon mal einen Link auf die Man-Page zu /etc/network/interfaces. Hier ist u.a. erklärt, was Direktiven wie „pre-up“ und „post-down“ bedeuten.

Vielleicht sind auch noch eine Menge anderer Links notwendig. Je nach dem Vorbildungs-Stand, wenn man an diese Aufgabe geht.

OpenVPN wird oft als simpel dargestellt. Ist es auch. So lange, bis es doch nicht funktioniert. Und in diesem Fall möchte ich ermutigen: Nicht aufgeben, nicht wild rumprobieren, sondern systematisch nach der möglichen Fehlerquelle suchen.

… und bei den Tests mit dem Client: den Client IMMER von außen auf das lokale Netz zugreifen lassen. Starte ich ihn innerhalb des lokalen Netzes, wird es Mist. Die Pakete gehen dann an der OpenVPN-Verbindung vorbei.

Ich verwende dazu ein Gerät, dass mir UMTS auf WLAN umsetzt. Sprich: …mir auch zu Hause (bei meinen Tests) ein WLAN aufspannt, über das ich faktisch von außen so auf das Heimnetzwerk zugreife, als wäre ich im Himalaja unterwegs.

Und wenn man doch den Kanal voll hat: Die gängigen NAS, z.B. von Synology, können auch ein OpenVPN-Server sein. Allerdings nicht als vollwertige Bridge. Aber: Ich habe die letzten 3 Jahre mit dieser Lösung recht gut gelebt. Und neben dem NAS muss man am Router nur noch den zugehörigen Port frei geben.

Start: Schlüssel und Zertifikate

OpenVPN beruht auf SSL. Ein Verschlüsselungssystem, das mit privaten und öffentlichen Schlüsseln hantiert und die Zertifizierung dieser Schlüssel organisiert.

An dieser Stelle mag ich darauf nicht im Detail eingehen. Es würde nicht nur diesen Beitrag inhaltlich übersteigen, sondern mich dazu zwingen Dinge wiederzugeben, die ich nur zu 90% verstanden habe. Nur so viel: Es gibt immer einen privaten Schlüssel, der nicht aus der Hand gegeben wird. Dazu gehört ein öffentlicher Schlüssel mit dem ein Externer dechiffrieren und chiffrieren kann. Und es gibt eine Zertifikats-Stelle, die (mutmaßlich) Auskunft darüber gibt, ob der, der einen öffentlichen Schlüssel anpreist, auch tatsächlich der ist, mit dem man glaubt, zu kommunizieren. Bei einem OpenVPN-Tunnel macht es keinen Sinn, dass das Zertifikat bei einer offiziellen, vertrauenswürdigen Stelle liegt, denn wir wollen ja gerade nicht, dass jeder den Tunnel verwenden kann, sondern nur der, für den wir den Tunnel extra einrichten.

XCA statt EasyRSA?

Es gibt im Netz zahlreiche, nahezu identische und ausführliche Beschreibungen zum Thema OpenVPN-Installation und -Einrichtung. Zu unterschiedlichsten Plattformen. Üblich ist, EasyRSA als Kommandozeilentool zur Erstellung der Schlüssel und Zertifikate zu verwenden. Macht man das aber für unterschiedliche Systeme und auch noch selten, kann man sehr schnell die Übersicht verlieren, notiert man sich alles nicht sehr akribisch.

Aus diesem Grund möchte ich hier XCA verwenden. Zur kurzen Einführen lies z.B. hier.

Die offizielle Projektseite ist http://xca.sourceforge.net

Der Download für Windows, Linux und Mac ist hier möglich.

Eine sehr schönes Manual hat Augenoptiker-Meister Christian Berndt online gestellt. Ausgehend von dieser Doku leite ich hier meine Beschreibung ab.

Schlüssel und Zertifikate mit XCA erstellen

Um OpenVPN betreiben zu können, benötigen wir prinzipiell folgende Schlüssel und Zertifikate:

  • Schlüsselpaar/Zertifikat für die Certificate Authority (CA) auf dem VPN-Server
    • privaten Schlüssel erstellen (netname-vpn-ca-key.pem)
    • Zertifikat (netname-vpn-ca-cert.pem)
  • Schlüsselpaar/Zertifikat für den VPN-Server
    • privaten Schlüssel erstellen (netname-vpn-server-key.pem)
    • Zertifikat (netname-vpn-server-cert.pem)
  • Schlüsselpaar/Zertifikat für Client (jeweils für jeden Client)
    • privaten Schlüssel erstellen (netname-vpn-clientname-key.pem)
    • Zertifikat (netname-vpn-clientname-cert.pem)
  • Diffie-Hellmann Parameter erzeugen (dh2048.pem)

Die relativ langen Filenamen wähle ich, um die Dateien für andere Dienste und Netze am Namen auseinander halten zu können. Für netname setze ich eine Bezeichnung ein, die klar mein Home-Netzwerk bezeichnet. Die Personen zugeordneten Client-Zertifikate und -Schlüssel bekommen den Benutzernamen hier im Dateinamen unter name. Es kann genau so Sinn machen, statt dessen Gerätenamen hier zu verwenden, wenn nicht ein Zertifikat pro Nutzer, sondern ein Zertifikat pro Gerät erzeugt werden soll, was eigentlich näher an der Schlüsselverwendung bei OpenVPN dran ist.

Das alles also nur wegen der Übersichtlichkeit. Man kann die Bezeichnungen letztlich wählen, wie man will. Auf Sonderzeichen sollte man jedoch besser verzichten.

Ablauf mit XCA

Zuerst eine Datenbank erstellen (nachfolgend zur besseren Darstellung die Bilder jeweils anklicken):

XCA-1

Auf die Angabe eines Passwortes habe ich verzichtet, da ich meine Passwörter hin und wieder ändere und damit Alte auch vergesse. Statt dessen speichere ich die Datenbank auf einem Stick, der im Schrank aufbewahrt wird.

Als nächstes erstelle ich Vorlagen:

  • Für meine CA

XCA-2

Die Seite Inhaber fülle ich soweit aus (commonName bekommt nur einen auffälligen Platzhalter; Korrektur: Kann man weg lassen, da er bei Anwendung des Templates gar nicht vor-eingetragen wird.):

XCA-3

Damit alles eindeutig wird, verwende ich als internen Namen den Namen, den ich auch als Dateinamen verwenden werde.

Im Reiter Erweiterungen kann man die Gültigkeit anpassen. Ich lasse es hier auf 10 Jahre stehen.

XCA-4

Mit Ok abschließen.

XCA-5

  • Vorlage für meinen OpenVPN-Server

Hier die Vorlagen-Vorlage „HTTPS_server“ auswählen.

XCA-6

XCA-7

Ich möchte mir den Aufwand nicht jedes Jahr auferlegen und wähle auch hier bequeme 10 Jahre (das ist nicht die Voreinstellung!):

XCA-8

Ok.
(Die 10 Jahre werden an-gemeckert, weil sie rein rechnerisch nach dem vorher erstellten CA-Zertifikat liegen, denn das ist ja nun schon einige Minuten alt, also keine vollen 10 Jahre mehr. Einfach wegklickern und trotzdem erstellen lassen.):

XCA-9

  • Vorlage für die VPN-Clients

Die Vorlagen-Vorlage „HTTPS_client“ benutzen:

XCA-10

XCA-11

Auch hier wieder die Laufzeit anpassen.

Mit Ok abschließen. Jetzt sieht es so aus:

XCA-12

Jetzt werden die Zertifikate und Schlüssel für den Server angelegt:

  • CA-Zertifikat und Schlüssel

Auf den dritten Reiter „Zertifikate“ gehen und „Neues Zertifikat“ anklicken.

Signatur algorithmus „MD 5“ und das vorhin angelegte CA-Template auswählen:

XCA-13

Jetzt den Button „Alles übernehmen“ drücken (nicht OK!). Damit wird das Template geladen.

Auf die Registerkarte „Inhaber“ gehen. Den internen Namen setze ich zusammen mit dem eindeutigen „commonName“ auf den Namen, den ich der Datei auch geben werde:

XCA-14

Jetzt den Button „Erstelle einen neuen Schlüssel“ anklicken. Den Namen passe ich an meinen oben selbst gewählten Dateinamen an, RSA bleibt gewählt und die Schlüssellänge ändere ich auf die inzwischen empfohlene Länge von 2048 Bit:

XCA-15

Der Schlüssel wurde erfolgreich erstellt. Jetzt noch mit OK die Erstellung dieses Zertifikates abschließen.

XCA-16

  • VPN-Server-Zertifikat und Schlüssel

Wieder „Neues Zertifikat“ anklicken. Hier sind jetzt 3 Dinge einzutragen: „Unterschreiben“ wird auf „Verwende dieses Zertifikat zum Unterschreiben“ gesetzt und das CA-Zertifikat ausgewählt. Weiterhin wird der Algorithmus wieder auf „MD 5“ gestellt und jetzt die Vorlage für den VPN-Server ausgewählt UND AUF „Alles übernehmen“ klicken.

XCA-17

Jetzt zum Reiter „Inhaber“ wechseln. Auch hier setze ich „Interner Name“ und „commonName“ auf die vorgesehene Dateibezeichnung des Zertifikates:

XCA-18

Auf die gleiche Art und Weise, wie für den CA-Schlüssel erzeuge ich jetzt den Schlüssel für den VPN-Server per Druck auf „Erstelle einen neuen Schlüssel“ und durch Anpassen der Voreinstellungen:

XCA-19

Schlüssel erstellen und das Erstellen des Zertifikates mit OK abschließen.

Unser Server-Zertifikat erscheint logisch eingeordnet „unter“ dem CA-Zertifikat:

XCA-20

Jetzt werden die Zertifikate und Schlüssel für alle Clients angelegt:

Ich verwende in diesem Beispiel den Nutzer-Anmeldenamen „meier“ zur Kennzeichnung, für wen das Zertifikat ist.

Unter dem Reiter „Zertifikate“ den Button „Neues Zertifikat“ anklicken. Unter „Unterschreiben“ ist „Verwende dieses Zertifikat zum Unterschreiben“ auszuwählen und das CA-Zertifikat des VPN-Servers auszuwählen. Algorithmus auch hier auf „MD 5“ stellen. Die Vorlage für die Client-Zertifikate wählen und auf „Alles übernehmen“ klicken. (NICHT auf Ok!):

XCA-21

Jetzt die Registerkarte „Inhaber“ ausfüllen. Als „Interner Name“ wie auch als „commonName“ wähle ich die oben vorgeschlagene Schreibweise für die Files. Außerdem lege ich ein zusätzliches Feld vom Typ „name“ an, dass ich mit dem Klarnamen des Nutzers fülle, um mich später besser in den Zertifikaten und Schlüsseln zurechtzufinden:

XCA-22

Jetzt auf „Erstelle einen neuen Schlüssel“ klicken und ausfüllen: Ich ändere die Bezeichnung fherbHome-vpn-meier-cert in fherbHome-vpn-meier-key, wie ich das weiter oben für mich definiert habe. Die Schlüssellänge mit 2048 Bit wählen:

XCA-23

„Erstellen“ drücken. Und danach das Erstellen des Zertifikates mit „OK“ abschließen.

Wir haben jetzt 3 Zertifikate und Schlüssel (plus weitere, wenn wir mehr VPN-Nutzer vorgesehen hätten):

XCA-24

Jetzt werden die Zertifikate und Schlüssel für Server und alle Clients exportiert:

Dazu das Server oder Client-Zertifikat mit der Maus anwählen, welches man exportieren möchte. Letztlich muss für den Server und alle Clients der Export-Prozess mehrmals nacheinander durchlaufen werden, wie ich ihn hier nur für den Server zeige:

Ich klicke das Zertifikat fherbHome-vpn-server-cert an und klicke danach auf „Export“. Als Exportformat wird „PKCS #12 with Certificate chain“ ausgewählt:

XCA-25

(Die Export-Dateien liegen nach dem Export standardmäßig im Programmordner von XCA, wenn man, wie ich hier versehentlich, beim Export den Pfad vergisst anzupassen.)

Jetzt OK drücken. Beim Server muss grundsätzlich auf ein Passwort verzichtet werden, damit er automatisch anlaufen kann. Bei den Clients habe ich mich entschieden, auch kein Passwort für die Zertifikats-Datei zu verwenden. Der Nutzer soll sich bei der Verbindungsaufnahme mit OpenVPN anmelden (Benutzername/Passwort). Das soll für mich als Sicherheit reichen.

Da wir „PKCS #12“ als Exportformat gewählt haben, ist dann in der OpenVPN-Konfiguration die Datei in folgender Form einzubinden:

pkcs12 "/<vollständigerPfad>/fherbHome-vpn-server-cert.p12"

(als eine Zeile natürlich!)

Den Diffie-Hellmann Parameter als Datei erstellen kann man mit XCA nicht. Dazu und zu allen weiteren Aufgaben wechseln wir jetzt auf den zukünftigen VPN-Server (Linux). Die Zertifikatsdatei für den Server lege ich, wie die Datenbank  auch, auf einen Stick. Den kann ich später am RasPi anstecken und dort die fherbHome-vpn-server-cert.p12 herunter kopieren.

Kommentar zum Abschluss

XCA zeigt gegenüber EasyRSA in seiner Hierarchie schon ein wenig besser, wie die Schlüssel und Zertifikate hierarchisch zusammen gehören.

Wir haben jetzt alle Vorarbeiten geleistet, um Server und Client aufzusetzen. Alles was jetzt kommt, verwendet die Schlüssel und Zertifikate, bearbeitet sie aber nicht weiter.

OpenVPN-Server installieren und konfigurieren

Ausgangssituation

Ich gehe hier von einem RasPi aus, auf dem nichts außer der grundlegenden Betriebssystemkonfiguration drauf ist. So, wie hier gezeigt. Das bedeutet aber auch, dass die Firewall (iptables) komplett offen ist. Zu dem Thema Linux-Firewall werde ich bestimmt einen weiteren Beitrag veröffentlichen. Die recht weltoffene Ausgangssituation hat insbesondere ihre Daseinsberechtigung, dass wir unseren kleinen RasPi-Server zu Hause gewöhnlich hinter einem Router mit eingebauter Firewall betreiben. Wir benötigen also hierfür gar keine Firewall auf dem Linux-System selbst, solange wir nicht weitere Dienste darauf installieren, die einen besonderen Schutz erfordern. Für den Betrieb von OpenVPN reicht es aus, auf dem separaten Router das spezielle OpenVPN-Port an den RasPi durchzuleiten und sonst nichts.

Installationen

Auf Systemen, wo openssl noch nicht installiert ist, muss das jetzt erfolgen. Bei RasPi ist die Software bereits vorhanden, da sie für den Headless-Zugang per SSL-Client bereits konfiguriert ist.

Die Installation von OpenVPN erfolgt mit

apt-get install openvpn

Die Installation startet den Server bereits. Wir stoppen ihn mit

service openvpn stop

Für die Bridge-Konfiguration wird ebenfalls benötigt:

apt-get install bridge-utils

Egal, ob wie tun oder tap als Zugang verwenden, funktioniert dies nur, wenn der entsprechende TUN-Treiber (der Beides kann) auch geladen ist. Derzeit ist er beim RasPi im Kernel mit enthalten.

Für die Bridge-Funktionalität werden wir das TAP-Interface verwenden.

Zertifikate/Schlüssel zufügen

Die notwendigen Zertifikate des Servers lege ich mit in den Konfigurationspfad von OpenVPN. Dazu gehe ich auf den angeschlossenen USB-Stick in den Ordner mit der XCA-Export-Datei *.p12, die ich vorher unter Windows angelegt habe. In meinem Fall landet mit

cp fherbHome-vpn-server-cert.p12 /etc/openvpn/

das File im Konfigurationsordner von OpenVPN.

Diffie-Hellmann Parameter als Datei erstellen

Für unsere Zertifikats-Schlüsselorgie fehlt uns noch die Datei mit dem sogenannten Diffie-Hellmann Parameter.

Wir haben vorhin die Schlüssel mit 2048 Bit Länge angelegt.
— Klar: Weil wir paranoid sind. Aber die Mitarbeiter der „Behörden“ sind nicht nur paranoid, die sind in manchen Ländern auch gut finanziert. —

Die DH-Datei muss also auch entsprechend mit dem Parameter 2048 erstellt werden:

openssl dhparam -out dh2048.pem 2048

Das dauert ein Weilchen. Beim RasPi dauertes das in einem Fall rund 20 Minuten, in einem anderen eine Dreiviertelstunde! Siehe nächste Überschrift

Dann auch diese Datei mit in unseren Konfigurationsordner legen:

mv dh2048.pem /etc/openvpn/
Kaffeepause!

Jetzt erst mal Kaffee kochen, dann weiter lesen.

IP-Forwarding einschalten

Damit der RasPi empfangene Daten der Clients auch ins Internet weiter leitet, muss das IP-Forwarding dauerhaft freigeschaltet werden. Dazu das File

nano /etc/sysctl.conf

öffnen und dort das IP-Forwarding auf 1 setzen (das heißt, # entfernen):

net.ipv4.ip_forward = 1

Das Neueinlesen können wir uns sparen, da wir später den RasPi komplett rebooten werden.

Bridge einrichten

Hier führen in den Dokus im Netz viele Wege nach Rom. ich entscheide mich für eine statische Konfiguration in /etc/network/interfaces

Ziel ist eine Brücke zu erstellen, in die sofort die Ethernetschnittstelle eingebunden wird, das Tap-Device mittels openvpn erzeugt wird und dieses dann ebenfalls der Brücke zugewiesen wird. Das kann man auch über extra Scripte erreichen. Aber warum Scripte schreiben und aufrufen, wenn man schon hier die Kommandos eintragen kann.

Hier also erfolgt jetzt nur die Konfiguration der Ethernetschnittstelle und der Bridge:

nano /etc/network/interfaces
auto lo br0
iface lo inet loopback

iface eth0 inet manual

iface br0 inet dhcp
 bridge_ports eth0
 post-up ip link set br0 address 28:2B:1b:e1:55:2F
 pre-up openvpn --mktun --dev tap0
 post-up brctl addif br0 tap0
 pre-down brctl delif br0 tap0
 post-down openvpn --rmtun --dev tap0

Erklärung:

Der RasPi verbindet sich in diesem Fall per DHCP über die Ethernetschnittstelle mit unserem Netzwerk.

Zu beachten ist, dass die Bridge unbedingt der Auto-Startfunktion zugefügt wird:

auto lo br0

Danach komm erst mal die übliche Loop-Back-Schnittstelle:

iface lo inet loopback

Die Ethernetschnittstelle (eth0) muss auf „manual“ gestellt werden und darf nicht weiter konfiguriert werden:

iface eth0 inet manual

Die Zeile

iface br0 inet dhcp

erstellt die Brücke und stellt die Konfiguration auf DHCP. Man kann die Konfiguration auch mit der Hand übernehmen. Diese Variante zeige ich unten. Die Zeile

bridge_ports eth0

fügt nun die Ethernetschnittstelle eth0 der Bridge zu. Mit „post-up“ werden Anweisungen ausgeführt, die unmittelbar nach dem Erstellen der Bridge ausgeführt werden. Die Zeile

post-up ip link set br0 address 28:2B:1b:e1:55:2F

legt die MAC-Adresse fest, mit der sich die Brücke in unserem Netz meldet. Lässt man dies weg, bekommt die Brücke irgendeine MAC-Adresse. Manchmal (!) die der Ethernetschnittstelle eth0. Aber nicht immer. Haben wir auf unserem Router die MAC-Filterung nicht eingeschaltet, kann uns die MAC auch egal sein. Meist schaltet man die Filterung aber auf dem Router ein, damit sich im WLAN des Routers nur Geräte anmelden dürfen, die man explizit mittels ihrer MAC-Adresse im Router eingetragen hat. Dies ist eher der Standard, also ist auch die Angabe einer festen MAC für unsere Brücke eher der Standard. Leider habe ich im Netz nicht eine einzige Doku zur OpenVPN-Bridge gesehen, wo dies gemacht wird und bin lange davon ausgegangen, dass immer die MAC von eth0 verwendet wird, weil sich der RasPi ja letztlich mit diesem Netzwerkchip am Netz anmeldet. Vielleicht ist diese Sache auch distributionsabhängig.

Diese MAC (gern auch eine Andere als oben dargestellt verwenden; aber keine, die bereits ein Gerät im Netz besitzt!) also im Router in die Liste der MAC-Filterung jetzt mit eintragen. Sonst kommt uns der RasPi beim nächsten Reboot im Netz abhanden.

Die Zeile

pre-up openvpn --mktun --dev tap0

lädt uns vor Aktivierung der Bridge OpenVPN mit dem Aufruf, sein Tap-Device zu erstellen.

Die Zeile

post-up brctl addif br0 tap0

fügt uns dann nach Aktivierung der Bridge dieses Device der Bridge zu.

Und die Zeilen

 pre-down brctl delif br0 tap0
 post-down openvpn --rmtun --dev tap0

entfernen uns auf entgegengesetztem Wege dieses Device, wenn das Netzwerk heruntergefahren wird.

Alternativ ohne DHCP:

So würde die /etc/network/interfaces in der gleichen Konfiguration aussehen, wenn wir nicht DHCP verwenden, sondern die Daten fest eintragen:

auto lo br0
iface lo inet loopback

iface eth0 inet manual

iface br0 inet static
 address 192.168.1.105
 netmask 255.255.255.0
 network 192.168.1.0
 gateway 192.168.1.1
 broadcast 192.168.1.255
 bridge_ports eth0
 post-up ip link set br0 address 28:2B:1b:e1:55:2F
 pre-up openvpn --mktun --dev tap0 post-up brctl
 addif br0 tap0 pre-down brctl delif br0 tap0
 post-down openvpn --rmtun --dev tap0

Dabei ist

192.168.1.105 – Adresse des RasPi im lokalen Netz

255.255.255.0 – die Maske für dieses lokale Netz (bedeutet das alle Teilnehmer von 192.168.1.1 bis 192.168.1.254 zu diesem Netz gehören)

192.168.1.0 – Der fixe Teil der Adressen in diesem lokalen Netz, sprich: der Netzwerkname

192.168.1.255 – Adresse 255 in diesem Netz ist kein Netzteilnehmer, sondern alle Teilnehmer hören auch auf dieser Adresse nach Broadcast-Nachrichten

Konfigurationsdatei des Servers erstellen (zuerst ohne Bridge)

Eine Datei zur Konfiguration erstellen:

nano /etc/openvpn/openvpn.conf

 

port 5994
proto udp
dev tap0
ifconfig-pool-persist /etc/openvpn/ipp.txt
dh /etc/openvpn/dh2048.pem
pkcs12 "/etc/openvpn/fherbHome-vpn-server-cert.p12"
server-bridge 192.168.1.105 255.255.255.0 192.168.1.40 192.168.1.80
#push "redirect-gateway def1"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
#log /var/log/openvpn.log
verb 3
status /var/log/openvpn-status.log

Erklärung:

port 5994

ist mein Port, auf dem mein OpenVPN von einem Client Verbindung mit meinem Server aufnimmt. Der Standard-Port für OpenVPN ist eigentlich Port 1194. Es gab und gibt noch Provider, die eine OpenVPN-Verbindung für den Nutzer dadurch blockieren wollen, indem sie Port 1194 sperren. Da es hier keinen Nutzen bringt, unbedingt den Standard-Port zu verwenden, wähle ich gleich eine Alternative.

proto udp

legt das Protokoll auf UDP fest. (Alternativ: tcp) Ob nun UDP oder TCP ist nicht leicht zu sagen. Es wird geschrieben, dass UDP weniger auf DDoS-Attacken anfällig ist. Ob uns das hier bei unserem OpenVPN-Port passiert? TCP ist mir vom Protokoll her sympathischer, da es eine Absicherung enthält, dass alle Pakete ankommen. OpenVPN ist darauf aber nicht angewiesen. TCP hätte noch den Vorteil, dass es etwas „abartiger“ für OpenVPN ist und deshalb möglicherweise bei restriktiven Providern vielleicht eher nicht blockiert wird. (Solange die nur auf Port/Protokoll testen und nicht tiefer.)

dev tap0

spezifiziert das zu verwendende Device. In dem Fall unser oben erstelltes Tap-Device.

Unser OpenVPN-Server ist für die Clients der DHCP, der die IP-Adressen vergibt. In der Datei

ifconfig-pool-persist /etc/openvpn/ipp.txt

werden diese Adressen abgelegt, damit die Clients beim nächsten Verbinden wieder die gleiche IP-Adresse bekommen können.

dh /etc/openvpn/dh2048.pem
pkcs12 "/etc/openvpn/fherbHome-vpn-server-cert.p12"

Sind unsere beiden Dateien, die für die Verschlüsselung verwendet werden.

server-bridge 192.168.1.105 255.255.255.0 192.168.1.40 192.168.1.80

Sagt OpenVPN, dass es als Server mit Bridge arbeiten soll. Der Wert 192.168.1.105 gibt die eigene Adresse an, 255.255.255.0 ist die Subnet-Maske und 192.168.1.40 192.168.1.80 legt fest, dass der OpenVPN-Server in diesem Adressbereich den Clients eine Adresse zuweisen kann.

#push "redirect-gateway def1"

Der Server kann durch Weglassen von # dem Client sagen, dass dieser die vollständige Internetkommunikation über den Tunnel ausführen soll. Auskommentiert, wie hier, sendet der Client nur die Pakete des eigenen Subnetzes über OpenVPN. Man kann dies auch im Konfigurationsfile des Clients angeben. Steht diese Direktive hier, gilt sie für alle Clients.

Ob tatsächlich das def1 am Ende stehen muss, habe ich noch nicht herausgefunden. In Veröffentlichungen werden beide Varianten, mit und ohne def1 angegeben.

Steht

client-to-client

mit in der Konfiguration können sich auch die Clients, die über OpenVPN kommunizieren, untereinander Nachrichten schicken.

keepalive 10 120

konfiguriert die Lebenszeichenüberwachung zum Remote-System hin. Aller 10 Sekunden wird ein Ping gesendet und wenn 120s keine Antwort kommt, wird das als Verbindungsabbruch gewertet.

comp-lzo

Stellt das Komprimierungsverfahren für die Übertragung ein.

Was

persist-key
persist-tun

tun, habe ich zugegebenermaßen nicht verstanden. Ich kann es zwar in der Dokumentation übersetzen, aber das heißt nicht, es wirklich in seiner Wirkungsweise verstanden zu haben.

Bei Problemen können wir

#log /var/log/openvpn.log

einschalten und vielleicht nachvollziehen, woran es hängt.

verb 3

Es gibt verschiedene Stufen, wie „gesprächig“ OpenVPN im Logfile ist. 3 ist Standard. Bei Verbindungsproblemen sollte man den Wert auf 6 stellen.

Mittels

status /var/log/openvpn-status.log

schreibt OpenVPN jede Minute einen kurzen Statusbericht über die aktuelle Verbindungslage. Die Datei wird dabei überschrieben, wächst also nicht stetig im Gegensatz zu einem Logfile.

Auf der Serverseite sind wir in den Vorbereitungen erst einmal fertig (die Bridge richten wir später ein).

Jetzt neu booten:

reboot

In der Zwischenzeit können wir jetzt noch das verwendete Port 5994 auf dem Router zum VPN-Server durchlassen. In dieser Konfiguration über das UDP-Protokoll.

Hinweis: RasPi-eigene Firewall

Ich habe keine Firewall auf dem RasPi laufen, sprich keine iptables-Regeln definiert. Aus dem Grund brauche ich hier auch nichts tun. Läuft aber eine solche Firewall, wird vorgeschlagen, diese Einträge zu setzen:

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

Konfiguration des Clients

Ich verwende Windows als Client. Das Konfigurationsfile, wie auch das File mit den Schlüsseln muss dort im OpenVPN-Client-Programmordner unter

.../data/config

abgelegt werden.

Ehe wir es vergessen, kopieren wir das Schlüsselfile fherbHome-vpn-meier-cert.p12 (s. oben) dorthin.

Nun legen wir die Konfiguration im File openvpn.ovpn an:

client
dev tap
proto udp
remote [my-server-ip-address] 5994
resolv-retry infinite
nobind
persist-key
persist-tun
pkcs12 "fherbHome-vpn-meier-cert.p12"
comp-lzo
verb 3

Ich möchte jetzt hier nicht wieder jede Zeile auseinander nehmen. Eine Dokumentation findet sich hier.

Außer eine Erklärung zur Zeile

remote [my-server-ip-address] 5994

Für [my-server-ip-address] ist die IP-Adresse bzw. Domainnamen des Servers einzutragen.

Zu Hause gibt uns allerdings der Provider wechselnde Adressen. Wir benötigen also einen Dynamic DNS Dienst, wie z.B. den bekannten DynDNS.org. Will oder kann man den dazu notwendigen Update-Dienst nicht auf dem eigenen Router einrichten, kann man den auch gleich mit auf den RasPi packen, wo OpenVPN läuft. Wie es geht, habe ich hier erklärt.

Die MAC-Adresse des Clients

Noch eine Stolperfalle. Wir sind noch nicht ganz fertig.

Das gleiche Problem, wie ich es schon oben für die Hardwareadresse der Bridge beschrieben habe, tritt nun wieder auf, falls im Router die MAC-Adressfilterung aktiv ist. Dies ist, meiner Meinung nach der einzige Nachteil, den die Bridge gegenüber der Tap-Variante hat, wo der RasPi als NAT-Router auch den Datenpaketen des Clients dann im eigenen Netzwerk seine eigene Adresse spendiert. Hier, bei der Bridge, kommen die Pakete direkt vom Client und wir müssen natürlich auch dessen Adresse in die Router-Firewall eintragen.

Es handelt sich weder um die MAC des Ethernetadapters noch des WLAN-Adapters. Auf dem Client hat OpenVPN einen eigenen Adapter installiert. Unter Windows heißt dieser TAP-Win32 Adapter.

Dessen MAC müssen wir im Router eintragen.

Unter Windows kann man ihn über den Status unter Details anzeigen oder über die Kommandozeile cmd.exe:

ipconfig /all

ist dafür das richtige Kommando. Wir suchen in der Liste nun den Ethernet-Adapter LAN-Verbindung… bei dem unter „Beschreibung“ der Adapter „TAP-Win32 Adapter…“ genannt ist und lesen dort die Physikalische Adresse aus.

Dabei tritt ein Problem auf, wenn wir diesen Adapter versehentlich beim Beenden von OpenVPN deinstallieren lassen. OpenVPN fragt jedesmal danach, sodass es schnell passieren kann. Mit der neuen Anlage des Adapters wird dann eine neue MAC-Adresse erzeugt und wir kommen nicht mehr ins heimische Netz. Trifft man keine Vorkehrungen, hat man sich vielleicht für den Rest des Urlaubs ausgesperrt.

Hierzu habe ich zwei gut funktionierende Tricks:
1. Den OpenVPN-Client nicht mit Administratorrechten starten

Für den allerersten Start, bei dem der Netzwerkadapter installiert werden muss, muss man OpenVPN natürlich mit Administratorrechten starten. Und beim Beenden den Adapter nicht wieder löschen. Bei allen weiteren Aufrufen startet man OpenVPN nur als Benutzer.

Tippt man dann versehentlich beim Beenden auf das automatische Entfernen des Adapters, kann das OpenVPN nicht erledigen, weil ihm die Rechte dazu fehlen.

2. Unbedingt MAC-Adresse aufschreiben

Nach dem ersten Start des Clients (den man dabei mit Administrator-Rechten starten muss) wird der Adapter installiert und die MAC vergeben. Diese lese ich nun, wie oben beschrieben, aus, und trage sie als Kommentar in mein Konfigurationsfile auf dem Client ein.

Musste ich nun den Adapter doch zufällig oder absichtlich neu installieren, kann ich die alte Adresse nun wieder mit der Hand einsetzen. Dazu zum Abschluss noch folgende Bilderserie für die dazu erforderliche Vorgehensweise in Windows(7):

Mit der rechten Maustaste auf das Netzwerksymbol in der Taskleiste klicken. Und dann weiter, wie in folgenden Bildern.

mac-konfig-1 (1)
mac-konfig-2 (2)
mac-konfig-3 (3)
mac-konfig-4 (4)
mac-konfig-5 (5)
mac-konfig-6 (6)

Ich habe jetzt die Konfiguration testweise nach dieser Anleitung auf einem RasPi noch einmal völlig neu erstellt, um sicher zu sein dass funktioniert, was ich geschrieben habe. Das Image mit dem Kernel stammt vom Juni 2014. Ich hoffe, dass in Zukunft keine weiteren Stolpersteine dazu kommen.

Ein Gedanke zu „OpenVPN als Bridge aufsetzen“

  1. Noch einen 3. Trick:

    Ich werde OpenVPN noch in einer zweiten Instanz laufen lassen, die als NAT-Router mit dem tun-Device auf einem anderen Port arbeitet. Also die sonst gängige Variante. Dies wird ein eigener Artikel.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.