OpenVPN - mit sicheren Kommunikationswegen einen sicheren Zugang ins heimische Netzwerk herstellen
Datenschutz zum ersten (gegen Ausspähen), Schutz der eigenen Daten zum zweiten (gegen Manipulation), sichere Kommunikationswege zum dritten (gegen Abhören)... das ist hier in diesem Artikel mein Thema.
Inhaltsübersicht über die Kapitel dieses Artikels:
> Überblick - Was ist alles zur Einrichtung von OpenVPN notwendig ?
> Deb-Package für OpenVPN erstellen und installieren
> Ein paar Basics zu Protokollen, Verschlüsselung und Perfect Forward Secrecy
> Erstellen der Konfigurationsdateien, Keyfiles, Zertifikate und Service-Units
> Certificate Revocation List (CRL)
|
Kontinuierlich dem schon in meinen anderen Artikeln vorhandenen Security-Leitfaden folgend, befasst sich auch dieser Artikel wieder mit dem Thema Sicherheit, hier mit den beiden Aspekten Datenschutz und Schutz meiner Daten. Das sind tatsächlich zwei unterschiedliche Aspekte, der Datenschutz richtet sich gegen den unbemerkten, heimlichen und missbräuchlichen Zugriff durch Fremde, der Schutz meiner Daten richtet sich gegen unerlaubte Manipulation, Verlust oder Zerstörung. In diesem Artikel geht es um sichere Kommunikationswege. Im weiteren Sinne ist damit also ein Schutz gegen Zugriff auf meine Daten durch Fremde von außerhalb gemeint. Das betrifft sowohl meine Daten im heimischen LAN als auch die Daten meiner mobilen Aktivitäten, wenn ich auf Reisen Account- oder Zugangsdaten auf einer Web-Site eingeben soll/muss/will, um zum Beispiel unterwegs mal schnell einen Blick in mein Online-Postfach zu werfen. Speziell beim Letzteren geht es darum, das mögliche Belauschen der Verbindung und der Datenübertragungen durch Fremde vollständig zu unterbinden, wenn ich mich mit meinem Laptop an offenen WLAN-AccessPoints verbunden habe. Wir haben es hier also mit zwei unterschiedlichen Aspekten zu tun, die allerdings beide mit dem gleichen Werkzeug verfolgt und gelöst werden.... und zwar mit OpenVPN. In diesem Artikel befasse ich mich also mit OpenVPN und versuche Antworten auf die folgenden Fragen zu finden. Was ist OpenVPN? Was kann es für mich tun? Wann kann ich es nutzen? Wie richte ich es ein? Fangen wir mit der ersten Frage an.
Den Wortanteil "Open" im Namen des Paketes muss man wohl nicht erläutern... es ist halt ein Programm aus einer Open-Source-Community. Der Wort-Anteil "VPN" steht für "Virtual Private Network". OpenVPN ist also eine Netzwerk-Software, die zwischen zwei weit entfernt voneinander betriebenen Endgeräten (Computern) über das Internet eine Netzwerkverbindung als in sich geschlossene private End-to-End-Verbindung herstellen kann. Es handelt sich hierbei jedoch nicht um ein neues physikalisches Netzwerk, basierend auf Hardware und Kabeln, sondern um ein logisches, rein virtuelles Netzwerk. Allerdings bildet die vorhandene physische Infrastruktur wie z.B. PCs mit Netzwerk-Interface, Patchkabel und DSL-Router oder Mobilgeräte mit WLAN-Karten und natürlich auch das Internet die physische Grundlage, in der das virtuelle VPN eingebettet ist.
"In sich geschlossen" bedeutet, dass diese Datenverbindung aufgrund der in der Verbindung angewendeten Verschlüsselung von allem anderen im Internet vorhandenen Traffic unlesbar isoliert oder gekapselt ist. Umgangssprachlich wird hierbei von den Insidern oft von einem Tunnel gesprochen, mit dem i.ü.S. ein blickdichter Tunnel gemeint ist, der von dem einem Endgerät durchs gesamte weltweite Internet bis zum anderen Endgerät reicht. Blickdicht (ein vergleichender Begriff von mir) bedeutet, das alle Datenpakete, die durch diesen Tunnel transportiert werden, von niemand anderen abhörbar oder lesbar sind. Nach meiner Kenntnis sind entsprechend dem heutigen technischen Stand solcherart durch ein VPN geleitete Datenpakete nicht hackbar, die Verschlüsselung solcher auf dem Transportweg befindlicher Daten-Pakete ist auf absehbare Zeit nicht zu knacken. Das mag dann auch wohl der Grund dafür gewesen sein, dass Apple vom chinesischen Regime im Zeitraum Juli-August 2017 gezwungen wurde, weit über 600 VPN-Apps aus dem App-Store zu entfernen... ein tatsächlicher Sachverhalt, den man mit den entsprechenden Stichworten einfach im Web selber recherchieren und nachlesen kann. Dabei ist OpenVPN gar nichts subversives, es ist nichts aufrührerisches, nichts gefährliches.... es verhindert lediglich, dass meine Daten-Privatsphäre von mir fremden Menschen verletzt wird... es schützt meine digitale Privatsphäre, es schützt mein Recht auf die vollständige Verfügungshoheit meiner persönlichen Daten beim Transport durch das Internet.
Diese und die nächste Frage sind etwas komplizierter zu beantworten. Um die Sinnhaftigkeit und sogar Notwendigkeit von VPN-Software zu verstehen, muss man sich zuerst der real vorhandenen Gefahren bewusst sein, denen unsere privaten Daten permanent ausgesetzt sind. Und erst daraus resultiert die Erkenntnis, wie wertvoll OpenVPN für uns sein kann und bei welchen Gegebenheiten wir es verwenden sollten.
Um die Situation insgesamt etwas besser einschätzen zu können und um unsere Ausgangslage und die Rahmenbedingungen auch wirklich zu verstehen, schauen wir uns kurz das nebenstehende Bild an... ...und wir erkennen darin eine eigentlich völlig normale Situation... wir sitzen irgendwo auf der Welt in einem Café, in einer Strandbar, in einer Pension oder einem Hotel, oder sind irgendwo in einer City, oder in einem Park und freuen uns über das offene kostenlose WLAN. Unser Laptop ist also gerade mit irgendeinem 'freundlichen' AccessPoint via WLAN verbunden und wir können komfortabel unser Mailpostfach öffnen und auf neue Emails prüfen, oder unser Facebook-Konto auf neue Nachrichten prüfen, oder einfach nur frei Surfen im Web und vielleicht auch Postings in unseren abonnierten Online-Foren beantworten. |  |
Nun überlegen wir kurz, was uns zu solchen Situationen einfällt bzw. was wir dazu wissen ... und anschließend natürlich auch, was wir nicht wissen. Das, was wir wissen, ist einfach. Mir fallen dazu -wenn ich an mich und meinen Laptop denke- wirklich nur zwei Punkte ein:
Ich weiß, dass
1. mein Laptop 'sauber' ist und das ich keine bösen Absichten in diesem Gastnetz habe. Ich möchte das Gäste-WLAN einfach nur kurz für meine persönlichen Belange ins Internet nutzen.
2. mein Laptop nach der Anmeldung in ein fremdes Netzwerk integriert ist, was aus technischer Sicht faktisch gleich einzuschätzen ist, als wenn ich zuhause im LAN angeschlossen bin. Das ist insofern erwähnenswert, weil das Betriebssystem selber der Bewertung, ob das fremde Netzwerk ein freundliches Netz ist oder nicht, eher keine Bedeutung beimisst. Rein technisch betrachtet verbindet es sich mit einem "feindlich" gesinnten Netzwerk genauso schnell, wie zuhause im heimischen Netzwerk und es behandelt andere Clients in beiden Netzen gleich. Wenn mein Laptop zuhause einen SSH-Zugang oder einen Samba-Share anbietet, woher soll er wissen, dass er das in diesem fremden Netz nicht soll oder darf? Tja, er weiß es nicht.
Dem entgegen ist die Liste dessen, was ich nicht weiß, was aber trotzdem für mich von Bedeutung ist, etwas länger. Und wer jetzt denkt "was ich nicht weiß, macht mich nicht heiß" ... tja, der braucht hier auch nicht mehr weiterlesen.
Ich weiß nicht,
1. ob der Betreiber des Lokals (oder was auch immer diese Örtlichkeit darstellt) tatsächlich auch der Betreiber des WLAN-Access-Point ist
2. wer die Verantwortung für die Wartung und Pflege der WLAN- bzw. Netzwerk-Infrastruktur innehat
3. wer neben dem Betreiber außerdem auch (kontrolliert oder offen und unkontrolliert) Zugang zu dieser exponierten IT-Hardware hat
4. ob dieser AP von einem sachkundigen Administrator eingerichtet wurde oder ob der Koch nur einfach WLAN an seinem Router freigegeben hat
5. ob dieser AP resp. dessen Hardware durch fahrlässigen früheren Umgang nicht vielleicht schon kompromittiert ist
6. ob dieser AP über eine Firewall verfügt oder eingerichtet hat, die gegen das Internet wirkt
7. welche Absichten der Betreiber dieses AP überhaupt verfolgt, ob er integer sind oder eher als dubios einzuschätzen ist. Vielleicht geht's ihm ja auch nur darum, bei dem vielleicht hohen Durchsatz an Reisenden und Tourismus-Gästen gewisse Account-Daten abzugreifen um damit nebenher Geld zu verdienen
8. welchen lokalen staatlichen Bestimmungen ein WLAN-Betreiber vielleicht zwangsweise folgen muss, z.B. durch Anti-Terror-Gesetze, Gesetze zur Telekommunikationsüberwachung, etc.
9. welchen "Charakter" der AP überhaupt hat und ob er wirklich der ist, der er zu sein vorgibt (Stichwort Evil Twin)... ein Umstand, der für uns überhaupt nicht zu erkennen ist. Wenn ein Strandcafé beispielsweise das WLAN mit der SSID beach_cafe_mary anbietet, so ist es für uns unmöglich zu erkennen, dass die SSID beach_cafe_mary2 mit vielleicht besserer Leistung gar nicht zu diesem Café gehört, sondern ein Evil Twin ist. Dem Chef des Cafés wird das gar nicht auffallen, weil der bei der Bewirtung seiner Gäste wichtigeres zu tun hat, als ständig sein WLAN zu beobachten. Mit der SSID beach_cafe_mary2 melden wir uns aber in ein Netzwerk an, was uns gegenüber unzweifelhaft feindselig eingestellt ist ... eben weil es nicht von diesem Café betrieben wird und weil es keine andere Rechtfertigung dafür gibt, sich als jemand anderes auszugeben. Vielleicht hat das keine Konsequenzen für uns, aber dann nur deshalb nicht, weil wir als unbescholtene Urlauber einfach zu unwichtig sind. Aber vielleicht hat sich auch jetzt jemand Zugang zu unserem Laptop verschafft oder einfach nur unsere Anmeldedaten abgehört.
Es gibt also wirklich gute Gründe, sich vor der Anmeldung an fremden WLAN-Access-Points ein paar Gedanken über die Sicherheit seines Laptops zu machen. An dieser Stelle verweise ich deshalb natürlich auch noch mal auf meinen Artikel zu Sicherheit durch Firewall, in dem ich einen Paketfilter für solche Situationen beschrieben habe ... nun ja, das nur mal am Rande, denn hier soll es ja primär um OpenVPN gehen.
Die oben beschriebene Situation mit der WLAN-Verbindung an einem offenen/freien AccessPoint ist also offensichtlich etwas ganz normales, was völlig alltägliches ... nur leider eben durchaus auch mit ein paar Risiken behaftet. Das ganze erhält aber noch eine zusätzliche Dimension an Risiken, wenn ein Anwender darüber hinausgehend auch noch vorhat, sich von unterwegs mit seinem heimischen Netzwerk zu verbinden, um damit von jedem Ort auf der Welt einen Zugriff auf die Daten seines Servers zuhause zu bekommen. Das ist beispielsweise eine immer häufiger auftretende Frage in "meinen" Onlineforen, wenn Linux-Beginner nach Möglichkeiten fragen, um von außerhalb einen Zugriff auf die Hausautomatisierung zu bekommen, auf Überwachungskameras, auf die vom Server vorgehaltenen Daten.
Technisch ist das wirklich kein großes Problem. Das ist alles ganz fix gemacht. Wir öffnen einfach die benötigten Türen in der Firewall unseres DSL-Routers und schon steht uns von überall auf der Welt das ganze private Netzwerk zur Verfügung.
Ein SSH-Zugang mit leicht zu merkendem Password, ein Web-Server, der sich sofort mit "Hallo, hereinspaziert" meldet, ein lokaler Mailserver, mit dem man sich auf Reisen problemlos mit Thunderbird oder einem Smartphone-Client verbinden kann, die Home-Automatisierung, bei der man sich mit "1234" als Password authentifiziert ... alles kein Problem.... das geht alles ganz fix einzurichten. Man installiert die entsprechenden Dienste auf dem Server, passt die Einstellungen an, öffnet zudem die Ports im DSL-Router mit passender Weiterleitung und schon läuft alles wunderbar.
Wäre das nicht schön, wenn's dabei bleiben würde? Aber leider befindet sich genau hier das Problem... denn es bleibt nämlich nicht allein dabei. Die Wirklichkeit sieht leider ein wenig anders aus. |  |
Sobald wir einzelne Türen in unser Netzwerk herein öffnen, besteht ab diesem Moment ununterbrochen die äußerst signifikante Gefahr, dass sich durch diese Tür auch Fremde einschleichen wollen, und das heimlich einbrechend, unberechtigt, mit unbekannten Absichten. Und genau darin besteht meine größte Herausforderung: wie schaffe ich es, dass die von mir geöffneten Türen nicht unberechtigt auch von Fremden durchschritten werden? Wie verhinderte ich effektiv, dass Fremde sich illegalen Zugriff auf mein Heimnetzwerk verschaffen und mich belauschen, oder meine Daten stehlen, oder schlimmstenfalls sogar alle meine Daten zerstören? Tja... ich habe für unser Netzwerk meine Antwort auf diese Frage gefunden... die auch relativ einfach ist, aber auch radikal und endgültig. Ich vermeide heute einfach konsequent Türen zu öffnen, deren Sicherheit ich nicht selber absolut unzweifelhaft in der Hand habe. Und ich vermeide verschiedene Türen (also mehr als nur eine) für verschiedene Dienste öffnen zu müssen.
Genau für diese Zielsetzung eines wirklich kontrollierten Zugangs in mein Heimnetzwerk ist OpenVPN ein perfekte Lösung, weil ich für OpenVPN erfreulicherweise nur eine einzige Tür öffnen muss, die mir aber trotzdem den vollständigen Zugang auf alle Ressourcen ermöglicht und deren Passage nur mit Vorlage "meines Personalausweises" erlaubt ist ... man verzeihe mir den Vergleich mit dem Personalausweis, aber das ist eben für uns Laien die beste sinngemäße Übertragung für das Zertifikat zur Authentifizierung und dem Keyfile für die Ver-/Entschlüsselung ... mir fiel wirklich nichts besseres ein. Unbestritten ist, ohne diesen "Ausweis" (das Zertifikat) wird der Zugang ins Netzwerk verwehrt. Das bedeutet allerdings auch, dieses Zertifikat und das Keyfile sind als zwei äußerst sensible Dateien zu behandeln, die man wirklich zuverlässig geschützt vor unberechtigtem Zugriff aufbewahren muss. Die notwendige sichere Aufbewahrung habe ich auf meinen Laptop durch einem grundsätzlich unzugänglichen LUKS-Container realisiert, in dem die beiden Files gespeichert sind. Der Container wird on-the-fly erst dann geöffnet, wenn ich einen bestimmten USB-Stick ins Gerät einstecke. Sobald ich den Stick wieder abziehe, ist der Container wieder gesichert und kann nicht mehr eingesehen werden.
Die Vorgehensweise bis zur sicheren Verbindung ist also eigentlich ganz einfach:
1. Ein restriktiver Paketfilter ist aktiv
2. Netzwerk-Verbindung zum AccessPoint wird hergestellt
3. Bevor eine Anwendung gestartet wird, die das Netzwerk nutzt, wird der OpenVPN-Client gestartet
4. Nach erfolgreicher VPN-Verbindung starte ich auf dem Laptop die jetzt von mir gewünschten Programme oder Dienste
Mit OpenVPN habe ich also eine Möglichkeit gefunden, trotz aller vorhandenen Gefahren auf absolut sichere Weise sämtliche in meinem heimischen LAN verfügbaren Ressourcen auch von außerhalb erreichen und nutzen zu können, wie den Samba-Server, oder den Mailserver. Ich kann meine auf dem Server gespeicherten Kontakte mit dem Smartphone synchronisieren, meine Web-Cams öffnen und Haus und Hof kontrollieren, oder einfach auf abhörsichere Art und Weise über meinen Router zuhause im Internet surfen.... und das alles ganz (un)bequem auf dem oben gezeichneten Stuhl im Café sitzend, mit meinem Laptop auf dem Tisch, verbunden mit einem potentiell unsicheren fremden und unbekannten Netzwerk. OpenVPN kann damit vielleicht sogar die Installation eines eigenen Web-Servers und installierter Cloud-Software unnötig machen ... eine Idee, auf die man möglicherweise kommt, weil man drüber gelesen hat und weil man glaubt, nur damit können die Kontakte und Termine vom Handy mit dem Server synchronisiert werden. Dabei geht das auch wirklich prima ohne solch schweren Geschütze, deren Sicherheit ich aufgrund der wirklich hohen technischen Anforderungen als Laie vielleicht kaum gewährleisten kann. Dieses Problem löst radicale perfekt, welches genau für den Zweck der Synchronisation mehrerer Smartphones mit mehreren Adressbüchern und Kalendern ein tolles Werkzeug ist.
Der wirklich augenfällige Vorteil von OpenVPN ist, ich muss gar nicht eine für jeden Service meines LAN-Servers passende Tür öffnen, um über das Internet Zugang zu diesen Service zu bekommen, ich integriere mich mit OpenVPN einfach in das heimische Netzwerk und kann dann alle Dienste so nutzen, so als wäre ich mit meinem Laptop zuhause im Netz angemeldet. Schauen wir auf das nebenstehende Bild, um noch besser die Funktionsweise von OpenVPN zu verstehen. Ich melde meinen Laptop zunächst mal ganz normal bei diesem AccessPoint über einen Netzwerkmanager an. Bis zu diesem Moment sind noch keinerlei private Daten geflossen... es wird nur rein technisch eine Funkverbindung zwischen zwei Geräten hergestellt und ein Netzwerk etabliert. Das bedeutet, der Laptop bekommt eine IP-Adresse vom Router des APs aus dessen Netz zugewiesen. Ab diesem Moment ist mein Laptop aber auch in diesem Netzwerk resp. für den Admin dieses Netzes sichtbar, genau so wie ich meinen Laptop oder die anderen Geräte zuhause im Netz sehe, wenn ich das mit meinem PC kontrolliere oder überwache. Ich wiederhole das noch mal kurz... an diesem Punkt ist eine restriktiver Paketfilter eine wichtige Empfehlung.
|  |
Und nun starte ich auf dem Laptop den VPN-Client, der dann automatisch eine Verbindung zu meinem VPN-Server zuhause aufbaut und damit den schon erwähnten sicheren Tunnel zwischen diesen beiden Geräten etabliert. Nach erfolgreicher Verbindung bin ich ab jetzt nicht nur ein Mitglied meines Netzwerkes zuhause und alle dessen Ressourcen stehen mir zur Verfügung, es ist auch noch der direkte Zugang vom Laptop über den AccessPoint zum normalen Internet blockiert. Das bedeutet, wenn ich jetzt mit dem Browser im Internet surfe, geht der vollständige Traffic nicht mehr über den AccessPoint ins Internet, sondern erst durch den Tunnel in mein Netzwerk zuhause und dann über den heimischen Router wieder ins Internet. Keine einzige mit meinem Browser geöffnete Web-Seite ist vom AccessPoint sichtbar, es können keine Daten (Anmeldename, PWD) abgegriffen werden, die ich auf irgendeiner Web-Seite eingebe, der gesamte Datenverkehr findet hochsicher verschlüsselt durch den Tunnel über meinen Router zuhause statt. Ich kontrolliere das immer zuerst, in dem ich mir kurz auf einer Online-Website meine jetzt aktuellen öffentlichen IP-Adressen anzeigen lasse.... und mit erfolgreich gestarteten OpenVPN ist das nie die temporäre Adresse des AccessPoints, sondern immer die IP meines Routers zuhause oder eine IPv6-Adresse gebildet aus meinem heimischen ISP-Prefix.
Ist das VPN meiner FRITZ!Box nicht das gleiche, wie OpenVPN? Im DSL-Router ist VPN ja schon als Grundfunktion vorhanden und man kann es ohne viel Arbeitsaufwand nutzen. Ja, stimmt, vermutlich ist VPN über die Fritzbox um einiges leichter in Betrieb zu nehmen. Aber leider gibt es auch einige gravierende sicherheitsrelevante Unterschiede im Vergleich zu OpenVPN, wegen derer ich schließlich zu dem Fazit gekommen bin, das AVM-VPN nicht zu verwenden.
Ein OpenVPN-Tunnel ist immer eine end2end-Verbindung zwischen zwei vertrauenswürdigen Geräten, die von mir selber eindeutig als vertrauenswürdiger Erster und Letzter Punkt auf dieser Kommunikationsstrecke identifiziert sind. Alles was zwischen diesen beiden Endpunkten liegt, also auf dem ganzen Weg des Tunnels, kann man eigentlich durchweg als potentiell unsicher einstufen. Das betrifft natürlich zuallererst den offenen Start-AccessPoint mit dem wir verbunden sind, dann den Transport durchs Internet und letztlich auch die Fritzbox als End-AccessPoint. Der Vorteil des OpenVPN-Tunnels ist, dass die übertragenen Daten-Pakete diese "drei unvermeidbaren Teilnehmer" nicht entschlüsselbar und somit völlig unlesbar passieren, einschließlich der vielleicht auch übertragenen Passworte oder Zugangsdaten zu Geräten der Home-Automation.
Und warum ist das Fritzbox-eigene VPN als unsicher einzustufen? Zum einen, weil die Paketverschlüsselung an einem Punkt aufhört, der auf proprietärer Software basiert und zum anderen wegen der Tatsache, dass die Fritzbox bekanntermaßen eine Backdoor implementiert hat. Also braucht man eine Antwort auf die Frage, ob man einer fremden Hardware mit quasi unkontrollierbarer Software als Endpunkt einer Verschlüsselung wirklich vertrauliche Daten anvertrauen will? Wenn es dabei auch noch um Home-Automation und Zugangsdaten dazu geht, halte ich das für einigermaßen fahrlässig.
Was bedeutet Backdoor...?... das klingt ja irgendwie beunruhigend. Viele moderne DSL-Router -wie eben auch die FRITZ!Box von AVM- haben die TR-069-Schnittstelle implementiert. Über diese Schnittstelle werden primär Updates installiert, oder neue Programme, aber auch Sicherheitspatches. Und bei manchmal auftretenden heimischen Problemen, mit denen unkundige normale Home-User oft überfordert sind, können Support-Mitarbeiter des DSL-Anbieters über diese Schnittstelle auch Wartungsarbeiten am Router durchführen, bis hin sogar zu veränderten Einstellungen. Aber genau deswegen ist es funktional wie ein SSH-Zugang für Fremde in unser Netzwerk zu sehen, ohne faktisch selber ein SSH-Server zu sein. Also ist das alles nur scheinbar vorteilhaft für uns, es wird uns nämlich gar nicht offen mitgeteilt, welche Nachteile das zeitgleich für uns beinhaltet und wir werden nicht gefragt, ob wir dem überhaupt zustimmen. Denn wer diese Schnittstelle bedienen darf, kann alles installieren und im Router alles veranlassen. Ein Wikipedia-Artikel beschreibt die TR-069-Schnittstelle deshalb auch als Beschneidung der Privatsphäre und des Datenschutzes für den Endanwender. Dem DSL-Anbieter wird damit ermöglicht, Änderungen am DSL-Router durchzuführen, die der Benutzer weder kennt noch erlaubt hat. Über diese Schnittstelle sind sogar nicht nur Änderungen im Roll-Out-Mode für alle im Land betriebenen DSL-Router möglich, sondern auch explizit für einen einzeln Router, was insbesondere für uns eine große Bedeutung bei Online-Durchsuchungen, digitaler Schleierfahndung oder Abhörbefugnissen haben kann. TR-069 sieht sogar die Möglichkeit vor, Geräte hinter der Router-Firewall, also unsere Geräte im Netz zu sehen und ggf. dort Daten zu verändern. Damit stellt TR-069 durch sein Funktionsprinzip ohne jeden Zweifel eine Backdoor da. Einige DSL-Anbieter erlauben es, diese Schnittstelle im Router zu deaktivieren, einige DSL-Anbieter räumen einem dieses Recht nicht ein. In einem solchen Fall würde ich diese Fritzbox nicht verwenden bzw. eine eigene Router-Firewall zwischen DSL-Router und lokales Netzwerk positionieren.
Der Zusammenhang zum VPN ist also ganz einfach. TR-069 ist eine Schnittstelle, mit der natürlich folgerichtig auch direkt und unautorisiert auf die im DSL-Router hinterlegten Zertifikate und Kryptografie-Schlüssel zugegriffen werden könnte. Und wenn man die hat, braucht man die Schnittstelle gar nicht mehr, um Zugang zu Deinem Netzwerk zu bekommen, damit ist man einfach auf geraden Weg direkt drin. Wegen der Schnittstelle TR-069 hast Du tatsächlich also keine Kontrolle mehr darüber, wer vielleicht auf diese Daten zugreift und wie er das verwendet. Wie willst Du außerdem gewährleisten oder verhindern, dass bei einer Fritzbox nicht sogar beabsichtigt ist, die Keys auszulesen und anders als Du erlaubst zu verwenden? Wie willst Du gewährleisten, dass eine Behörde nicht so was wie einen 'Generalschlüssel' für diese Keyfiles hat oder von AVM oder dem DSL-Anbieter die Herausgabe als Polizeimaßnahme erzwingen kann?
Und genau hier besteht der wirklich beunruhigende Unterschied zu OpenVPN, denn wer Zertifikat und Kryptografie-Schlüssel aus der Fritzbox 'entwendet' hat, hat ungehinderten Zugang zu Deinem Netzwerk. Dabei ist es völlig egal, ob die Keys legal ausgelesen wurden, oder illegal, oder gehackt, oder über eine Sicherheitslücke. Deshalb machst Du die Sicherheit Deines privaten Netzwerkes auch von dem Zufall abhängig, wie "sorgfältig" und "gewissenhaft verschwiegen" irgendein beliebiger Support-Mitarbeiter Deines DSL-Anbieters mit den Zugangsdaten zu Deinem Router umgeht, ohne das Du selber den geringsten Einfluss darauf hast. Genauso wenig hast Du Einfluss darauf, wer beim DSL-Anbieter überhaupt wie autorisiert und wie kontrolliert und von welchen Compliance-Regeln geleitet Zugang zu deren Systemen hat, um darüber vielleicht die Zugangsdaten für Deinen Router auszulesen. Und vergiss nicht, dass im First-Level-Support manchmal auch nur 400€-Teilzeit-Kräfte für eine Erst-Hilfe sitzen, oder es handelt sich gar nur um ein mit dem Auftrag "Kunden-Erst-Kontakt" beauftragtes Call-Center.
Bei meiner FRITZ!Box konnte ich den Port jedenfalls nachweislich (mithilfe eines Port-Scanners) schließen. Wenn sich diese Situation jemals ändern sollte, schalte ich sofort eine eigene Router-Firewall zwischen LAN und DSL-Router. Und selbst wenn mein DSL-Router LAN-Intern unerlaubt lauschen und Passwörter (o.ä.) mitschreiben würde, so hat er dennoch keine Möglichkeit, auf Zertifikat und Keyfile lesend zuzugreifen und diese anders als von mir erlaubt zu verwenden. Insofern ist natürlich wegen fehlender Keyfiles auch kein unerlaubter Zugriff von außen möglich. Du solltest also akzeptieren, dass Du mit der Verwendung des AVM-VPNs die Kontrolle über Deine Hardware und Deines Netzwerkes zu einem beträchtlichen Teil aus der Hand gibst und somit möglicherweise in eine Situationen kommst, in der Du nicht mehr allein Entscheidungen für Deine Hardware triffst.
Meine Fritzbox hat definitiv keinen Zugang zu den Dateien, die die Kryptografie und ausschließlich den erlaubten Zugang in mein Netz sicherstellen. Insofern kann sie auch nichts übernehmen und ggf. unautorisiert weitergeben. Alles zusammengenommen sind das für mich wirklich gute Gründe, OpenVPN als Alternative zu verwenden.... auch wenn es -wie wir noch sehen werden- einigermaßen kompliziert einzurichten ist.
Bevor es nun endlich mit der Installation unseres VPN-Netzwerks losgeht, solltest Du Dir aber jetzt noch einmal bewusst machen, um was es hier überhaupt geht: Du öffnest ein Portal in Dein privates Heim-Netzwerk! Das bedeutet, wenn Du im Anschluss daran nicht zweifelsfrei eine auf Wissen beruhende Kontrolle über Deine Hardware hast, entscheidest Du auch nicht darüber, wer diese Hardware mit welchen Absichten verwendet. Punkt! Wie Deine Hardware verwendet wird, entscheiden dann vielleicht irgendwelche Dir völlig unbekannte Menschen. Akzeptiere das einfach. Allein zu denken und darauf zu vertrauen, Du hättest die Kontrolle und es passiert schon nix ... vergiss es! So funktioniert das nicht! Gerade bei den allzu oft vorgefundenen und fast normalen privaten Rahmenbedingungen ist das in Wirklichkeit nur ein Trugschluss. Auf einem potentiell unsicheren Betriebssystem kannst Du keine ausschließliche Kontrolle und somit keine vollständige Sicherheit erwarten, infolgedessen gibt es auch keine Garantie dafür, dass nur Du alleine Entscheidungen für Dein System triffst. |  |
Ein potentiell unsicheres Betriebssystem ist es, wenn Du z.B. den Nutzungsbedingungen proprietärer Software ungelesen (oder unverstanden) zugestimmt hast, oder wenn Du Software aus dubiosen Fremd-Quellen (anonyme ppa's oder Quellen im Internet) verwendest, oder wenn Du in der Admin-Group eingetragen bist und als Du selber Programme starten kannst, die dann mit privilegierten Rechten ausgeführt werden. Unter solchen Bedingungen ist der Gedanke ganz allein die exklusive Kontrolle zu haben eine Illusion, ein reines Glücksspiel. Sei Dir deshalb immer zu jeder Zeit bewusst, dass Du im Fall der Fälle niemals nur Dir allein schadest, der Schaden trifft immer uns alle. Mach Dir bewusst, was es bedeutet, wenn Deine Hardware als Mitglied einer Bot-Net-Attacke z.B. einen Energieversorger angreift oder ein Krankenhaus oder eine Bank oder eine Versicherung. So etwas betrifft immer uns alle. Die Kontrolle darüber, wer Deine Hardware verwendet, kannst Du nur dadurch erhalten, wenn Du alles mit Sachverstand und der zweifelsfreien Feststellung "ich verstehe, was ich hier mache" tust. Und nicht vergessen, "Glauben" hat wirklich absolut gar nichts mit "Wissen" zu tun. | |
Überblick - Was ist alles zur Einrichtung von OpenVPN notwendig ?
Die folgenden Liste verschafft uns einen kurzen Überblick über das, was uns ab jetzt erwartet.... mit folgender Zielsetzung:
- Ich möchte einen VPN-Zugang einrichten, um auf sichere Art und Weise von außerhalb über das Internet auf die Ressourcen meines Heimnetzwerks zugreifen zu können.
- Für ein Fallback-Szenario wird zusätzlich ein zweites VPN-Netz via TCP auf Port 443 vorgesehen.
- IPv6 soll via NAT geroutet werden. (Kann bei reinen IPv4-Netzen ignoriert werden!)
Dazu wird mit OpenVPN ein End-to-End-Tunnel über den Routing-Mode mit tun-Devices etabliert (alternativ: tap-Devices + Bridging). Als regelmäßig verwendetes Protokoll ist UDP vogesehen. Das Fallback-VPN ist in den Fällen eine mögliche Alternative, wenn ein Gastgeber-WLAN den Datenverkehr auf HTTP(S) beschränkt und sämtliche UDP-Ports über einen Paketfilter gesperrt hat. Bitte unbedingt dabei beachten, dass der Port 443 nicht durch einen anderen Service belegt sein darf, wie zum Beispiel durch einen Web-Server wie Apache oder Nginx. Wird der Port 443 bereits verwendet, steht diese Möglichkeit eines Fallback-VPNs nicht zur Verfügung. Es gibt zwar die Möglichkeit des Port-Sharings, OpenVPN unterstützt das, aber das kann nicht Thema dieses Artikels sein.
Die To-do-Liste:
Was? | Wo? | |
| Benötigte Ports öffnen und deren Weiterleitung einrichten | DSL-Router |
| Statische Routen für die VPN-Netze zum VPN-Gateway einrichten | DSL-Router |
| OpenVPN aus dem Source-Paket kompilieren und ein Deb-Package erstellen | Arbeitsplatz-PC |
| Keyfiles und Zertifikate für Server und alle betroffenen Clients-Geräte erstellen | Arbeitsplatz-PC |
| Config-Files für den Server erstellen | Arbeitsplatz-PC |
| Config-Files für Clients erstellen | Arbeitsplatz-PC |
| Systemd-Service-Units zum Starten der VPN-Daemons und nftables-Regeln erstellen | Arbeitsplatz-PC |
| Deb-Package für OpenVPN installieren | OpenVPN-Server |
| Kernelparameter für Forwarding setzen | OpenVPN-Server |
| Service-Units übertragen und aktivieren | OpenVPN-Server |
| Deb-Package für OpenVPN auf den Laptops installieren | mobile OpenVPN-Clients |
| Keyfiles und Zertifkate auf die betroffenen Laptops übertragen | mobile OpenVPN-Clients |
| On-The-Fly-Starter auf den betroffenen Laptops einrichten, um es nur bei Bedarf zu starten | mobile OpenVPN-Clients |
| OpenVPN-Client auf den betroffenen Smartphones installieren | Smartphone |
| Keyfiles und Zertifkate auf die Smartphones übertragen | Smartphone |
| OpenVPN-Client auf den Smartphones einrichten | Smartphone |
Mit einem Blick auf das nebenstehende Bild versuchen wir uns auch noch einmal kurz zu verinnerlichen, wohin die Reise überhaupt gehen soll, was unser Ziel ist, welche Komponenten wir mir welcher IP in Erinnerung behalten müssen ... und was ganz am Ende, wenn wir fertig sind, hinten rauskommen soll.
Wenn alles korrekt eingerichtet ist, haben wir 3 Netzwerke, 2 Gateways und 3 DHCP-Server in Betrieb genommen. Wir haben Clients, die sich mit allen 3 Netzen verbinden können, zuhause ins heimische LAN und unterwegs in eins der beiden VPN-Netze. Und sie erhalten je nach Netzwerk eine zum Netzwerk passende IP-Adresse für IPv4 und ggf. auch für IPv6. Wir haben dann |  |
> das alte Heim-Netzwerk, IP-Range 10.0.1.0/24 und > ein neues VPN-Netzwerk (UDP), IP-Range 10.0.8.0/24 > ein neues VPN-Netzwerk (TCP), IP-Range 10.0.9.0/24 > das alte Gateway und DHCP-Server, IP 10.0.1.1 und > ein neues Gateway, IP 10.0.1.2 sowie > einen neuen VPN-DHCP-Server (UDP), IP 10.0.8.1 > einen neuen VPN-DHCP-Server (TCP), IP 10.0.9.1 |
Für die Vorbereitung der Installation auf Server und Clients verwende ich 2 Systeme, einmal meinen persönlichen PC, der hierfür als Entwickler-PC und als Key-Signing-Machine genutzt wird. Und einen RasPi zum Erstellen des OpenVPN-Binaries für die Arm-Architektur.
Weil mein als Server arbeitender Pi keine Entwicklungstools beinhaltet und ich diese dazu notwendigen Pakete nicht nur für diesen einen Ausnahmefall installieren will, erstelle ich das Paket auf einem Zweit-Pi mit einem eigenem Raspian-Lite. Falls kein zweiter PI zur Verfügung steht, empfehle ich im vorhandenen PI kurzerhand vorübergehend die Karte auszutauschen. Dazu einen shutdown durchführen, eben schnell eine Zweit-Karte mit einem abgespeckten Raspian-Lite rein, das Paket wie beschrieben erstellen, Karte raus, erste Karte wieder rein und den Pi für den Normalbetrieb durchstarten. Von der Zweitkarte übertrage ich dann das Paket zur Sicherung via Card-Reader und SSH auf meinen PC und führe später von dort die OpenVPN-Installation auf dem Server durch.
Für den späteren ersten Funktionstest einer Verbindung von außen über das Internet zum OpenVPN-Server verwende ich meinen Laptop und mein Galaxy-S8. Mit dem S8 kann ich über die Verwendung der Funktion "Mobile Daten" die aktive UMTS-Verbindung via Tethering "weitergeben". Der Laptop meldet sich dazu einfach am WLAN-Accesspoint des Handys an und hat damit über das Handy-Netz eine Internet-Verbindung.
|
Beginnen wir mir den notwendigen Einstellungen in unserem DSL-Router. Wie oben schon in den Bildern sichtbar und erklärt, ist es notwendig, eine spezielle Tür für die OpenVPN-Datenpakete ausdrücklich zu öffnen. Einige weitergehende und durchaus wichtige und mit diesem Artikel unbedingt im Zusammenhang stehenden Informationen zur rudimentären Firewall-Funktion des DSL-Routers habe ich in meinem Firewall -Artikel beschrieben, deswegen begnüge ich mich hier mit einem Verweis und spare mir damit lange Wiederholungen.
Ich empfehle als erstes den Dialog-Modus des Web-Inferfaces unseres DSL-Routers auf "erweitert" oder "Expert" einzustellen. Nur mit dieser Einstellung werden uns auch alle wichtigen Parameter angezeigt bzw. sind änderbar. Ich verwende hier Beispiele für die Fritzbox 7490, die aber im Großen und Ganzen auch passend für die FB 7270 sind. Für alle anderen Router muss man sich die äquivalenten Einstellungen im Menüsystem suchen. Über den Menüpunkt Freigaben werden die zu öffnenden Ports eingerichtet, über die später ein Zugang aus dem Internet heraus in unser lokales Netzwerk ermöglicht wird. Bitte die Schaltfläche Gerät für Freigaben hinzufügen auswählen. |  |
Der erste Schritt ist es, den Zielhost für die von außen kommenden Datenpakete zu bestimmen. Erster Empfänger aller Pakete von außen ist immer unser DSL-Router, weil der als einziger eine Internet-taugliche IPv4 innehat. Die IPV4-Adressen aller anderen Clients sind nur lokal gültige Adressen, die nicht internettauglich sind. Auf diesem Bildschirm teilen wir dem DSL-Router mit, welcher PC im LAN als OpenVPN-Ziel-Host diese Pakete erhalten soll. Damit es hier zu keinen Missverständnissen führt, wähle ich immer den Zielhost ausdrücklich über seine in meinem Netz statische IP-Adresse aus. Das ist ein sehr wichtiger Umstand: Wir müssen sicherstellen, dass kein anderer PC diese IP-Adresse zugeteilt bekommt, diese IPv4 muss für den OpenVPN-Server reserviert bleiben. Bitte nach Eingabe des Zielhosts die Schaltfäche Neue Freigabe auswählen. |  |
Mit diesen 2 Dialogen können für den zuvor festgelegten Ziel-Host die zu öffnenden Ports vorgegeben werden. Die Bezeichnung OpenVPN_UDP4 und OpenVPN_TCP4 sind von mir willkürlich festgelegt worden, ebenso ist die Wahl der Ports 443 und 55553 willkürlich. Den Port 443 habe ich als Fallback-Port freigegeben, der nur in Ausnahmesituationen verwendet wird, wenn durch den Admin eines für Gäste offenen AccessPoints das primär von mir genutzte UDP-Protokoll gesperrt ist – wovon möglicherweise unprivilegierte Ports oberhalb 1024 betroffen sein können. Der Port 55553 ersetzt den für OpenVPN regulär verwendeten Port 1194. Die Variante mit Port 443 ist eine besondere Spielerei, die bei einer Erst-Einrichtung eigentlich nicht zwingend notwendig ist. Für den Anfang reicht es aus, sich erst mal nur auf den UDP-Port zu konzentrieren und erst später, wenn das läuft, vielleicht über einen alternativen TCP-Port nachzudenken. Und es besteht hierbei noch eine wichtige Besonderheit, die uns durchaus bewusst sein muss. Eigentlich ist der Port 443 ja der für HTTPS-Traffic verwendete Port. Üblicherweise lauscht also ein Web-Server auf Verbindungsversuche, die von außerhalb über DSL-Router über diesen Port "reinkommen". Auf meinem OpenVPN-Server lauscht aber kein Web-Server auf Port 443, ich habe diesen Port im DSL-Router quasi zweckentfremdet. Bei mir lauscht auf dem Ziel-Host nur ein OpenVPN-Server auf den Ports 55553 (UDP) und 55554 (TCP). Man muss sich die Wege eines Daten-Paketes also wie folgt vorstellen: Internet-Anfrage: Annahme durch DSL-Router: Weitergeleitet an OpenVPN-Server: von Port 55553 auf Port 55553 auf Port 55553 von Port 443 auf Port 443 auf Port 55554 Wenn allerdings jetzt sofort beide Freigaben eingerichtet werden, empfehle ich, beide Freigaben einzeln einzurichten. Das heißt, nicht beide gleichzeitig, sondern die zweite erst dann, wenn die erste auf der Einstiegsseite als Aktiv markiert ist. Siehe ergänzend zu den Port-Nummern auch: < Firewall > |  |
 | |
Die Übersichtsseite zeigt, dass die neuen Freigaben fehlerfrei eingerichtet sind. |  |
Als nächstes sind im DSL-Router noch statische Routen zu setzen. Wir haben es ja hier faktisch mit 3 Netzen zu tun. Home-Network: 10.0.1.0/24 Gateway: DSL-Router = 10.0.1.1 OpenVPN-Netz via UPD: 10.0.8.0/24 Gateway: OpenVPN-Server = 10.0.1.2 OpenVPN-Netz via TCP: 10.0.9.0/24 Gateway: OpenVPN-Server = 10.0.1.2 Allein die Weiterleitung vom DSL-Router zum VPN-Server reicht nicht aus. Diese statischen Routen sorgen dafür, dass zwischen den 2 VPN-Netzwerken und dem Home-Netzwerk auch eine normale Kommunikation zwischen VPN-Clients und Home-Netzwerk-Clients möglich ist. Ohne Routen wären im Heimnetz die VPN-Clients unbekannte Ziele... das bedeutet, Pakete mit dem Ziel eines VPN-Clients (also unbekannt) würden die Standard-Route (DSK-Router) ins Internet nehmen und dort irgendwann verworfen werden, weil sie auch dort unbekannt sind. Durch diese neuen Routen wird definiert, dass für Pakete mit dem Ziel 10.0.8/24 und 10.0.9/24 unser OpenVPN-Server das Standard-Gateway ist und nicht der DSL-Router.... also kommen sie auch am Empfänger an. |  |
Abschließend werfen wir noch einen Blick auf die Netzwerk-Einstellungen des DSL-Routers. Wir sehen hier die Adressen, die selbstverständlich die gleichen sind, die später bei den Konfigurationsdateien verwendet werden. Das ist sowieso einer der wichtigsten Grundsätze: Wenn wir solche Arbeiten tun oder vorhaben, also z.B. wie hier mehrere miteinander kommunizierende Netzwerke einrichten, so müssen wir uns zu jeder Zeit aller Faktoren bewusst sein. Dabei ist es auf jeden Fall hilfreich, wenn man zuvor ein Papier-Planungs-Netzwerk entwirft, auf dem alle Komponenten schon ihre zukünftigen Parameter erhalten und von dem man beim individuellen Einrichten die betroffenen Werte abliest oder einfach nur, um die eingerichteten Parameter am Ende noch mal mit der Planung zu vergleichen. Ein kleiner Fehler, und schon funktioniert's am Ende nicht... und dann beginnt das frustrierende Drama der Fehlersuche, weil man zunächst mal gar keine Ahnung hat, wo man überhaupt zu suchen anfangen soll. Also ganz wichtig, besser vorher genau planen und beim Einrichten immer äußerst konzentriert und gewissenhaft arbeiten. |  |
