Hallo,
hier will ich einfach mal kurz beschreiben wie ich meinen Zugriff auf Edomi von intern und extern regele.
Gerne höre ich mir dazu positive aber vor allem auch negative Meinungen und Vorschläge an. Ich halte diesen Aufbau für sehr komfortabel und auch genügend sicher.
==> Einige Annahmen und Grundgedanken:
- VPN
Ich mag kein VPN für Edomi. VPN on Demand ist doof zu konfigurieren (MAC)... undokumentierte Textdateien für iOS basteln.
Selbst wenn man ein elegantes VPN on demand eingerichtet hat, hat man das Problem (iOS ist zu blöd sich routen geben zu lassen) dass entweder alle Daten über das VPN übertragen werden oder nur Daten zum direkten VPN Host. 1) will ich nicht (Performance) und 2) reicht eben nicht, außer der VPN Server läuft auf Edomi. Das will ich für mich auch nicht, da ich nicht weiß, was gaert alles in einem Update ändern wird und ich nicht immer nachziehen will.
- https mit Client-Zertifikaten
Also kein VPN. Bleibt externer Zugriff über https.
https auf dem apache-webserver kann man so einrichten, dass nur spezielle clients (Nachweis mit Zertifikaten) auf den apache verbinden können.
- Performance, Kameras
Wenn Geräte aus meinem internen Netz auf edomi zugreifen, brauch ich kein https.
Weiterhin will ich auf meine Kameras im Live-Stream über edomoi zugreifen. Nicht via 1 Bild / Sekunde.
Andererseits brauche ich von extern keinen live stream in HD Qualität (lahme Leitung..?), da sollen es 1 Bild / Sekunde sein
==> Ziel
- Geräte von extern greifen auf edomi über https zu. Kamera-Bilder werden direkt von edomi geliefert (1 Bild / Sekunde)
- Geräte von intern greifen auf edomi über http zu. Kamera-Bilder werden direkt/live in HD eingebunden.
Wichtig: Ich will auf meinem iOS natürlich nur EIN Edomi-Symbol haben!
- Ich will keinen weiteren Rechner (zb reverse-proxy) haben. https soll direkt auf dem edomi-Rechner laufen.
==> Konzept image_53843.png
Meine "dyndns"-Domain (in meinem Beispiel MEINNAME.diskstation.me) löst von außen auf meine DSL IP auf. Normaler dyndns-Kram bzw regelt das meine Synology-Diskstation.
Dieselbe dyndns domain wird über meinen internen Domainserver (läuft auch auf meiner Synology) quasi "gefaked" und zu 192.168.10.19 (interne EDOMI-IP) aufgelöst.
So komme ich von innen und außen über denselben Namen immer auf Edomi.
Auf edomi habe ich dann ein kleines Entscheidungsskript geschrieben (siehe Anhang):
Wenn aktueller request von innen, leite weiter auf http://192.168.10.19/visu/{über https gesendete Zugangsdaten}.
Wenn aktueller request von außen, leite weiter auf https://MEINNAME.diskstation.me/visu/{über https gesendete Zugangsdaten}
Wegen der gewünschten Kamera-Einstellungen (Live+direkt <> 1Bild/Sek über edomi) muss ich meine Hauptvisu in edomi duplizieren und die Kameraeinstellung in der zweiten Visualisierung anpassen.
Das Verteiler-Skript setzt also auch die benötigte visu Seite für mich, in Abhängigkeit von internem oder externem Zugriff.
==> Howto
1) Internen DNS Server Server einrichten, so dass dyndns-url (zb MEINNAME.diskstation.me) auf interne Edomi IP zeigt
2) Apache für https einrichten
A) Zertifkate generieren
Vorgegangen bin ich nach: http://www.garex.net/apache/
Das hier waren im Wesentlichen meine Befehle. Sind aber alle im Detail in obigem link beschrieben.
yum install openssl
openssl genrsa -out CA/steffenCA.KEY
openssl req -new -key CA/steffenCA.KEY -out CA/steffenCA.CSR
openssl x509 -req -days 3650 -in CA/steffenCA.CSR -out CA/steffenCA.CRT -signkey CA/steffenCA.KEY
openssl genrsa -des3 -out keys/steffenWEB.KEY
openssl req -new -key keys/steffenWEB.KEY -out requests/steffenWEB.CSR
openssl ca -days 3650 -in requests/steffenWEB.CSR -cert ../CA/steffenCA.CRT -keyfile ../CA/steffenCA.KEY -out certificates/steffenWEB.CRT
# Passwort entfernen
openssl rsa -in keys/steffenWEB.KEY -out keys/steffenWEB.KEY.nopass
# User CA
openssl genrsa -des3 -out user1.key 1024
openssl req -new -key garex.KEY -out garex.CSR
openssl ca -days 3650 -in user1.CSR -cert ../CA/steffenCA.CRT -keyfile ../CA/steffenCA.KEY -out user1.CRT
# convert
openssl pkcs12 -export -clcerts -in user1.CRT -inkey user1.KEY -out user1.P12
B) Apache für https konfigurieren
yum install mod-ssl
Achtung, nach Installation von mod-ssl hat bei mir ein Eintrag in der apache-ssl-konfig den apache Start verhindert.
Habe das SetEnvIf in Zeile 217 einfach auskommentiert.
nano /etc/httpd/conf.d/ssl.conf
da die Pfade zu den Zertifikaten anpassen. Siehe http://www.garex.net/apache/
Ich habe geändert:
<VirtualHost *:443>
ServerName edomi.local:443 <== Name wie der CN im Server-Zertifikat
Zum Testen empfehle ich, zuerst einmal kein Client-Zertifikat zu erzwingen ("SSLVerifyClient require" auskommentieren!)
Wenn der https Zugriff klappt, dass versuchen, die Client-Zertifikate zum Laufen zu bekommen.
3) Das Weiterleitungsskript auf EDOMI /usr/local/edomi/www/ kopieren
Im Skript muss noch das Subnetz konfiguriert werden (24 ist in den meisten Fällen richtig).
Außerdem müssen die Visu-IDs dort angepasst werden!
Weiterhin hat man die Möglichkeit, für erste Tests $doRedirect=FALSE; zu setzen, damit man nicht sofort weitergeleitet wird, sondern erstmal eine Testausgabe bekommt.
Da wir hier selbstsignierte Zertifikate benutzen, kommt beim ersten Aufruf eine entsprechende Warnung.
Außerdemkann iOS beim Generieren der WebApp (Safari => Seite auf HomeScreen legen) wohl nicht das originale Icon wegen der https Warnung laden. Daher habe ich es auf meinen Server gelegt und lade dieses Icon in dem Weiterleitungsskript eben von meiner externen http-seite...
Weiterleitungs-Seite auf Edomi aufrufen, von intern und extern sollte jetzt klappen mit gleichem Aufruf.
https://dyndns-url/?login=AAAAA&pass=BBBBB
Ich glaube das war's....
Viel Spaß,
Steffen
hier will ich einfach mal kurz beschreiben wie ich meinen Zugriff auf Edomi von intern und extern regele.
Gerne höre ich mir dazu positive aber vor allem auch negative Meinungen und Vorschläge an. Ich halte diesen Aufbau für sehr komfortabel und auch genügend sicher.
==> Einige Annahmen und Grundgedanken:
- VPN
Ich mag kein VPN für Edomi. VPN on Demand ist doof zu konfigurieren (MAC)... undokumentierte Textdateien für iOS basteln.
Selbst wenn man ein elegantes VPN on demand eingerichtet hat, hat man das Problem (iOS ist zu blöd sich routen geben zu lassen) dass entweder alle Daten über das VPN übertragen werden oder nur Daten zum direkten VPN Host. 1) will ich nicht (Performance) und 2) reicht eben nicht, außer der VPN Server läuft auf Edomi. Das will ich für mich auch nicht, da ich nicht weiß, was gaert alles in einem Update ändern wird und ich nicht immer nachziehen will.
- https mit Client-Zertifikaten
Also kein VPN. Bleibt externer Zugriff über https.
https auf dem apache-webserver kann man so einrichten, dass nur spezielle clients (Nachweis mit Zertifikaten) auf den apache verbinden können.
- Performance, Kameras
Wenn Geräte aus meinem internen Netz auf edomi zugreifen, brauch ich kein https.
Weiterhin will ich auf meine Kameras im Live-Stream über edomoi zugreifen. Nicht via 1 Bild / Sekunde.
Andererseits brauche ich von extern keinen live stream in HD Qualität (lahme Leitung..?), da sollen es 1 Bild / Sekunde sein
==> Ziel
- Geräte von extern greifen auf edomi über https zu. Kamera-Bilder werden direkt von edomi geliefert (1 Bild / Sekunde)
- Geräte von intern greifen auf edomi über http zu. Kamera-Bilder werden direkt/live in HD eingebunden.
Wichtig: Ich will auf meinem iOS natürlich nur EIN Edomi-Symbol haben!
- Ich will keinen weiteren Rechner (zb reverse-proxy) haben. https soll direkt auf dem edomi-Rechner laufen.
==> Konzept image_53843.png
Meine "dyndns"-Domain (in meinem Beispiel MEINNAME.diskstation.me) löst von außen auf meine DSL IP auf. Normaler dyndns-Kram bzw regelt das meine Synology-Diskstation.
Dieselbe dyndns domain wird über meinen internen Domainserver (läuft auch auf meiner Synology) quasi "gefaked" und zu 192.168.10.19 (interne EDOMI-IP) aufgelöst.
So komme ich von innen und außen über denselben Namen immer auf Edomi.
Auf edomi habe ich dann ein kleines Entscheidungsskript geschrieben (siehe Anhang):
Wenn aktueller request von innen, leite weiter auf http://192.168.10.19/visu/{über https gesendete Zugangsdaten}.
Wenn aktueller request von außen, leite weiter auf https://MEINNAME.diskstation.me/visu/{über https gesendete Zugangsdaten}
Wegen der gewünschten Kamera-Einstellungen (Live+direkt <> 1Bild/Sek über edomi) muss ich meine Hauptvisu in edomi duplizieren und die Kameraeinstellung in der zweiten Visualisierung anpassen.
Das Verteiler-Skript setzt also auch die benötigte visu Seite für mich, in Abhängigkeit von internem oder externem Zugriff.
==> Howto
1) Internen DNS Server Server einrichten, so dass dyndns-url (zb MEINNAME.diskstation.me) auf interne Edomi IP zeigt
2) Apache für https einrichten
A) Zertifkate generieren
Vorgegangen bin ich nach: http://www.garex.net/apache/
Das hier waren im Wesentlichen meine Befehle. Sind aber alle im Detail in obigem link beschrieben.
yum install openssl
openssl genrsa -out CA/steffenCA.KEY
openssl req -new -key CA/steffenCA.KEY -out CA/steffenCA.CSR
openssl x509 -req -days 3650 -in CA/steffenCA.CSR -out CA/steffenCA.CRT -signkey CA/steffenCA.KEY
openssl genrsa -des3 -out keys/steffenWEB.KEY
openssl req -new -key keys/steffenWEB.KEY -out requests/steffenWEB.CSR
openssl ca -days 3650 -in requests/steffenWEB.CSR -cert ../CA/steffenCA.CRT -keyfile ../CA/steffenCA.KEY -out certificates/steffenWEB.CRT
# Passwort entfernen
openssl rsa -in keys/steffenWEB.KEY -out keys/steffenWEB.KEY.nopass
# User CA
openssl genrsa -des3 -out user1.key 1024
openssl req -new -key garex.KEY -out garex.CSR
openssl ca -days 3650 -in user1.CSR -cert ../CA/steffenCA.CRT -keyfile ../CA/steffenCA.KEY -out user1.CRT
# convert
openssl pkcs12 -export -clcerts -in user1.CRT -inkey user1.KEY -out user1.P12
B) Apache für https konfigurieren
yum install mod-ssl
Achtung, nach Installation von mod-ssl hat bei mir ein Eintrag in der apache-ssl-konfig den apache Start verhindert.
Habe das SetEnvIf in Zeile 217 einfach auskommentiert.
nano /etc/httpd/conf.d/ssl.conf
da die Pfade zu den Zertifikaten anpassen. Siehe http://www.garex.net/apache/
Ich habe geändert:
<VirtualHost *:443>
ServerName edomi.local:443 <== Name wie der CN im Server-Zertifikat
Zum Testen empfehle ich, zuerst einmal kein Client-Zertifikat zu erzwingen ("SSLVerifyClient require" auskommentieren!)
Wenn der https Zugriff klappt, dass versuchen, die Client-Zertifikate zum Laufen zu bekommen.
3) Das Weiterleitungsskript auf EDOMI /usr/local/edomi/www/ kopieren
Im Skript muss noch das Subnetz konfiguriert werden (24 ist in den meisten Fällen richtig).
Außerdem müssen die Visu-IDs dort angepasst werden!
Weiterhin hat man die Möglichkeit, für erste Tests $doRedirect=FALSE; zu setzen, damit man nicht sofort weitergeleitet wird, sondern erstmal eine Testausgabe bekommt.
Da wir hier selbstsignierte Zertifikate benutzen, kommt beim ersten Aufruf eine entsprechende Warnung.
Außerdemkann iOS beim Generieren der WebApp (Safari => Seite auf HomeScreen legen) wohl nicht das originale Icon wegen der https Warnung laden. Daher habe ich es auf meinen Server gelegt und lade dieses Icon in dem Weiterleitungsskript eben von meiner externen http-seite...
Weiterleitungs-Seite auf Edomi aufrufen, von intern und extern sollte jetzt klappen mit gleichem Aufruf.
https://dyndns-url/?login=AAAAA&pass=BBBBB
Ich glaube das war's....
Viel Spaß,
Steffen
Kommentar