[HowTo] Sicherer Fernzugriff auf den Receiver (SSH, VPN, OpenWebif mit HTTPS)

Nachricht
Autor
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

Sicherer Fernzugriff auf den Receiver (SSH, VPN, OpenWebif mit HTTPS)

#1

Beitrag von SpaceRat »

[align=center]Einleitung

Mit den immer umfassenderen Funktionen unserer E2-Boxen - insbesondere wenn so ein schönes Image wie OpenATV darauf läuft :) - wird es auch immer interessanter, von unterwegs Zugriff auf die Box zu haben.

Beispiele für die Möglichkeiten mit Fernzugriff auf die Box sind u.a.:
- Fernwartung von Boxen (z.B. bei den Eltern, Freunden oder sonstigen Verwandten, die sich weniger gut auskennen)
- Pflege von Senderlisten
- Programmierung von Aufnahmen von unterwegs aus
- Streaming oder Transcoding von Live TV oder Aufnahmen/Mediendateien aufs Smartphone, eine E2-Box im Ferienhaus, o.ä.

Die entsprechenden Dienste sind - leider - auch sehr schnell freigegeben, Anleitungen dazu - man könnte sie auch Anleitungen zum Selbstmord nennen - gibt es auch viel zu viele.

Ich möchte an dieser Stelle vor diesen Anleitungen zur Freigabe von Telnet, FTP und HTTP/Web-Interface eindringlich warnen, ganz so einfach ist es eben doch nicht:
Alles was Ihr für Euch ins Internet freigebt ist nicht nur für Euch erreichbar, sondern auch für jeden anderen auf der Welt mit Internetanschluß!


Dabei sollte man auch nicht auf den Gedanken kommen "ist ja nur ein Receiver, ist mir egal, wenn der Besuch kriegt":
Eine E2-Box ist eben nicht einfach nur ein Receiver, es ist ein vollwertiges Linux-System, je nach Generation mit mehr Rechenleistung als so mancher PC!
Die jüngsten Cyber-Angriffe im Internet ...
- die Lahmlegung von Netflix, Twitter, u.v.m im Oktober 2016
und
- der Abschuß einer Million Telekom-Anschlüsse im November 2016
... gehen auf das Konto einer ganzen Armee genau solcher Geräte aus dem sogenannten IoT (Internet of Things)!



Dies bedeutet aber nicht, daß man auf die neuen Möglichkeiten verzichen muß:
Man muß sich lediglich Gedanken machen und etwas Zeit in die Absicherung investieren!


Um genau diese Absicherung geht es in diesem Tutorial.
Ich werde aufzeigen, wie man
- SSH (Secure Shell)
- VPN (Virtual Private Networks)
- HTTPS
so konfiguriert, daß ein Zugriff von außen mit größtmöglichem Komfort bei gleichzeitiger bestmöglicher Sicherheit realisierbar ist.

Ein Hinweis vorab:
Es ist technisch unmöglich, die Dienste
- Telnet
- FTP
oder
- HTTP
abzusichern, auch wenn die Möglichkeit eines Kennwort"schutzes" das suggerieren mag.[/align]


Inhalt:

Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#2

Beitrag von SpaceRat »

[align=center]1.1: SSH - Secure SHell, ein Überblick

Eine Möglichkeit des sicheren Zugangs zur Box von außen besteht in der Verwendung von "Secure Shell" oder kurz ssh.
SSH wurde als Ersatz für den unsicheren Telnet-Zugang geschaffen, kann aber deutlich mehr.

Über SSH könnt Ihr:
- auf die Shell/Console Eurer E2-Box zugreifen, genau wie mit Telnet
- mittels scp (Secure CoPy) Dateien zwischen Boxen, Box und PC, usw. usf. übertragen
- mittels sftp (Secure FTP, aber nicht wirklich verwandt mit FTP und auch nicht zu verwechseln mit FTP(E)S) Dateien übertragen
- "Ports tunneln", um weitere Dienste - z.B. ggf. unsichere - durch die gesicherte SSH-Verbindung zu leiten

Kurz:
Über SSH ist die vollständige Bedienung und Benutzung aller anderen Dienste[size=75], incl. CAMs, aus der Ferne möglich.[/size]

Die Einrichtung ist relativ einfach, in der Benutzung ist es bei Benutzung von Port-Tunneling dafür etwas aufwendiger als ein VPN.
SSH eignet sich somit vor allem zur Fernwartung von solchen Boxen auf die Ihr eher selten Zugriff haben müßt und für Einsatzzwecke, wo ohne SSH auch nur Telnet und FTP benötigt würden.[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#3

Beitrag von SpaceRat »

[align=center]1.2: SSH - Secure SHell - Einrichtung des Servers

Um sicheren Zugriff per SSH zu erlangen, muß zuerst einmal der Server, also Eure E2-Box, konfiguriert werden.
Im Auslieferungszustand ist SSH nämlich völlig unsicher (OpenATV, OpenHDF, OpenViX, ...) oder kaum gesichert (OpenPLi), also keinen Deut besser als Telnet.



Schritt 1: Erzeugen eines Schlüsselpaares (Key Pair)
Sicher wird SSH erst durch Verwendung von "(pub) key auth", also Authentifizierung über
- einen privaten Schlüssel (Den hat der Client)
und
- einen öffentlichen Schlüssels (Den hat der Server, den könntet Ihr vom Prinzip her auch auf Facebook posten).
Die beiden Schlüssel bilden ein sogenanntes "Schlüsselpaar" oder "key pair" bzw. ein Asymetrisches Kryptosystem.

Prinzipiell wäre SSH auch über eine reine Passwort-Authentifizierung möglich.
Ein Passwort wird jedoch erst durch Verwendung eines möglichst großen Zeichensatzes (Großbuchstaben, Kleinbuchstaben, Ziffern [b]und
Sonderzeichen) sowie eine gewisse Mindestlänge sicher.
Selbst ein elendig langes und nicht mehr zu merkendes Passwort könnte nicht an die Sicherheit eines Schlüsselpaares tippen, deshalb rate ich zur Verwendung eines Schlüsselpaares, damit kann das Passwort der Box ggf. auch leer oder simpel gehalten werden.
[/B]

Die Erzeugung des Schlüsselpaares kann auf der E2-Box selbst erfolgen, dazu verbindet Ihr Euch per Telnet mit der Box und gebt folgenden Befehl ein:

Code: Alles auswählen

dropbearkey -s 2048 -t rsa -f ~/.ssh/id_rsa


Dabei ist 2048 die Länge des Schlüssels in Bit, je länger diese ist, desto sicherer ist die Verschlüsselung, desto mehr Rechenaufwand ist aber auch für die Erzeugung des Schlüssels und für die Verschlüsselung nötig.
Je nach Quelle gelten 2048, 4096 oder 5120 Bits als sicher, d.h. nach derzeitigem Stand der Wissenschaft nicht durch brutale Rechengewalt ("brute force") zu knacken.

dropbearkey wird damit ein RSA-Schlüsselpaar anlegen und in der Datei ~/.ssh/id_rsa speichern, das ist in lang: /home/root/.ssh/id_rsa

Die Ausgabe wird in etwa wie folgt aussehen:

Code: Alles auswählen

root@solo2 ~ # dropbearkey -s 2048 -t rsa -f ~/.ssh/id_rsa
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfQtxExZz/LozE6Yz1hRN9AK6hfxH78OPzVEnObhE3EVxvrzJhUOX006HsNhs5fs1lyeL1qpFB5iN6B5S8WbWK9tz96QlfV3pFh9G2rBO/zbk/C2A1hLiXI88TpneTI3AtSg05KybyCKtlitBXeTcCxqw7MP1JwkVMO+Md7cDfTfWBFJvknF2z9DF8dsP5uuCjn4eV2X468/aD4RyRJGRFdPic1ONUqYYBtqrMP0nY9AMk+pyIOTVc599io/uDuFy6GR6QoluBq/Jwfahu4iAVHEOSFUk3QU+xD12KvU8E31P99xUb83XAn9lzdlh2hfPdeDvPzLtdhIAMVGqs5l2V root@solo2
Fingerprint: md5 f8:9d:71:ae:df:bb:65:89:2a:1c:40:76:40:00:ae:fa


dropbear erzeugt den Schlüssel dabei in einem Format, mit dem kein anderes Programm etwas anfangen kann, deshalb konvertieren wir den Schlüssel nun noch ins Format von OpenSSH:

Code: Alles auswählen

dropbearconvert dropbear openssh ~/.ssh/id_rsa ~/.ssh/id_rsa.ssh





Schritt 2: Den neu erzeugten Schlüssel als zugriffsberechtigt eintragen und Rechte korrigieren

Damit eine Verbindung zur E2-Box mit dem neu erzeugten Schlüssel möglich ist, muß dies erst noch dropbear (Das ist der SSH-Server auf den E2-Boxen) mitgeteilt werden.
Dazu wird der öffentliche Schlüssel/public key - also der, den man vom Prinzip her jedem Hinz und Kunz geben könnte - in die Konfigurationsdatei ~/.ssh/authorized_keys (in lang: /home/root/authorized_keys) eingetragen.

Folgendes Kommando erledigt dies:

Code: Alles auswählen

dropbearkey -y -f ~/.ssh/id_rsa | grep "^ssh-rsa " >> ~/.ssh/authorized_keys

Damit wurde der öffentliche Key aus der Datei ~/.ssh/id_rsa ausgelesen und an ~/.ssh/authorized_keys angehangen.

Wie von Linux gewohnt, gibt es noch Nickeligkeiten bzgl. der Zugriffsrechte auf die Dateien, alle SSH-Dateien des Benutzers root dürfen auch nur dem Benutzer root zugänglich sein.
Die folgenden Befehle (Jede Zeile ein Befehl) setzt die gewünschten Rechte:

Code: Alles auswählen

chmod 600 ~/.ssh/*
chmod 700 ~/.ssh
chmod 700 ~




Schritt 3: SSH-Zugang nur noch mit Key erlauben

Mit folgendem Befehl

Code: Alles auswählen

echo DROPBEAR_EXTRA_ARGS="-s" > /etc/default/dropbear

ändert Ihr die Standardeinstellung "-B" (Für: "leere Passwörter erlauben", igittigitt) in "-s" (Gar keine Logins mit Passwort erlauben -> Key auth zwingend erforderlich).



Schritt 4: Abschluß

Ladet Euch nun noch die Dateien ~/.ssh/id_rsa und ~/.ssh/id_rsa.ssh bzw. /home/root/.ssh/id_rsa und /home/root/.ssh/id_rsa.ssh - z.B. per ftp oder Samba/Windows-Netzwerk - auf Euren PC runter und startet die E2-Box neu.




Hinweise

In OpenATV ist ein einmal abgesicherter SSH-Server "flashfest":
Bei einem Neuflash mit Einstellungsübernahme werden die authorized_keys und die Einstellung für dropbear, daß nur noch key auth zulässig ist, mit gesichert bzw. wiederhergestellt!

Es gibt jedoch Situationen, in denen die Rechte der Verzeichnisse aufgeweicht werden, was dazu führt, daß dropbear gar keine Connects mehr akzeptiert.
In diesem Fall müßtet Ihr per telnet - lokal ist Telnet ja ok - auf die Box und die folgenden Befehle wiederholen:

Code: Alles auswählen

chmod 600 ~/.ssh/*
chmod 700 ~/.ssh
chmod 700 ~


Ich habe sie meinem myrestore.sh-Script zugefügt, welches am Ende jedes Flash-Upgrades ausgeführt wird.[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#4

Beitrag von SpaceRat »

[align=center]1.3: SSH - Secure SHell - Einrichtung des Clients

Zugriff auf unseren soeben abgehärteten SSH-Server ist mit verschiedenen Clients möglich.

Ich werde in den folgenden Abschnitten die Verwendung mit
- FileZilla (kostenlos)
- PuTTY (kostenlos)
- ZOC
und
- ConnectBot (Android, kostenlos)
erklären.[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#5

Beitrag von SpaceRat »

[align=center]1.3.1: SSH - Secure SHell - Einrichtung des Clients: FileZilla

Der Zugriff auf den SSH-Server mittels FileZilla dient dem Transfer von Dateien, z.B. Senderlisten, und kann so FTP ersetzen, welches technisch unmöglich abzusichern wäre.

Die Einrichtung von FileZilla für einen SSH-Server gestaltet sich genauso einfach und selbsterklärend wie die eines FTP-Servers:
Bild[/align]
  1. Klickt auf "Neuer Server"
  2. Tragt genauso wie für FTP einfach den Hostname Eurer Box ein
  3. Wählt als Protokoll "SFTP - SSH File Transfer Protocol" aus
  4. Wählt als Verbindungsart "Schlüsseldatei" aus
  5. Benutzername ist "root"
  6. Navigiert zum Speicherort der von der Box heruntergeladenen id_rsa.ssh und wählt diese aus (Eine für PuTTY umgewandelte Datei im Format .ppk funktioniert ebenfalls!)
  7. Verbindet Euch zum Server bzw. speichert die neu erstellte Verbindung ab
  8. Jagt FTP zum Teufel ;)
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#6

Beitrag von SpaceRat »

[align=center]1.3.2: SSH - Secure SHell - Einrichtung des Clients: PuTTY

Für Windows ist einer der gängigsten SSH-Clients mit Sicherheit "PuTTY", ganz einfach weil er kostenlos ist.

In diesem Kapitel werde ich erklären, wie Ihr
- den auf der Box erzeugten Schlüssel ins Format von PuTTY importiert/konvertiert
- eine sichere Konsolen-Sitzung (a la Telnet) mittels PuTTY herstellt
- mittels PuTTY Ports von der Box zum Client-Rechner tunneln könnt


PuTTY

PuTTY steht gratis zur Verfügung und kann von hier heruntergeladen werden. Einsteigern empfehle ich den Download von "A Windows MSI installer package for everything except PuTTYtel".

Schlüssel importieren/konvertieren[/align]

PuTTY kann weder mit dem Schlüssel im dropbear-Format (id_rsa) noch dem im OpenSSH-Format (id_rsa.ssh) etwas anfangen, aber es kann den im OpenSSH-Format in das eigene "PPK"-Format konvertieren.
  1. PuTTYgen öffnen
    Klickt nach der Installation von PuTTY auf den Link "Run PuTTYgen" um PuTTYgen zu starten.
  2. Schlüsseldatei im OpenSSH-Format laden
    Bild
    1. Klickt in PuTTYgen auf "Load"
    2. Navigiert zum Speicherort, wo Ihr die von der Box gezogene Datei id_rsa.ssh abgelegt habt
    3. Wechselt auf die Ansicht "All Files (*.*)
    4. Wählt die Datei id_rsa.ssh aus
    5. Klickt auf "Öffnen"

    Ihr erhaltet folgende Bestätigung, daß PuTTYgen in der Datei einen OpenSSH-Schlüssel gefunden hat und Ihr den im PuTTY-Format speichern könnt:
    Bild
  3. Schlüsseldatei im PuTTY-Format speichern
    Bild
    1. Klickt in PuTTYgen auf "Save private key" und bestätigt folgenden Hinweis mit ok:
      Bild
    2. Navigiert zum Speicherort, wo schon die Datei id_rsa.ssh liegt (Sollte aber noch voreingestellt sein)
    3. Gebt der Datei einen Namen, hier im Bild id_rsa.ppk
    4. Klickt auf "Speichern"
  4. Abschluß
    Nun könnt Ihr PuTTYgen beenden.
[/spoiler]


[align=center]Verbindung herstellen[/align]

Für den Zugriff per putty von einem Windows-Client aus ist es empfehlenswert, sich ein Profil anzulegen und abzuspeichern, um später jederzeit mit einem Klick eine Verbindung herstellen zu können.

  1. Putty starten
  2. Profil-Grundeinstellungen
    In der Start-Ansicht von putty ...
    Bild
    sind nur wenige Einstellungen vorzunehmen:
    1. Der Hostname (z.B. die MyFritz-Adresse) der Box, hier tut.dyn.ip
    2. Der Name des Profils, hier einfach "Tut"
    SSH und Port 22 sollten bereits eingestellt sein.
    Das Profil kann auf Wunsch jetzt bereits zwischengespeichert werden.
  3. Autorisierung auf "Private Key" umstellen
    Auf der linken Seite wechseln wir in die Ansicht "Connection -> SSH -> Auth" und nehmen folgende Einstellungen vor:
    Bild
    1. Deaktivieren der "keyboard interactive"-Anmeldung
    2. Auswählen unseres im Schritt "Schlüssel importieren/konvertieren" erzeugten "private keys"
  4. Einstellen des Benutzernamens
    Den Benutzernamen stellen wir in der Ansicht "Connection -> Data" ein:
    Bild
    Hier ist einfach nur "root" einzutragen.
  5. Profil abspeichern
    Die Ansicht zurückwechseln auf "Session", dort die bereits vorab gespeicherte Sitzung "Tut" aus der Liste auswählen und auf [Save] klicken.
  6. Verbindung testen
    Mit Klick auf "Open" sollte sich ohne weiteres Zutun (Beim ersten Mal muß noch der Fingerabdruck des Servers auf der Box bestätigt werden) eine Terminal-Sitzung zu unserer Box öffnen:
    Bild
  7. Verbindung benutzen
    Die neu eingerichtete Verbindung kann von nun an ganz genauso wie eine Telnet-Sitzung benutzt werden.
    Tendenziell funktioniert sie eher sogar besser, was z.B. die Verwendung von Farben und Sondertasten (Und dazu zählen schon die Cursortasten) angeht, wie man spätestens bei Verwendung des Midnight Commanders (mc) o.ä. merkt.

    Im Gegensatz zu Telnet (Port 23), kann man eine so eingerichtete SSH-Verbindung (Port 22) aber tatsächlich auf Wunsch auch nach außen freigeben:
    Solange Ihr auf die Dateien id_rsa, id_rsa.ssh und id_rsa.ppk aufpaßt wie auf Euren Augapfel, genügt dieser Zugang höchsten Sicherheitsanforderungen.


[align=center]Ports durch SSH tunneln[/align]

    PuTTY erneut starten
  1. Profil laden
    Ladet das im vorherigen Schritt erstellte Profil, indem Ihr es in der Liste auswählt und auf "Load" klickt.
    Bild
  2. Tunnel erstellen
    Wechseln in die Ansicht "Connection -> SSH -> Tunnels"
    und dort die gewünschten Einstellungen vornehmen:
    Bild
    Es können beliebig viele Tunnel definiert werden, wobei jeweils einzustellen ist:
    1. Source Port = Der Port auf der lokalen Maschine, also dem SSH-Client
    2. Destination = IP/Name plus Port auf der Zielmaschine (Der E2-Box)
    Im abgebildeten Beispiel wird der lokale Port 17080 auf den Port 80 der E2-Box umgeleitet.
    Diese beiden Angaben jeweils ausfüllen und auf [Add] klicken, danach ggf. für weitere Ports wiederholen.
  3. Profil wieder abspeichern
    Nachdem alle gewünschten Tunnel definiert wurden, einfach wieder auf die Ansicht "Sessions" zurückwechseln und das Profil durch Klick auf "Save" neu abspeichern.
  4. Tunnel starten
    Sobald nun mit diesem Profil wieder eine Verbindung hergestellt wird (Profil auswählen -> Load -> Open), werden gleichzeitig die eingestellten ssh-Tunnel geöffnet.

    Das bedeutet:
    Solange die ssh-Sitzung läuft, sind die eingestellten Zieladressen/Ports unter der Adresse des Clients plus dem eingestellten Port ansprechbar.
    Um also den Web-Server der E2-Box aufzurufen (Siehe Beispiel oben), wird einfach im Webbrowser des SSH-Clients (= die Maschine, auf der PuTTY läuft) die Adresse http://127.0.0.1:17080 aufgerufen.
    Dieser Aufruf wird dann von PuTTY durch den ssh-Tunnel zur Box transportiert und auf dieser an "localhost:80" weitergereicht ... also den Webserver der Box.


[align=center]Tip zum Komfort bei SSH-Tunneling:[/align]

Wenn alles zur Zufriedenheit eingerichtet hat, kann man sich ganz einfach eine Desktop-/Schnellstart-/Sonstwas-Verknüpfung
mit dem Ziel

Code: Alles auswählen

d:\path\to\putty.exe -load "my session"

also z.B.

Code: Alles auswählen

C:\Programme\putty\putty.exe -load "Tut"

anlegen.

Danach genügt ein Doppelklick auf diese Verknüpfung um
1. PuTTY zu starten
2. eine SSH-Sitzung aufzubauen
und
3. alle eingestellten Tunnel wiederherzustellen.

Um auf unser ursprüngliches Vorhaben zurückzukommen, z.B. den Receiver der Eltern mit DreamBoxEdit o.ä. fernwarten zu können, würde man also wie folgt vorgehen:
1. Ein Tunnel vom lokalen Port 17021 auf die entfernte Adresse localhost:21
2. Ein Tunnel vom lokalen Port 17023 auf die entfernte Adresse localhost:23
3. Ein Tunnel vom lokalen Port 17080 auf die entfernte Adresse localhost:80
4. Ein Tunnel vom lokalen Port 17801 auf die entfernte Adresse localhost:8001
5. Ein Tunnel vom lokalen Port 17802 auf die entfernte Adresse localhost:8002

In DreamBoxEdit wäre dann nur noch einzustellen, daß die Box "Eltern" unter der Adresse 127.0.0.1 erreichbar ist und die Ports 17021 für FTP, 17023 für Telnet und 17080 für das Web-Interface nutzt.
Ggf. kommen halt noch die Ports 17801 für Streaming und 17802 für Transcoding hinzu, auch abhängig davon, was die Leitung hergibt und die Box der Eltern kann.

Ist die SSH-Verbindung mitsamt Tunneling also einmal eingerichtet, kann die so verbundene Box genauso einfach per Bouquet Editor Suite, DreamSet, DreamBoxEdit, etc. pp. ferngesteuert werden, als hätte man die notorisch unsicheren Ports 21, 23 und 80 der Box freigegeben. Man muß nur jeweils vorher die SSH-Verbindung samt ihrer Tunnel aufbauen, was ja nicht mehr Arbeit ist als ein Doppelklick!
Es ist aber im Gegensatz zur direkten Freigabe sicher, weil der einzige Port den Ihr wirklich freigebt Port 22 für SSH ist!

Natürlich könnt Ihr über diese SSH-Tunnel auch streamen und transcoden (Sofern die Internet-Leitung bei der Geschwindigkeit mitspielt), indem Ihr auf den lokalen Port 17802 aus dem Beispiel statt auf den Port 8002 der Box selbst zugreift.

Wenn auf der Gegenseite mehrere Boxen laufen, braucht Ihr übrigens nicht zwingend für jede Box eine neue SSH-Verbindung samt Tunnel, Ihr könnt auch alle Boxen (und weitere Geräte) durch eine einzige SSH-Verbindung erreichbar machen!
Wählt dazu als "Destination" (Ziel) nicht localhost, sondern den Hostname oder die IP, unter der die per SSH verbundene entfernte Box die anderen erreichbar zu machenden Geräte kennt.
Durch einen Tunnel vom lokalen Port 17001 nach "192.168.1.1:80" z.B. könnt Ihr Euch z.B. das Web-Interface des Routers der Gegenseite erreichbar machen (Angenommen, er hat die IPv4 192.168.1.1, sonst natürlich die richtige IPv4 des Routers nehmen :) )
oder
über einen Tunnel vom lokalen Port 18021 nach "anderebox:21" den FTP-Server der zweiten Box mit dem Hostname "anderebox".

Ein Hinweis am Rande für die, die es noch nicht wissen:
Jeder Port kann nur einmal benutzt werden. Wenn Ihr also wie im Beispiel Port 17021 für den entfernten FTP-Server der ersten Box verwendet, dann könnt Ihr Port 17201 für nichts anderes mehr verwenden, also nicht für den FTP-Server einer zweiten Box - auch nicht in einem zweiten Tunnel - und auch nicht mehr für lokale Server auf Eurem SSH-Client.
Verwendet also nach Möglichkeit in jedem SSH-Profil/-Tunnel andere Ports und zwar solche, die Ihr auch lokal nicht braucht.
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#7

Beitrag von SpaceRat »

Hier entsteht mein HowTo
Platzhalter 6
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#8

Beitrag von SpaceRat »

[align=center]1.3.4: SSH - Secure SHell - Einrichtung des Clients: ConnectBot (Android)

Für den Zugriff vom Smartphone aus benötigen wir einen SSH-Client mit Tunnelunterstützung.
Empfehlenswert ist z.B. ConnectBot (Gibt's kostenlos im Play Store).

Einrichten von ConnectBot für eine SSH-Verbindung mit Port-Tunneling[/align]

  1. Schlüssel auf's Smartphone kopieren
    Den in Kapitel 1.2 erzeugten Schlüssel im OpenSSH-Format, hier also id_rsa.ssh (auf den Bildern tut.ssh) ins Hauptverzeichnis des internen Speichers vom Smartphone kopieren.
  2. ConnectBot starten
  3. Verbindung erzeugen
    Bild
    Dazu einfach unten im Adressfeld

    Code: Alles auswählen

    root@<Dyn-Hostname der Box>

    eintragen, also z.B.

    Code: Alles auswählen

    root@tut.dyn.ip
  4. Privaten Schlüssel importieren
    In ConnectBot über
    Menütaste -> "Pubkeys verwalten" -> Menütaste -> "Importieren"
    zum Import der Keys wechseln und die Datei "id_rsa.ssh" auswählen.
  5. Privaten Schlüssel aktivieren
    Bild
    Den importierten Schlüssel antippen, so daß das Vorhängeschloß grün angezeigt wird.
  6. Tunnel anlegen
    Zurück in der Hostliste von ConnectBot lange auf unseren Host "tut.dyn.ip" tippen und "Port-Weiterleitungen editieren ..." auswählen.

    1. Über Menütaste -> "Port-Weiterleitung hinzufügen" kann ein neuer Tunnel angelegt werden.
    2. Langes Tippen auf eine vorhandene Port-Weiterleitung und man kann diese ändern oder löschen.

    Der Aufbau der Tunnel ist fast identisch wie bei putty:
    Bild
    Einziger Unterschied ist, daß jede einzelne Port-Weiterleitung auch einen eindeutigen Spitznamen erhält, z.B. "Web"

    Sobald alle Tunnel angelegt sind, kann die Verbindung hergestellt werden ...
  7. ssh-Verbindung samt Tunnel herstellen
    Zurück in der Hostliste kann eine Verbindung durch einfaches Antippen aufgebaut werden.
    Zum Trennen einer Verbindung "exit" eingeben oder Menütaste -> "Verbindung trennen" auswählen.
  8. Zugriff auf die Ressourcen der Box
    Solange ConnectBot die SSH-Verbindung zur Box aufrecht erhält, sind auch die für diesen Host definierten Tunnel ("Port-Weiterleitungen") aktiv und können vom Smartphone benutzt werden.
    Man könnte nun z.B. in DreamPlayer (oder DreamDroid) ein Profil erzeugen, welches 127.0.0.1 Port 17080 als Adresse des Web-Servers nutzt.


Ebenso wie die Verbindung über PuTTY ist auch diese Verbindung nach dem derzeitigen Stand der Technik weder abzuhören noch ist es möglich, unerlaubt Zugriff zu erlangen ohne den privaten Schlüssel zu besitzen.
(Es sei denn, Google ist so nett, den Inhalt Eures Smartphones mit der NSA zu synchronisieren, aber das ist eine andere Geschichte ....)
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#9

Beitrag von SpaceRat »

[align=center]1.3.5: SSH - Secure SHell - Einrichtung des Clients - PuTTY (Windows Phone)

Es gibt PuTTY auch als Version für Windows Mobile im Microsoft Store.

Eine Anleitung dafür kann ich leider nicht liefern, da ich kein Gerät mit Windows Mobile habe, den Bewertungen zufolge unterstützt PuTTY für Windows Mobile jedoch alles, was gebraucht wird, incl. Port Tunneling.

Wenn jemand mit Windows Mobile so nett wäre, das bei der Einrichtung mit Screenshots zu dokumentieren und etwas zu erklären, pflege ich das gerne hier ein.

Bild[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#10

Beitrag von SpaceRat »

[align=center]1.3.6: SSH - Secure SHell - Einrichtung des Clients - DasKannDasTeilAlsoAuchNicht (Apple OS - fälschlich auch iOS genannt¹)

Für den Zugriff vom Smartphone aus benötigen wir einen SSH-Client mit Tunnelunterstützung und ein Smartphone.
EiFon und EiPad sind aber so gar nicht smart und seit Apple OS 7.x macht das OS die im Hintergrund laufenden SSH-Sitzungen kaputt.
SSH-Sitzungen und Tunnel sind also theoretisch möglich, brechen aber 5 Minuten nachdem der SSH-Client in den Hintergrund gewandert ist wieder zusammen.

Naja, wieso sollten Pimmelprothesen für 1000 EUR auch das selbe können wie Smartphones für 100 EUR.

Da Apple bisher technisch ca. 4 Jahre zurückhängt, könnte ich voraussichtlich in 2020 diesen Beitrag mit einer Anleitung für EiFons füllen :)[/align]



1 - IOS ist das Betriebssystem auf Cisco-Routern, schon lange bevor an Eier-Fons und Eier-Pads zu denken war. Apple ist doch sonst so scharf darauf, daß Namens- und sonstige Rechte gewahrt bleiben!
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#11

Beitrag von SpaceRat »

Platzhalter für den Einsatz von SSH "Box2Box" (autossh, ssh, mc)
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#12

Beitrag von SpaceRat »

[align=center]2.1: VPN - Virtual Private Network - Überblick

Eine weitere Möglichkeit um von außerhalb sicheren Zugangs zur Box zu erhalten besteht in der Verwendung eines "Virtual Private Networks" ("virtuelles privates Netzwerk") oder kurz "VPN".

Die Einrichtung ist - je nach Rahmenbedingungen - relativ aufwendig, in der späteren Benutzung ist es aber sehr einfach.
VPNs eignen sich vor allem für den Zugriff auf Boxen, die ihr praktisch ständig im Zugriff haben wollt oder müßt.


Zuerst aber eine kleine Klarstellung, was ein VPN ist, denn der Begriff wird in der jüngeren Vergangenheit arg strapaziert/mißbraucht:

Ein VPN dient zur Verbindung mehrerer Teil-Netze - z.B. Eures Heimnetzes und dem Eurer Eltern, Eures Smartphones - zu einem einzigen Netzwerk oder Netzwerkverbund, als ob diese direkt über Kabel (oder WLAN) miteinander verbunden wären.

Das bzw. der so entstehende Netzwerk(-Verbund) ist
- virtuell, weil es eben keine direkte Kabel- oder WLAN-Verbindung besitzt
- privat, weil es trotzdem ein nach außen hin abgeschlossenes Netzwerk ist, das als solches nicht (direkt) mit dem Internet verbunden ist

VPNs dürfen nicht mit Anonymisier- und Urheberrechtsverletzungserleichterungsdiensten a la Perfect Privacy etc. verwechselt werden.
Diese benutzen zwar die gleichen Programme um ihre Dienstlistung anzubieten, aber es sind keine VPNs im ursprünglichen Sinne die da aufgebaut werden, denn "privat" ist da nichts, vielmehr wird eine (zweite) Verbindung ins öffentliche Netz hergestellt, also das genaue Gegenteil.
Man würde das besser als VIC für "virtual internet connection" oder so bezeichnen, es gibt auch tatsächlich einen Fachbegriff dafür, aber ich komme grad nicht drauf, weil der richtige Begriff von dem falschen erdrückt würde.

Wenn ich oder andere erfahrene User von VPNs reden, dann meinen sie aber immer die Kopplung privater (im Sinne von "abgeschlossene") Netze!

Was macht ein VPN bzw. was kann es?

Wie oben beschrieben lassen sich örtlich getrennte Netzwerke nicht nur über Kabel und WLAN verbinden, sondern auch virtuell.
Eine Software, z.B. Dienstprogramme für IPSec oder OpenVPN, baut dazu eine hochgradig verschlüsselte Verbindung über das öffentliche Netz (Das Internet) auf und lenken jeglichen Datenverkehr, der für das Teilnetz auf der anderen Seite bestimmt ist, durch den so entstandenen "Tunnel".
Für die Benutzer und Programme auf beiden Seiten des Tunnels ist dieser Vorgang vollkommen transparent, d.h. wenn Ihr im Teilnetz 192.168.10.x sitzend eine Maschine im entfernten Teilnetz 192.168.11.x erreichen wollt, dann tut Ihr das einfach durch Angabe der Zieladresse, z.B. beim Öffnen des OpenWebif auf http://192.168.11.20.
Es ist die VPN-Software - idealerweise auf dem Router laufend - die dann erkennt, daß dieses Netzwerk nicht direkt verbunden ist sondern durch den VPN-Tunnel erreicht wird, den Netzwerkverkehr durch den Tunnel lenkt und die zurückkommenden Antworten wieder in Eurer Netzsegment einspeist.

Man sieht an der Beschreibung schon:
- bei der Einrichtung werden wir uns auch ein klein wenig mit dem Routing beschäftigen müssen (Was uns bei SSH völlig egal war)
aber
- bei der Benutzung ist es simpler, denn solange der Tunnel steht nutzt Ihr ganz normal z.B. die o.g. Beispiel-Adresse http://192.168.11.20 auch von Eurem Zuhause aus, als wenn Ihr ein Notebook mitnehmt und im Netz der Eltern betreibt

VPNs werden z.B. auch verwendet
- für Home-Offices, damit der Mitarbeiter zuhause Zugriff auf Daten aus dem Firmennetz hat, ohne daß diese im Internet preisgegeben werden müssen
- an Universitäten/Hochschulen, damit auch Studenten die nicht in Wohnheimen mit Hochschulanschluß wohnen Zugriff auf das Campus-Netzwerk haben


Begriffsdefinition

Man unterscheidet VPNs überwiegend in die folgenden beiden Varianten:

Site-2-Site oder LAN-2-LAN-Kopplung
Dabei werden zwei komplette Netzwerke miteinander verbunden, so daß jede Maschine in dem einen Netzwerk jede Maschine des anderen Netzwerkes ansprechen kann.

Beispiel:
Ihr habt eine eigene Wohnung und darin ein Netzwerk 192.168.10.x, Eure Eltern wohnen ganz woanders, haben aber auch ein eigenes Netzwerk 192.168.11.x.
Nach Errichtung einer LAN-2-LAN-Kopplung könntet Ihr von zuhause aus auf jedes Gerät im Netzwerk der Eltern zugreifen und umgekehrt genauso.


Road Warriors ("Straßenkämpfer")
Hierbei verbindet sich ein einzelnes Gerät (Also der Road Warrior) - z.B. das eigene Smartphone, Tablet, Notebook, ... - von außerhalb in das heimische Netzwerk und kann danach alle Dienste daraus auch von unterwegs nutzen.

Andere Geräte im selben Netzwerk wie der Road Warrior kriegen davon nichts mit und erlangen auch keinen Zugriff auf das Heimnetz (Wäre ja auch noch schöner, wenn Ihr an einem WLAN-Hotspot wildfremden Leuten den Zugriff auf Euer Heimnetz gewähren würdet, nur weil Ihr Euch mit eurem Handy dorthin verbindet ;) ).

Entsprechend dieser beiden Möglichkeiten werdet Ihr später auch vor der Entscheidung stehen, was von beidem Ihr wollt.



Wichtige Überlegungen vorab

Eine der größten Geißeln von IPv4 betrifft uns unmittelbar bei der Errichtung eines VPN: Der Adressmangel!
TCP/IP funktioniert derart, daß jedes Gerät eine eindeutige IP-Adresse besitzt. Das ist bei IPv4 aber schon ewig nicht mehr der Fall, fast jedem Heimnetz stehen nur die privaten Adressbereiche 192.168/16, 172.16/12 und/oder 10/8 zur Verfügung.
Der weitaus größte Teil aller Heimnetze nutzt Adressen aus dem kleinsten dieser Bereiche, nämlich 192.168/16, also z.B. 192.168.178.x (Standardbereich bei Fritz!Boxen), 192.168.1.y oder 192.168.0.z (Standardbereiche der meisten anderen Router).
Normalerweise juckt es uns auch nicht, daß wir dieselben Adressen nutzen wie noch 20 Nachbarn von uns, da die Geräte aus diesen Netzen i.d.R. niemals direkt miteinander kommunizieren müssen.
Gegenüber dem Internet erscheint unser komplettes Heimnetz als ein einziges Gerät mit einer einzigen IPv4: Der, die der Internet-Providers unserem Router zuweist.

Wenn wir einen VPN-Zugang einrichten, kommen aber plötzlich meistens doch solche privaten Adressbereiche in Berührung, nämlich mindestens
- der Adressbereich unseres Heimnetzes
und
- der Adressbereich des Heimnetzes des Bekannten/Verwandten, aus dessen Netz wir auf unser Netz zugreifen wollen - oder - das CGNAT im Mobilfunk

Ein VPN zu unserem Heimnetz wird nicht - bzw. nur mit erheblichen Klimmzügen - funktionieren, wenn sowohl zuhause das Netzwerk 192.168.178.x verwendet wird, als auch in dem Netzwerk, in dem wir uns beim Aufbau befinden:
Der Webbrowser Eures Smartphones kann z.B. beim Aufruf der IP 192.168.178.25 schlichtweg nicht wissen, ob Ihr Eure heimische vusolo4k mit dieser IPv4 meint oder das Notebook Eures Onkels mit derselben IPv4 in seinem Haus.

Das Problem ist aber nicht nur auf die unmittelbar in Verbindung stehenden Netzwerke beschränkt, sondern erstreckt sich auch auf alle weiteren Netzwerke, die mit einer der beiden Seiten bereits in Kontakt stehen.
Angenommen Ihr habt zuhause das Netzwerk 192.168.178.x gewählt und habt dort bereits eine LAN-2-LAN-VPN-Kopplung mit einem Netzwerk 192.168.1.y, dann wird es für Euch unterwegs sowohl in LANs mit dem Adressbereich 192.168.178.x als auch in LANs mit dem 192.168.1.x zu Problemen kommen! Euer Router zuhause kann dann nämlich nicht wissen, ob die IPv4 192.168.1.40 (Einfach nur als Beispiel) in das eine oder das andere der beiden Netze mit demselben Adressbereich gehört.

Damit aber nicht genug, denn Ihr steht darüber hinaus oft auch noch unbewußt mit weiteren privaten Adressbereichen in Kontakt!
Oft liest man von den ganz cleveren Leuten, daß sie aus den vorgenannten Gründen zuhause einen Adressbereich aus dem Bereich 10/8, also z.B. 10.173.5.x verwenden, weil dieser ja sonst kaum von jemandem benutzt wird.
Wenn Ihr Euch aber z.B. mit "Network Info II" auf Eurem Smartphone anguckt, was für eine Adresse Ihr im Mobilfunk bekommt, werden Ihr feststellen, daß es eine aus eben diesem Adressbereich ist ...
Darüber hinaus wird dieser Adressbereich auch von den dt. Kabelnetzbetreibern zwischen Kabel-Modem und CMTS (Grob vereinfacht die "Kopfstation") verwendet.

Was folgern wir nun daraus?
Um das VPN in möglichst vielen fremden Netzen störungsfrei aufbauen zu können, sollte unser Heimnetz keinen der völlig überlaufenen Adressbereiche nutzen

Meidet auf jeden Fall:
192.168.0.x (Standardbereich vieler Router)
192.168.1.x (Standardbereich vieler Router)
192.168.100.x (Wird von Bridges verwendet, z.B. Kabel-Modems und Medien-Konvertern (Glasfaser) )
192.168.178.x (Standardbereich der Fritz!Boxen)
192.168.179.x (Gastnetz der Fritz!Boxen)

Und von
10.x.y.z halte ich aus dem vorgenannten Grund (Mobilfunk, Kabel-Anschluß) auch nicht viel.

Ich bin inzwischen dazu übergegangen, das Geburtsjahr des Hauptnutzers zu nehmen oder die Quersumme aus dem Geburtsdatum zu bilden oder sonst irgendwas, mit dem eine möglichst krumme Zahl ungleich 0, 1, 100, 178 und 179 rauskommt, und im Bereich 192.168/16 zu bleiben.
Aus dem 23.5.[19]78 würde z.B. 23+5+78 = 106, 192.168.106.x ist zumindest schon mal ungebräuchlicher als 192.168.1.x

Eine weitere Möglichkeit besteht in der Nutzung des Adressbereich 172.16/12, also der Bereich von 172.16.0.0 - 172.31.255.255. Diesen Bereich nutzen wirklich die allerwenigsten. Das Tolle ist, man kann auf jeden Fall z.B. seinen Geburtsmonat auf die 16 draufrechnen und erhält damit 17 für Januar, 18 für Februar, 19 für März, ... 28 für Dezember.

Diese Überlegungen solltet Ihr auf jeden Fall anstellen bevor Ihr Euer VPN einrichtet und ggf. vorher schon Euer Heimnetz entsprechend modifiziern, da die verwendeten IPs auch in die VPN-Konfiguration einfließen.
Nichts wäre ärgerlicher, als nach der ganzen Konfiguriererei festzustellen, daß nicht viel geht, wenn Ihr sowohl beim Onkel als auch zuhause dieselben IPs nutzt ...

Ein Hinweis dazu am Rande: Spätestens wenn Ihr mit der Fritz!Box selber eine LAN-2-LAN-Kopplung einrichten wollt, wird Euch diese dazu zwingen, sogar auf beiden Seiten ein anderes Netz als 192.168.178.x einzustellen.[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#13

Beitrag von SpaceRat »

[align=center]2.2: VPN - Virtual Private Network - IPsec (AVM Fritz!Box und viele andere)

Wenn Ihr eine Fritz!Box bzw. bei einer Site-2-Site-Kopplung auf beiden Seiten Fritz!Boxen habt, dann habt Ihr an dieser Stelle schon fast gewonnen.
Voraussetzung ist eigentlich nur noch, daß Euer Anschluß zuhause noch über eine öffentliche IPv4 verfügt, IPv6 (z.B. bei DS-lite) wird immer noch nicht unterstützt.

Auf die Einrichtung eines VPNs mit der Fritz!Box werde ich so gut wie gar nicht eingehen und zwar einfach, weil ich nicht jedes Rad neu erfinden muß.

AVM hat die Einrichtung bereits hervorragend beschrieben und auf diese Beschreibungen möchte ich hier einfach verweisen:
AVM - VPN Service

Dort findet Ihr detaillierte, bebilderte und leicht verständliche Beschreibungen ...

... für "Road Warrior"-Einrichtungen:
VPN-Verbindung zur FRITZ!Box unter Android einrichten
VPN-Verbindung zur FRITZ!Box unter Apple OS ("iOS") einrichten
VPN-Verbindung zur FRITZ!Box unter Blackberry OS einrichten
VPN-Verbindung zur FRITZ!Box mit Shrew-Soft VPN-Client unter Windows 10 einrichten
VPN-Verbindung zur FRITZ!Box unter Windows einrichten (Fritz!Fernzugang)
VPN-Verbindung zur FRITZ!Box unter Apple macOS einrichten
VPN-Verbindung zur FRITZ!Box unter Linux einrichten

... für LAN-2-LAN-Kopplungen:
VPN-Verbindung zwischen zwei FRITZ!Box-Netzwerken einrichten
VPN-Verbindung zwischen drei oder mehr FRITZ!Box-Netzwerken einrichten
FRITZ!Box als VPN-Client mit anderer FRITZ!Box verbinden (Zugriff nur in einer Richtung möglich)

Tips:
Mit der aktuellen MyFritz!-App läßt sich ein VPN mit einem Finger-Tippen direkt aus der App einrichten.
Bewegung bei den FRITZ!Apps – MyFRITZ!App runderneuert

Die Verwendung eines VPNs zur Fritz!Box statt Portfreigaben auf den Receiver macht nicht nur Euren Zugang zu Eurer E2-Box sicher, sondern eröffnet noch viele weitere Möglichkeiten:
Ihr könnt von unterwegs aus sehen wer zuhause angerufen hat, Ihr könnt von unterwegs Faxe über die Fritz!Box empfangen oder senden, auf dem heimischen Drucker drucken, ....
... ja, Ihr könnt sogar unterwegs über den heimischen Festnetzanschluß erreichbar bleiben/telefonieren, wenn Ihr auch MyFritz!Fon oder einen anderen SIP-Client auf dem Smartphone installiert.
Die erstaunten Blicke der Eltern, wenn man mit der heimischen Festnetznummer dort anruft, um mitzuteilen, daß man am Urlaubsort angekommen ist, kann man sogar hören![/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#14

Beitrag von SpaceRat »

- Reserve -
Receiver/TV:
  • Vu+ Ultimo 4k 4xDVB-S2 FBC / 2x-C / 5.5TB / OpenATV 6.4@LG 65" OLED
  • Gigablue Quad 4k 2xDVB-S2 / 2x-C / 1.8TB GB / OpenATV 6.4@Samsung 37" LED
  • diverse weitere
  • S2-Twin-Tuner PCIe@Samsung SyncMaster T240HD (PC)
  • TechniSat SkyStar HD 2 (2.PC)
Pay-TV: Schwarzfunk, Redlight HD Mega, HD-, Sky
Internet: Unitymedia 2play 400 + Telekom VDSL100 / Linksys WRT1900ACS / IPv4 (UM) + IPv6 (Hurricane Electric+UM+Telekom)
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#15

Beitrag von SpaceRat »

[align=center]2.3: VPN - Virtual Private Network - OpenVPN (Praktisch überall verfügbar)

OpenVPN ist eine frei verfügbare, quelloffene Software für den Aufbau von VPNs
und zwar sowohl für Site-2-Site-Kopplungen als auch für "Road Warrior"-Szenarien.

Im Gegensatz zu AVMs auf IPSec-basierender VPN-Lösung unterstützt OpenVPN auch IPv6 und kann über Port-Proxies weitergeleitet werden, so daß auch ein DS-lite-Anschluß dem Einsatz nicht im Wege steht.

Als Verschlüsselungsverfahren kommt wie bei SSH i.d.R. ein asymetrisches Kryptosystem, also Schlüsselpaare, zum Einsatz.
OpenVPN ist nahezu überall verfügbar, also z.B. auch auf Android-Smartphones, Apple EiFons, Windows, diversen Routern, usw. usf. und eben auch auf unseren E2-Boxen selbst, so daß im Endeffekt jeder die Möglichkeit hat, ein VPN mittels OpenVPN zu errichten.

Die Ersteinrichtung gestaltet sich für den Laien vergleichsweise aufwendig, es gibt aber diverse Hilfsprogramme, die das Leben etwas erleichtern.

Grundsätzlicher Aufbau des Kryptosystems:
Es gibt eine zentrale Autorität (Root Authority), von welcher dann alle Server- und Client-Zertifikate ausgestellt/signiert und damit gültig gemacht werden.

(Diese Zentralgewalt werden wir auch noch einmal benötigen, wenn wir Zertifikate für HTTPS im OpenWebif erstellen!)

Sowohl diese "Zentralgewalt" als auch alle Server- und Clientzertifikate können sowohl unter Windows als auch Linux erzeugt werden.
Um möglichst wenig Zusatzanforderungen an Euer Equipment zu stellen, werde ich versuchen, so viele Schritte wie möglich auf der E2-Box selber durchführen zu lassen, da Ihr ja alle eine E2-Box habt, aber nicht alle die gleichen Betriebssysteme auf PCs/Notebooks, ...

Der Einfachheit halber verzichte ich auch auf eine hierarchische Struktur (Zentralgewalt -> Server-Verwaltung -> OpenVPN-Server -> OpenVPN-Clients), es werden alle Zertifikate direkt von der Zentralgewalt ausgestellt.[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#16

Beitrag von SpaceRat »

[align=center]Erzeugen der Zertifikate

Im Anhang liefere ich Euch (Wenn dieser Artikel fertig ist) ein paar Hilfsdateien, die Euch das Leben einfacher machen sollen.

Für dieses Tutorial werde ich davon ausgehen, daß Ihr die Schritte auf der E2-Box ausführt und schlage daher vor, in /etc/enigma2 einen Unterordner "Certs" anzulegen, dorthin entpackt Ihr auch mein ZIP-Archiv mit den Beispiel- und Grund-Konfigurationen.
An dieser Stelle angelegt wird dieser Ordner nämlich bei der Sicherung der Einstellungen automatisch mit gesichert, ist also flashfest.


"Root Authority" erzeugen (Alle 39 Monate)

Wechselt in das Verzeichnis "/etc/enigma2/Certs" und erzeugt einen 4096-Bit-Schlüssel:

Code: Alles auswählen

cd /etc/enigma2/Certs
openssl genrsa -out ca.key 4096

Auf aktuellen Boxen dauert dieser Vorgang ca. 1 Minute, auf alten Tierchen kann es auch mehrere Minuten dauern.


Erzeugt nun einen "Antrag auf Signierung" (Certificate Signing Request):

Code: Alles auswählen

openssl req -config Configs/ca.config -sha256 -new -key ca.key -out ca.csr -sha256


Nach Eingabe dieses Befehls sollt Ihr verschiedene Fragen beantworten, nämlich zuerst nach
- dem Ländercode (Das wäre "DE" für Deutschland, "CH" für die Schweiz, "AT" für Österreich, usw.)
- dem Land (Im Sinne von Bundesland, also z.B. "North Rhine-Westphalia", "Lower Saxony", "Free and Hanseatic City of Hamburg", "Bremen", ...)
- der Stadt, z.B. "Heiliges Köln, von Gottes Gnade der römischen Kirche getreue Tochter"

Diese Fragen müssen nicht wahrheitsgemäß beantwortet werden, die obigen Texte zeigen Euch nur, wie sie im professionellen Umfeld dann auch ausgefüllt würden ... naja, bis auf mein Beispieltext für Köln :)


Im weiteren Verlauf werden Ihr auch gefragt nach:
"Organization Name (eg, company)"
ATVCert habe ich in der Beispielconfig voreingetragen, das solltet Ihr aber nicht übernehmen.
Was Ihr hier eintragt, sehr Ihr immer wieder im Browser oder Log als ausstellende Autorität für das Zertifikat.
Für den schnelleren Überblick sollte das also ein Name sein, der für jeden von Euch eindeutig ist, damit Ihr Eure Zertifikate schon auf den ersten Blick von denen eins Kumpels unterscheiden könnt.

Nehmt irgendwas a la "Euer Spitzname zu Schulzeiten" plus Cert oder Sign, das sieht professionell aus (Wenn der Spitzname nicht gerade "Dumme Kuh" war) und ist am Ende auch relativ wahrscheinlich eindeutig.


Organizational Unit Name (eg, section)
Hier ist "CA Root" voreingestellt und das könnt Ihr auch übernehmen. Innerhalb der soeben erzeugten Organisation seid Ihr jetzt in der Abteilung ("Unit") "CA Root Authority", also Schlüsselverwaltung :)


Common Name (e.g. server FQDN or YOUR name)
Auch hier einfach die Voreinstellung "CA Root Admin" lassen. Ihr seid ja schließlich der oberste Torwächter der Abteilung :)


Email Address []:
Kann leer bleiben. Ihr als Schlüsselverwalter werdet Euch wohl kaum selber eine eMail mit Rückfragen zu dem Antrag schicken wollen ;)


Da Ihr wohl kaum viel Geld ausgeben wollt, damit Euch VeriSign o.ä. das Zertifikat signieren, signiert Ihr Euren eigenen Antrag einfach selber (Deshalb heißen diese Zertifikate auch "self-signed certificates"):

Code: Alles auswählen

openssl x509 -days 1170 -extfile Configs/ca.ext -sha256 -signkey ca.key -in ca.csr -req -out ca.crt -sha256

Ein solches "selbstsigniertes Zertifikat" hat den Nachteil, daß es für Euren und fremde Browser nicht automatisch vertrauenswürdig ist, aber dem kann man Abhilfe schaffen.
Was tut man nicht alles, um ein paar Tausend Dollar zu sparen ;)

Nach diesen Schritten solltet Ihr die folgenden drei Dateien in /etc/enigma2/Certs haben:
ca.key - Der Schlüssel Eurer CA Root Authority
ca.csr - Der Antrag auf Zertifizierung, wird eigentlich nicht weiter benötigt
ca.crt - Das erstellte, selbst-signierte Zertifikat

Abschließend legen wir noch einen Zähler für unsere Zertifikate an:

Code: Alles auswählen

echo 00 > ca.serial
[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#17

Beitrag von SpaceRat »

[align=center]Server-Zertifikat erzeugen (Alle 39 Monate)

Bisher haben wir nur eine "CA Root Authority", also quasi unsere eigene "Passbehörde".
Für unsere(n) Server an sich und dessen Clients müssen wir die Pässe erst noch ausstellen.
Das Zertifikat für den Server stellen wir in diesem Schritt aus.

Paßt zuerst einmal die Datei /etc/enigma2/Certs/Configs/server.config für Euch an.

Anzupassen ist hier der Abschnitt

Code: Alles auswählen

[ req_DN ]
C                      = DE
ST                     = North Rhine-Westphalia
L                      = Cologne
O                      = OpenATV Inc.
OU                     = Servers

wo Ihr analog zu den Ausführungen zur CA Root Authority Euren Standort (C = Country, ST = State = Bundesland, L = Location = Stadt) anpassen und einen Namen für Eure "Organisation" (O) festlegen könnt.
Die "Organizational Unit", also "Abteilung" kann ruhig "Servers" bleiben.

Diese Anpassung braucht Ihr nur ein einziges Mal für alle Server zu machen.



Im zweiten Schritt kopiert Ihr Euch - insbesondere wenn Ihr mehrere Boxen habt - die Beispielconfigs
/etc/enigma2/Certs/Configs/Box.config
und
/etc/enigma2/Certs/Configs/Box.ext
auf den Hostname oder die Hostnames Eurer Box um (Das ist so nicht zwingend, aber es erhöht die Übersicht).

Für eine Vu+ Solo 4k würde sich also anbieten

Code: Alles auswählen

cp /etc/enigma2/Certs/Configs/Box.config /etc/enigma2/Certs/Configs/vusolo4k.config
cp /etc/enigma2/Certs/Configs/Box.ext /etc/enigma2/Certs/Configs/vusolo4k.ext

auszuführen.

Danach öffnet Ihr die Kopien mit einem Editor, z.B. nano oder mcedit auf der Box oder notepad++ unter Windows und paßt sie an:

In der .config ist lediglich der "Canonical Name" anzupassen, hier empfehle ich, einfach den Namen der Box in ordentlich lesbar einzutragen, für eine Vu+ Solo4k würde die Datei also so aussehen:

Code: Alles auswählen

CN              = Vu+ Solo4k


Aufwendiger gestaltet sich die *.ext, hier sollten sämtliche Hostnames (incl. DynDNS-Hosts!) und IP-Adressen zusammengetragen werden, die die Box haben kann.

Ich habe das mal am Beispiel einer Vu+ Solo4k hinter einer Fritz!Box eingetragen, die sowohl einen klassischen DynDNS-Host für die Fritz!Box selber bzw. IPv4-Portweiterleitungen pflegt (spacerat.mooo.com) als auch einen MyFritz-Namen (abcdefghijklmnop.myfritz.net) für die Box selber bzw. IPv4-Portweiterleitungen.
Zusätzlich gibt es noch DynDNS- und MyFritz-Hosts für die E2-Box selber (vusolo4k.mooo.com und vusolo4k.abcdefghijklmnop.myfritz.net).
Außerdem sind sämtliche (Kurz-)Schreibweisen des Hostnames angegeben, unter denen die Box im Heimnetzwerk erreichbar ist (vusolo4k.fritz.box und alle möglichen Auslassungen dazu).
Ferner ist im Heimnetz jedes Gerät auch unter "Hostname.local" erreichbar, hier also vusolo4k.local

Bei den IP-Adressen gilt, daß Ihr bitte nur die eintragt, die die Box immer wieder bekommt:
- die private IPv4-Adresse im LAN (Hier im Beispiel 192.168.10.15) z.B. oder
- die IPv6 mit ULA-Präfix (fdff:affe:c0c0:1337:21d:ecff:fe12:3456)
- die link-lokale IPv6 (fe80::21d:ecff:fe12:3456)

Wechselnde IP-Adressen (z.B. Eure aktuelle öffentliche IPv4 oder die globale IPv6 bei wechselndem Präfix) tragt Ihr [b]nicht ein.[/B]

Im Beispiel habe ich zwar eine globale IPv6 (2001:db8:dead:beef:21d:ecff:fe12:3456) eingetragen, ich nutze aber auch eine Tunnel-Anbindung und habe daher wirklich feste IPv6-Adressen.

Wenn Ihr hier einen Hostname oder eine IP-Adresse vergeßt und ruft dann später die Box ausgerechnet mit dem ausgelassenen Hostname oder der ausgelassenen IP auf, wird es eine Warnung geben, daß das Zertifikat für diesen Server nicht gültig ist!
Auch deshalb sollte man sich den Blödsinn abgewöhnen, Geräte über ihre IP aufzurufen, denn ob es einige hören wollen oder nicht, IPv6 kommt und dann sind IPs eh viel zu lang zum Merken und an den meisten Privatanschlüssen ändern sie sich auch regelmäßig ...


Code: Alles auswählen

[ alt_names ]
DNS.1    = spacerat.mooo.com
DNS.2    = vusolo4k.mooo.com
DNS.3    = abcdefghijklmnop.myfritz.net
DNS.4    = vusolo4k.abcdefghijklmnop.myfritz.net
DNS.5    = vusolo4k.fritz.box
DNS.6    = vusolo4k.box
DNS.7    = vusolo4k
DNS.8    = vusolo4k.local
IP.1     = 192.168.10.15
IP.2     = 2001:db8:dead:beef:21d:ecff:fe12:3456
IP.3    = fdff:affe:c0c0:1337:21d:ecff:fe12:3456
IP.4    = fe80::21d:ecff:fe12:3456


Zeilen für Hostnames beginnen mit "DNS." und einer fortlaufenden Nummerierung, Zeilen für IP-Adressen mit "IP." und ebenfalls einer für sich fortlaufenden Nummerierung.
Diese Anpassungen braucht Ihr je Box auch nur ein einziges Mal zu machen, solange sich bei Euren DynDNS-Hosts oder den im LAN verteilten IP-Adressen nichts ändert.



Nachdem Ihr die Dateien wie beschrieben angepaßt habt, könnt Ihr das Server-Zertifikat erzeugen:

0. Ggf. ins Verzeichnis mit den Configs wechseln, wenn Ihr noch nicht dort seid:

Code: Alles auswählen

cd /etc/enigma2/Certs/Configs


1. Teil-Configs zusammenkopieren ...

Code: Alles auswählen

cat server.config > TempServer.config
cat vusolo4k.config >> TempServer.config

(In der zweiten Zeile ersetzt Ihr natürlich vusolo4k.config durch den zu Eurer eigenen Box passenden Dateinamen der im vorherigen Schritt angepaßten .config-Datei)

2. Teil-Exts zusammenkopieren ...

Code: Alles auswählen

cat server.ext > TempServer.ext
cat vusolo4k.ext >> TempServer.ext

(In der zweiten Zeile ersetzt Ihr natürlich vusolo4k.ext durch den zu Eurer eigenen Box passenden Dateinamen der im vorherigen Schritt angepaßten .ext-Datei)

3. Zurückwechseln nach /etc/enigma2/Certs

Code: Alles auswählen

cd /etc/enigma2/Certs


4. Erzeugen des Schlüssels:

Code: Alles auswählen

openssl genrsa -out vusolo4k.key 4096


5. Erzeugen des Zertifikat-Antrages:

Code: Alles auswählen

openssl req -config Configs/TempServer.config -sha256 -new -key vusolo4k.key -out vusolo4k.csr -sha256


6. Signieren des Zertifikats durch unsere CA Root Authority:

Code: Alles auswählen

openssl x509 -days 1170 -extfile Configs/TempServer.ext -sha256 -CA ca.crt -CAkey ca.key -CAserial ca.serial -in vusolo4k.csr -req -out vusolo4k.crt -sha256


Am Ende dieses Schrittes solltet Ihr die folgenden drei neuen Dateien im Verzeichnis /etc/enigma2/Certs haben:
vusolo4k.key - Schlüssel des Servers vusolo4k
vusolo4k.crt - Von unserer CA Root Authority signiertes Zertifikat des Servers vusolo4k
vusolo4k.csr - Der Antrag auf ein Zertifikat für den Server vusolo4k, wird nicht mehr unbedingt gebraucht


Für jeden weiteren Server, also jede weitere E2-Box, würdet Ihr diese Schritte wiederholen.
Ihr könnt auf diese Weise natürlich genausogut auch Server-Zertifikate für andere Server, z.B. einen Router mit OpenVPN, erzeugen!

Wenn Ihr die Zertifikate für OpenVPN erstellt, ist es in der Regel überflüssig, mehrere Server anzulegen, ein OpenVPN-Server im Heimnetz reicht völlig.
Für den Zugriff per HTTPS auf das OpenWebif hingegen benötigt jede Box ihr eigenes Zertifikat.
[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#18

Beitrag von SpaceRat »

[align=center]Client-/User-Zertifikat(e) erzeugen (Alle 39 Monate)

Für den Zugriff auf einen OpenVPN-Server benötigt auch jeder Client sein eigenes Zertifikat.
Bei der Verwendung für HTTPS in OpenWebif sind Client-/User-Zertifikate optional und können dort die Anmeldung ersetzen (ToDo).


Zuerst einmal ist auch hier eine Konfigurations-Datei zu kopieren und anzupassen und zwar die Datei "user.config".

Beispiel:

Code: Alles auswählen

cp /etc/enigma2/Certs/Configs/user.config /etc/enigma2/Certs/Configs/smartphone.config


Ihr benötigt so viele Benutzer und damit Kopien der user.config, wie Ihr individuelle Zugänge zu Eurem OpenVPN- (oder OpenWebif-)Server braucht.
Wenn Ihr z.B. von Eurem Smartphone, Tablet und Notebook ggf. gleichzeitig zugreifen können wollt, solltet Ihr auch (mindestens) drei User anlegen, usw.

Danach öffnet Ihr die Kopie(n) mit einem Editor, z.B. nano oder mcedit auf der Box oder notepad++ unter Windows und paßt sie an:

Code: Alles auswählen

[ req ]
default_bits       = 4096
distinguished_name = req_DN
string_mask        = nombstr
prompt             = no

[ req_DN ]
C                      = DE
ST                     = North Rhine-Westphalia
L                      = Cologne
O                      = OpenATV Inc.
OU                     = Clients
CN                     = OpenATV User
emailAddress           = openatv.user@foo.bar


Hier bietet es sich an, jeden Benutzer an irgendeiner Stelle zu individualisieren, z.B. unter CN ("Canonical Name") einzutragen
- Fritz Smartphone
- Fritz Tablet
- Fritz Notebook
- Anna Smartphone
usw.

Nachdem Ihr die Datei(en) wie beschrieben angepaßt habt, könnt Ihr das oder die Client-Zertifikat(e) erzeugen:

1. Zurückwechseln nach /etc/enigma2/Certs

Code: Alles auswählen

cd /etc/enigma2/Certs


2. Erzeugen des Schlüssels:

Code: Alles auswählen

openssl genrsa -out smartphone.key 4096


3. Erzeugen des Zertifikat-Antrages:

Code: Alles auswählen

openssl req -config Configs/smartphone.config -sha256 -new -key smartphone.key -out smartphone.csr


4. Signieren des Zertifikats durch unsere CA Root Authority:

Code: Alles auswählen

openssl x509 -days 1170 -extfile Configs/user.ext -CA ca.crt -CAkey ca.key -CAserial ca.serial -in smartphone.csr -req -out smartphone.crt


Am Ende dieses Schrittes solltet Ihr die folgenden drei neuen Dateien im Verzeichnis /etc/enigma2/Certs haben:
smartphone.key - Schlüssel des Clients smartphone
smartphone.crt - Von unserer CA Root Authority signiertes Zertifikat des Clients smartphone
smartphone.csr - Der Antrag auf ein Zertifikat für den Client smartphone, wird nicht mehr unbedingt gebraucht


Für jeden weiteren Client würdet Ihr diese Schritte wiederholen.
[/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#19

Beitrag von SpaceRat »

[align=center]2.2.x: VPN - Virtual Private Network - OpenVPN Server-Config

Nachdem wir nun alle Zertifikate beisammen haben, können wir uns an das Erstellen einer Server-Config machen.

Es gibt unzählige Möglichkeiten zur Konfiguration, von denen ich nicht auf alle eingehen kann.
Stattdessen werde ich nur zwei Varianten zeigen, nämlich
- einen Road-Warrior-Zugang (Für beliebig viele Road Warrior)
- eine Site-2-Site-Kopplung
und das so allgemeintauglich wie möglich.

OpenVPN benötigt für eine komplette Server-Config auch noch sogenannte Diffie-Hellman-Parameter (Etwas Primzahlen-Rechnerei), das erledigen wir direkt mal als erstes und am besten in einer zweiten Telnet/SSH-Sitzung zur Box, denn dieser Vorgang dauert recht lange.
Gebt dazu die folgenden zwei Befehle ein:

Code: Alles auswählen

cd /etc/enigma2/Certs
openssl dhparam -out dh2048.pem 2048


Danach solltet Ihr erst einmal das Paket openvpn nachinstallieren, sofern noch nicht geschehen:

Code: Alles auswählen

opkg install openvpn


Konfiguration eines OpenVPN-Servers für Road Warriors

Als nächstes ladet Ihr Euch die Grundkonfiguration aus meinem Archiv und paßt sie an Eure Bedürfnisse an.
Die Grundkonfiguration für Road Warriors liegt in /etc/enigma2/Certs/VPN/rwserver.base und sieht wie folgt aus:

Code: Alles auswählen

port 12345
ifconfig 172.16.107.1 255.255.255.0
ifconfig-pool 172.16.107.200 172.16.107.254 255.255.255.0
push "dhcp-option DNS 192.168.107.1"
push "route 192.168.107.0 255.255.255.0"
push "route 172.16.107.0 255.255.255.0"
push "route-gateway 172.16.107.1"
dev tun
comp-lzo yes
mssfix 1420
verb 1
keepalive 10 60
client-to-client 1
float 1
persist-tun 1
tls-server 1
cipher BF-CBC
mode server
proto tcp6-server
topology subnet
log /var/log/openvpn.log
push "topology subnet"
push "comp-lzo yes"
script-security 2
up /etc/openvpn/up.sh
[/align]
Änderungen sind in den ersten 7 Zeilen durchzuführen:
  • port 12345
    Der Port, auf dem OpenVPN später laufen/reagieren soll.
    Wenn Ihr zuhause DS-lite habt und somit für Zugriffe aus IPv4-only-Netzen auf Dienste wie feste-ip.net oder myonlineportal.net angewiesen seid, dann sollte dieser Port so wild zufällig wie möglich gewählt sein.
    Alle (ungenutzten) Ports zwischen 1 und 65535 sind möglich.
    Wenn das OpenWebif nicht auf Port 443 läuft, könnt Ihr unter Umständen mit Port 443 für OpenVPN sogar dann eine Verbindung aufbauen, wenn das Netz unterwegs eigentlich nur Webseiten-Aufrufe gestattet.
    Bei einfachen Routern basiert die Sperre "Nur Web" sowieso nur auf dem Zielport und selbst mit DPI (Deep Packet Inspection) ist noch lange nicht jeder Router/jede Firewall in der Lage, verschlüsselten HTTPS-Traffic von verschlüsseltem VPN-Traffic zu unterscheiden :)

    Für den Port, den Ihr hier wählt, braucht Ihr in Eurem Router
    - bei IPv4 eine Port-Weiterleitung zu der E2-Box, auf der der OpenVPN-Server laufen soll
    und/oder
    - bei IPv6 eine Port-Freigabe/Firewall-Ausnahme für die Adresse der E2-Box mit dem OpenVPN-Server und diesen Port

    Bei Fritz!Boxen empfehle ich, stattdessen eine MyFritz-Freigabe zu erstellen, die macht beides gleichzeitig und Ihr erhaltet zusätzlich auch einen DynDNS-Host für die Box (boxname.blablablabla.myfritz.net).
    (Netzwerkgerät: Eure E2-Box; Anwendung: "Andere Anwendung"; Bezeichnung: Freitext, z.B. "OpenVPN"; Schema: Egal, aber "Manuelle Eingabe" und "ovpn://" sieht am sinnigsten aus; Port: Der hier gewählte Port; Verzeichnis: leer lassen)
  • ifconfig 172.16.107.1 255.255.255.0
    Die Adresse des OpenVPN-Servers und dessen Subnet.
    Dies ist ein zusätzlicher Adressbereich, der zwischen OpenVPN-Server und OpenVPN-Clients benutzt wird, also keinesfalls denselben Adressbereich wie für Euer Heimnetz nutzen!
    Ich nutze wohl - wie auch in der Konfigurations-Vorlage - meistens einen "ähnlichen" Bereich, also wenn das Heimnetz 192.168.107.x hat, dann kriegt OpenVPN hier 172.16.107.x.

    Es geht aber auch jeder andere - noch nicht anderweitig genutzte - Adressbereich aus den privaten Adressbereichen 10/8, 172.16/12 oder 192.168/16
  • ifconfig-pool 172.16.107.200 172.16.107.254 255.255.255.0
    Aus welchem Adressbereich sollen die OpenVPN-Clients Adressen beziehen?

    In diesem Beispiel erhalten die Clients je genau eine IPv4 aus dem Bereich von 172.16.107.200 bis 172.16.107.254, insgesamt also 55 mögliche Adressen und damit auch 55 mögliche Clients.
    Diese Adressen müssen im selben Subnet liegen wie in Zeile 1 angegeben.
  • push "dhcp-option DNS 192.168.107.1"
    OpenVPN wird den Clients mitteilen, daß sie bei bestehender Verbindung den DNS-Server 192.168.107.1 nutzen sollen.

    Wenn Euer Router zuhause lokale Namensauflösung kann, solltet Ihr ihn auch hier eintragen, damit Ihr vom VPN-Client aus auch mittels Hostname auf Eure Geräte zuhause zugreifen könnt.
    http://quadbox2400 ist einfach griffiger als http://192.168.107.28

    Wenn Ihr einen Schrottrouter habt der das nicht kann (Da ist mir eigentlich nur Unitymedias Elektroschrott Technicolor TC7200 bekannt), dann löscht Ihr diese Zeile ganz.
  • push "route 192.168.107.0 255.255.255.0"
    Den Clients wird mitgeteilt, daß sie das Netzwerk 192.168.107.0 mit der Netmask 255.255.255.0 durch den VPN-Tunnel erreichen können.
    Ändert also 192.168.107.0 passend zu Eurem Heimnetz.

    Tip: Wenn Ihr von Eurem Heimnetz aus bereits LAN-2-LAN-Kopplungen zu anderen Netzen habt, dann könnt Ihr diese Zeile auch duplizieren und den Clients somit auch Zugriff auf die bereits verbundenen Netzwerke einräumen.
    Ihr braucht dann nicht zwischen den VPN-Verbindungen zu springen, um mal das eine und mal das andere entfernte Netz zu erreichen, sondern könnt beide/alle durch das zuerst verbundene ansprechen.
  • push "route 172.16.107.0 255.255.255.0"
    Den Clients wird mitgeteilt, daß sie das Netzwerk 172.16.107.0 mit der Netmask 255.255.255.0 durch den VPN-Tunnel erreichen können.
    Muß zu den Angaben in Zeile 1 & 2 passen.
  • push "route-gateway 172.16.107.1"
    Sicherheitshalber teilen wir auch das Gateway noch explizit mit.
    Muß zu den Angaben in Zeile 1 & 2 und in der vorherigen Zeile passen.
[align=center]Wundert Euch übrigens nicht, daß im weiteren Verlauf "proto tcp6-server" eingestellt ist:
tcp6-server bedeutet, daß OpenVPN mit TCP arbeitet und auf einem IPv6-Socket "lauscht". Serverseitig ist das absolut unproblematisch, selbst wenn Ihr Euch vorerst nur per IPv4 verbinden wollt.
Der Server wird bei dieser Einstellung sowohl Verbindungen per IPv6 als auch per IPv4 annehmen.

Nachdem Ihr die Grundkonfiguration nach Euren Bedürfnissen angepaßt habt und wenn/sobald die Generierung der Diffie-Hellman-Parameter bereits abgeschlossen ist, führt Ihr noch folgende Kommandos aus:

Code: Alles auswählen

cd /etc/enigma2/Certs
bin/rwserver.sh vusolo4k

... wobei Ihr vusolo4k durch den Hostname der Server-Box ersetzt, wie schon beim Erstellen der Server-Zertifikate.

Das Script rwserver.sh kleistert dann
- die Grundkonfiguration
- die Diffie-Hellman-Parameter
- das "CA Root"-Zertifikat
sowie
- den Server-Schlüssel für vusolo4k
und
- das Server-Zertifikat für vusolo4k
zu einer einzigen Konfigurationsdatei
/etc/openvpn/rwserver.conf
zusammen.

Die fertige Konfigurationsdatei /etc/openvpn/rwserver.conf wird in etwa so aussehen:

Code: Alles auswählen

port 12345
ifconfig 172.16.107.1 255.255.255.0
ifconfig-pool 172.16.107.200 172.16.107.254 255.255.255.0
push "dhcp-option DNS 192.168.107.1"
push "route 192.168.107.0 255.255.255.0"
push "route 172.16.107.0 255.255.255.0"
push "route-gateway 172.16.107.1"
dev tun
comp-lzo yes
mssfix 1420
verb 1
keepalive 10 60
client-to-client 1
float 1
persist-tun 1
tls-server 1
cipher BF-CBC
mode server
proto tcp6-server
topology subnet
log /var/log/openvpn.log
push "topology subnet"
push "comp-lzo yes"
script-security 2
up /etc/openvpn/up.sh
<dh>
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEA6cv6GnBrr+zyZOLdAID5vodoe05eCHUPSJEyXeCB974f1gq0HSbK
...
36V9wbeQLphYU2WbHBdRNOevC73qvTxwIwIBAg==
-----END DH PARAMETERS-----
</dh>
<ca>
-----BEGIN CERTIFICATE-----
MIIFzDCCA7SgAwIBAgIJAKkZ/yzXJBKjMA0GCSqGSIb3DQEBCwUAMIGDMQswCQYD
...
iGUfNbSBWPajKwY986sjJrudQkkQM52HpkWSduodVRAlw7xLowG/eaI2UyOE2YQe
-----END CERTIFICATE-----
</ca>
<key>
-----BEGIN RSA PRIVATE KEY-----
MIIJKAIBAAKCAgEAr+3uaQja0zHn7fcXK48BuxwZTTOVvvvbYdb+F7r+3sYFpXqD
...
sqZPQTkdh7GAB6pwGTJLONNeHVaqqqYUw2ckNntvMLnCErXG5xVf0ouRCLc=
-----END RSA PRIVATE KEY-----
</key>
<cert>
-----BEGIN CERTIFICATE-----
MIIHWjCCBUKgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCREUx
...
RI4fT2yJeCgntPvxOIQ=
-----END CERTIFICATE-----
</cert>


Lästige, aber (relativ) notwendige Konfiguration am Router

So wie es bisher eingerichtet ist, könntet Ihr den Server sofort benutzen. Verbundene Clients wären aber nur in der Lage, die Box selber zu erreichen.
Andere Geräte im Heimnetz erreichen sie so nicht, da weder die anderen Geräte noch der Router die "Rückroute" zum OpenVPN-Client (Der ja keine IP aus dem Heimnetz erhält, sondern nur eine 172.16.107.x) kennt.

Damit der OpenVPN-Client alle Geräte im Heimnetz erreichen kann, müßt Ihr in Eurem Router noch eine sogenannte "statische Route" oder "static route" einrichten.
Die Einrichtung variiert von Router zu Router, aber im Kern sind nur drei Angaben wichtig:
1. Ziel/Target: Das in Zeile 1 der Server-Config implizit gewählte Subnet (Hier also 172.16.107.0) mit der
2. Netzwerkmaske 255.255.255.0 (Oder in CIDR-Notation 172.16.107/24)
3. Gateway: Die interne IPv4 der E2-Box, die OpenVPN-Server spielt, also z.B. 192.168.107.40

Auch hier patzt der Drecknikotzlor DK7200 wieder. Keine statischen Routen möglich :([/align]
Benutzeravatar
SpaceRat
Developer
Developer
Beiträge: 2863
Registriert: 13 Aug 2013 11:53
Wohnort: Midgard
Receiver 1: Vu+ Ultimo 4k 4x DVB-S2 FBC / 2x DVB-C OpenATV 6.2
Receiver 2: Gigablue Quad4k 2xDVB-S2 OpenATV 6.2
Receiver 3: AX Quadbox 2400HD
Receiver 4: diverse
Receiver 5: DVBViewer
Hat gedankt: 480 Mal
Hat Dank erhalten: 1432 Mal
Kontaktdaten:

#20

Beitrag von SpaceRat »

[align=center]2.2.x: VPN - Virtual Private Network - OpenVPN Client-Config

Road Warrior-Szenario

Ähnliche wie schon beim Server ändert Ihr zuerst einmal die Rumpfkonfiguration, die liegt in /etc/enigma2/Certs/VPN/rwclient.base und sieht wie folgt aus:

Code: Alles auswählen

remote openatv.dyndns.org 12345
proto tcp6-client
route 192.168.107.0 255.255.255.0
route 172.16.107.0 255.255.255.0
dev tun
resolv-retry infinite
mute-replay-warnings
comp-lzo
verb 1
keepalive 10 60
persist-key
persist-tun
nobind
tls-client
client
cipher BF-CBC
mute 20
ping-timer-rem
[/align]
Hier sind die ersten 4 Zeilen anzupassen:
  • remote openatv.dyndns.org 12345
    Hier ersetzt Ihr openatv.dyndns.org durch einen DynDNS-Host, unter dem Ihr Euer Heimnetz bzw. Eure E2-Box von außerhalb erreicht.
    Hier kann auch der Hostname eingesetzt werden, der durch eine MyFritz-Freigabe erzeugt wird, also z.B. vusolo4k.blablablabla.myfritz.net.

    Außerdem ersetzt Ihr noch 12345 durch den bei der Konfiguration des Servers gewählten Port.
  • proto tcp6-client
    Das zu verwendende Internet-Protokoll, hier TCP mit IPv6 (und Rückfall auf IPv4).

    "proto tcp6-client" sollte eigentlich immer funktionieren, aber wenn Ihr ein Client-Profil für Euer Smartphone erzeugt und keine T-Mobile-Kunden seid (T-Mobile/D1 verwendet IPv6), dann werdet Ihr unterwegs eh fast immer auf IPv4 zurückfallen.
    In diesem Fall erfolgt der Verbindungsaufbau mit "proto tcp-client" etwas schneller, da direkt IPv4 genutzt wird.

    Wenn Ihr zuhause DS-lite habt, sollte hier immer "proto tcp6-client" stehen, um wann immer es geht die direkte Verbindung zur E2-Box zu versuchen, statt über einen Port-Mapper wie feste-ip.net oder myonlineportal.net zu laufen selbst wenn Ihr unterwegs auch IPv6 habt.

    Beim Client lohnt es sich also bei Verbindungsproblemen neben der DynDNS-Adresse (Falls Ihr mehrere habt) ggf. auch mit dieser Einstellung zu spielen.
  • route 192.168.107.0 255.255.255.0
    route 172.16.107.0 255.255.255.0

    Hier werden dieselben Routen eingetragen wie in der Server-Konfiguration als
    push route ...

    Im Prinzip ist diese Angabe doppelt gemoppelt, "push route" durch den Server genügt eigentlich.
    Nach meiner Erfahrung gibt es aber Clients (Ich meine es war mal wieder unter Apple OS), die die gepushten Routen ignorieren.
[align=center]Sobald Ihr die Rumpfkonfiguration angepaßt habt, erstellt Ihr mit folgenden Befehlen

Code: Alles auswählen

cd /etc/enigma2/Certs
bin/rwclient.sh smartphone

eine komplette Client-Konfiguration für einen Client, hier "smartphone", die wie die Server-Konfiguration aus der o.g. Rumpf-Konfiguration sowie
- dem Root-Zertifikat
- dem Client-Schlüssel
- dem Client-Zertifikat
besteht.

Die fertige Konfiguration findet Ihr unter "Client-Name".ovpn - also z.B. smartphone.ovpn - in /etc/enigma2/Certs/VPN

Diese Config eignet sich zum direkten Import in
OpenVPN Connect für Android (Kostenlos im Google Play Store)
Securepoint SSL VPN Client (Kostenlos auf sourceforge)
OpenVPN Connect für Apple OS ("iOS") (Kostenlos in Apple EiTunes)
Tunnelblick (Kostenloser OpenVPN Client für Mac OS X/macOS)
oder nach Umbenennung in "Client-Name".conf , also z.B. otherbox.conf, zur Verwendung mit OpenVPN unter Linux/auf einer anderen E2-Box ...
... sowie für viele weitere OpenVPN-Client-Variationen.[/align]
Antworten

Zurück zu „HOWTOs“