Was bietet SRVHome

DynDns

Ein DNS-Dienst der es ermöglicht seine eigene IP, und die Dienste die dort aktiv sind, über das Internet bereitzustellen

3 mal DNS

Bis zu 3 Hostnamen können einem Account zugeordnet werden. Diese können unabhängig voneinander mit eigenen IP's belegt werden

Gemeinsamer Update

Alle DNS-Einträge eines Accounts können gemeinsam mit einem Update gesetzt werden

IPV6

Für alle Hostnamen können IPV6-Addressen gesetzt werden

Let's encrypt

Für alle Hostnamen können DNS-Basierte validation's gesetzt werden. Somit können auch Dienste verschlüsselt werden die keinen zugriff auf HTTP ermöglichen

Einfacher automatischer Update

Ein einfacher Aufruf reicht aus um die automatische ermittelte IP einem Host oder Account zuzuordnen. Es ist nicht nötig seine eigene IP zu ermitteln

Was ist SRVHome

Will ich vom Internet meinen Server zuhause erreichen stellt sich oft das Problem das sich die IP meines Anschlusses wechselt. Dabei gibt es Varrianten bei denen sich die IP über Tage oder Wochen nicht verändern, andere wiederum ändern sich Täglich. Da man nicht weiß wann sich eine IP ändert wäre es doch toll wenn das keine Rolle mehr spielen würde. Ein Automatismus regelt das ganz einfach: Dynamische DNS. Am Einfachsten läßt sich so etwas mit einem Telefonbuch vergleichen. Suche ich nach 'Max Mustermann' werde ich die dazugehörige Telefonnummer finden. Die Telefonnummer ist meine IP meines Anschlusses. Ändert sich die IP, wird im Telefonbuch der Eintrag für 'Max Mustermann' automatisch berichtig. SRVHome bietet ein Telefonbuch und die Mechanismen um die Einträge automatisiert zu berichtigen. Eine Anwendung in der ein DynDNS-Dienst genutzt wird ist meine Türstation DoorBell32

Wo ist nun der Unterschied zu einer Cloud? Bei einem Cloud-Dienst werden Daten zu einem Server im Internet transportiert und diese dann allen Nutzern, welche die Berechtigung haben, zugänglich gemacht. Der Standort der Server ist häufig in Ländern in denen das Betreiben der Server kostengünstig ist. Im Falle von Cam's ist das häufig das Land der Hersteller der Kameras. Da wir immer zu einem bekannten Server verbinden benötigen wir keine Dynamischen DNS. Der Nachteil der Cloud-Dienste ist, das ich keinen Einfluß darauf habe wohin meine Daten transportiert werden und welche (vielleicht staatliche Einrichtungen) darauf zugriff haben. Ich bin auch daran gebunden das zu nehmen was mir angeboten wird. Ein Dienst nach meinen Wünschen zu gestalten ist nicht möglich.

DynDNS

srvhome Image

Cloud

srvhome Cloud Image

Dynamische DNS, MQTT oder Cloud?

Wenn wir einen Cloud-Dienst nutzen, werden Daten an eine öffentlich erreichbaren Stelle gesendet. Diese Daten werden dann durch die Endgeräte wieder abgefragt. Das hört sich etwas wirr an, ist aber im Grunde sehr einfach. Ich möchte es Dir an einem Beispiel versuchen zu erklären.

Ich möchte meine Heizung immer dann auf meine wohlfühl Temperatur regeln bevor ich nach Hause komme. Das ist natürlich hauptsächlich für meine Frau damit sie es schön mollig warm hat. Ein Projekt zu rechtfertigen ist immer einfacher wenn meine Frau der hauptsächliche nutznießer ist und ich darf mit wohlwollender zustimmung basteln ;-)

In diesem Projekt gibts es die Problematik das ich der Heizung sagen muß was sie zu tun hat. Bei dem China-Shop meines vertrauens habe ich einen Cloud-basierten Heizungsthermostat gesehen. Hier erfolgt die Einstellung der Temperatur über einen Cloud-Dienst. In meinem Handy stelle ich die Temperatur ein und sekunden später summt der Thermostat an meiner Heizung. Hierzu verbindet sich der Thermostat mit einem Server irgendwo auf der Welt des Herstellers und hält laufend Verbindung mit diesem Server. Verändere ich die Einstellung der Temperatur an meinem Handy, wird diese dem Server mitgeteilt. Der Thermostat wiederum erhält die Information das sich etwas geändert hat und reagiert darauf durch die Anpassung der Temperatur.

Ist beim Server des Herstellers eine Überlastung, oder einfach die Verbindung gestört, kann ich meine Temperatur nicht einstellen. Selbst wenn ich zuhause bin ist dies nicht mehr möglich weil die Verbindung immer zum Cloud-Dienst erfolgt.

Eine umgehung des Problems ist z.B. die Nutzung von MQTT. Hier bin ich nicht mehr an einen Dienst des Herstellers gebunden sondern kann einen beliebigen Anbieter nutzen und zur Not auch wechseln. Die Problematik bleibt jedoch das ich von einem Dienstanbieter abhängig bin wenn auch nicht gebunden an einen Anbieter.

Will ich eine unabhängigkeit von einem Dienstanbieter, muß ich selber der Dienstanbieter werden. Einen kleinen Server (z.B. RPI ) aufzusetzen ist kein Hexenwerk, nur wie kann ich diesen Erreichen wenn ich nicht zuhause bin?

Ganz einfach! Wir geben dem Zuhause einen Namen. Dazu gibt es Dienste die einen DNS-Eintrag für mich bereitstellen.

Ein DNS-Eintrag ist so etwas wie ein Telefonbuch. Mein Namenseintrag wird einer Telefonnummer zugeordnet. Will ich wissen welche Telefonnummer (IP) ich (mein Domain-Name) habe, schau ich einfach im Telefonbuch (DNS-Server) nach.

Kenne ich meine IP von meinem Zuhause, kann ich mich dorthin verbinden und alles das machen als wäre ich zuhause. Meist wird dies über VPN’s gemacht womit ich dann keine einzelne Dienste nach außen (dem Internet) freigeben muß.

Im konkreten Beispiel würde ich einen MQTT-Server zuhause aufsetzen, dort die MQTT-Fähige Regelung anmelden. An meinem Router (z.B. eine FritzBox) den Dyn-DNS Dienst eintragen und eine Portweiterleitung zu meinem MQTT-Server. Der Router teilt nun dem Dyn-DNS-Dienst mit, wenn sich meine IP ändert. Bin ich unterwegs kann ich nun auf den Namen zugreifen dem meine IP zugeordnet ist. Somit kann ich auf Musik, Videos, Dokumente, Lampen, meine Türklingel, Kameras,Sensoren usw. zugreifen ohne eine Vielzahl von Cloud-Dienste in anspruch nehmen zu müssen. Und das alles mit einem Namen den ich mir zum Großteil aussuchen kann… kostenfrei, selbstverständlich.

Wer meint dass das Beispiel an den Haaren herbeigezogen sein, dem sei versichert das ein ähnlicher Umstand mir passiert ist. Der Weihnachtsbaum sollte per Funksteckdose geschaltet werden. Bitte nicht noch eine Fernsteuerung auf dem Tisch! Also soll das per Smartphone geschaltet werden. In den Weihnachtsfeiertagen mußte ich mehrmals, ganz entgegen dem Sinn einer Funksteckdose, den Stecker ziehen um die Beleuchtung auszuschalten. Der Cloud-Server war nicht erreichbar.

Es gibt so viele, warum SRVHome ?

  • Beginnen wir mit dem Besten, es ist kostenfrei.
  • Es können bis zu 3 Namen verwendet werden.
  • Es wird kein spezieller Client für das Aktualisieren der IP’s benötigt, eine einfacher Aufruf reicht aus.
  • Ich muß nicht vorher meine IP ermitteln um sie setzen zu können.
  • SRVHome unterstützt Let’s Encrypt womit ein kostenfreies Zertifikat für eine verschlüsselte Übertragung erworben werden kann. Z.B. für eine eigene Cloud sehr hilfreich.
  • Es werden auch Einträge für IPV6 unterstützt.

MQTT was ist denn das ?

MQTT = Message Queuing Telemetry Transport

Dies wurde eingeführt um auch leistungsschwache Rechner wie z.B. Arduino’s eine Kommunikationsmöglichkeit mit anderen Rechner zu geben. Das Protokoll hat sich als so Leistungsfähig erwiesen das sehr viele Projekte damit ihre Daten übermitteln. MQTT benötigt zum funktionieren einen sog. Broker. Dies ist eine Software welche die Kommunikation mit den Clients entgegennimmt oder wieder an diese verteilt. Das Medium über die die Daten an den Broker geleitet werden ist dabei nicht relevant. Dies kann seriell, über Funk oder Netzwerk erfolgen.

Wie kann man die Funktion nun am besten beschreiben?

Nehmen wir doch ein Bespiel aus dem Leben.

Eine Familie: Mann, Frau und zwei Kinder, Emma und Paul. Auch wenn es die Männer nicht gerne hören, ist doch meist die Frau der Zentrale Punkt der Familie (Broker).

Wenn Paul etwas angestellt hat, dann ist der erste weg von Emma (Client) es der Mama (Broker) mitzuteile. Diese Information leitet der Broker (die Frau) dann an den Client (der Mann) der diese Information aboniert hat.

Sollen die Kinder ins Bett gehen, wird der Mann (Client) der Frau (Broker) sagen: “Bring die Kinder ins Bett”. Die Frau (Broker) schreit: “Kinder ins Bett!”.

Vereinfacht ist der Broker die Stelle an der die Informationen entgegengenommen werden, gespeichert werden und auch an die verbundenen Clients verteilt werden.

Es gibt kostenlose und auch Kostenpflichtige MQTT Broker im Internet. Ist diese zentrale Stelle im Internet verfügbar, kann ich von überall in der Welt mit den Informationen Arbeiten. Leider bin ich dann abhängig von der Verfügbarkeit des externen Dienstes. Ich kann auch in meinem Umfeld einen Broker installieren und direkt über einen DynDns-Dienst erreichen. Es gibt viele varianten wie auch Broker vernetzt werden können und auch Informationen gefiltert weitergereicht werden können das würde jedoch diese kurze Beschreibung sprengen.

Octoprint ist bekannt beim 3D-Druck

Octoprint ist eine Software die gerne von 3D-Druckern verwendet wird. Hier wird oft ein Raspberry PI eingestezt um einen Druck, der mehrer Stunden oder gar Tage dauern kann, zu überwachen.

Wie cool wäre es das von überall aus machen zu können? Einfach mit einem DYNDNS-Dienst wie SRVHome!

Im heimischen Router wird der DYNDNS-Dienst eingetragen und eine Protweiterleitung auf die Interne IP des Raspberry PI eingetragen. Schon kann ich von überall auf der Welt meinen Druckprozess überwachen. Einfach, oder?

Ich habe das schon so oft gelesen, was ist IOT ?

IOT = Internet of Things

Das ‘Internet der Dinge’ ist kein ‘etwas’ sondern eine Bezeichnung für das Bestreben auch einfache Dinge Internetfähig zu machen.

Über den Sinn seine Waschmaschine auch über eine App anschalten zu können mag man streiten, viele der kleine Internetfähigen Dinge erleichtern das Leben jedoch ohne Frage. Die Raumtemperatur nach wirklicher Nutzung zu steuern ist nicht nur Bequem sonder kann wirklich helfen Energie zu sparen. Eine Alarmierung und Überwachung meines Hauses kann schon zur Abschreckung von möglichen Einbrüchen führen. Das Abschatten der Fenster hilft das Raumklima zu Regulieren. Nur wenige Beispiele aus den fast unendlich vielen Möglichkeiten diese ‘Idee’ auch Hilfreich einzusetzen.

Um das Beispiel mit der Waschmaschine noch einmal aufzugreifen… wie wäre es wenn die Waschmaschine mir mitteilen könnte ob mein Waschmittel noch ausreichend für die nächsten wäschen vorhanden ist? Sollte ich beim nächsten Einkauf das berücksichtigen?

Let’s Encrypt, noch nie davon etwas gehört!

Die Daten-Sammelwut der Regierungen und die Agilität von Angriffen auf persönliche Daten und Aktivitäten trüben die Freude am Internet. Es könnte alles so schön sein wenn nicht…! Nehme ich den vorher erwähnten die Möglichkeit mich anzugreifen oder auszuspionieren könnte alles so schön sein. Da war doch etwas? Meine Verbindung verschlüsseln! Der erste Weg ist eine Verschlüsselung mit eigenen Zertifikaten zu verwenden. Nur kann das jeder und ich bin nicht sicher ob mein Gegenüber auch der ist, der er vorgibt zu sein. Es muß also jemand bestätigen das der Gegenüber der ist der er sein soll. Das lassen sich Zertifizierungsstellen zum Teil hoch vergüten. Ich mach mir die Mühe mit meiner eigenen Cloud und soll dann für ein Zertifikat bezahlen?

Let’s encrypt hat es sich zur Aufgabe gemacht das möglichst viel im Internet verschlüsselt wird. Dazu bietet Let’s encrypt kostenfrei Zertifikate an. Ein Nachteil dieses Zertifikats ist das diese nur 3 Monate gültig sind. Damit man nicht alle 3 Monate eingreifen muß, bietet Let’s encrypt Clients an die diese Zertifikate automatisiert verlängern und somit gültig halten. Zur automatisierten Verlängerung werden zwei Methoden verwendet. Die Http-Methode erfordert das ein Web-Server aktiv ist der eine kleine Datei bereitstellt um zu bestätigen dass das Zertifikat auch vom Domaininhaber angefordert wird. Habe ich keinen Webserver aktiv oder der Port 80 wird durch andere Dienste genutzt, bleibt nur die 2. Methode um mich zu Authentifizieren. Die zweite Methode verwendet einen TXT-Eintrag beim DNS-Server. Wer die Hoheit über den DNS-Eintrag hat, kann sich damit auch Identifizieren. Das Verfahren ist dabei das gleiche wie zuvor. nur wird nicht auf einem port 80 (http) die Datei abgefragt sondern ein Schlüssel beim DNS-Anbieter abgefragt.

SRVHome unterstützt dabei die DNS-Methode von Let’s encrypt. Somit ist eine automatisierte aktualisierung des Zertifikats sehr einfach möglich. Wir lieben das KISS-Prinzip (Keep it simple, stupid) alles einfach zu halten. Aus diesem Grund favorisieren wir für Let’s encrypt den ‘dehydrated’ client um den Updateprozess zu Automatisieren. Hier sind nur sehr wenig Abhängigkeiten zu anderer Software vorhanden da dies über BASH-Script abläuft.

Ok, ich bin überzeugt! Wie geht das nun ?

Welches Projekt Du auch immer verwirklichen möchtest, wir können Dir einen DynDNS Dienst anbieten der Dich in Deinem vorhaben unterstützt. Auch einfache Rechner (z.B. ESP8266) können die IP’s an SRVHome mitteilen. Meist sind aber die verwendeten Router zu einem DSL-Anschluß fähig direkt uns deine IP mitzuteilen. Der erste Schritt ist, sich bei SRVHome anzumelden. Es spielt keine Rolle ob das über eine Registrierung , über Google oder Facebook erfolgt.

Nach der Anmeldung kann man sich bis zu 3 Namen zu den Angebotenen Domains aussuchen/ausdenken.

Entgegen vielen anderen DynDns-Diensten wollen wir nicht das die Anmeldedaten bei einem ‘Update’ übertragen werden. Aus diesem Grund gibt es zu jedem Nutzer und jedem Namen (Hosteintrag) eigene ID's/Key's mit denen die Daten zugeordnet werden.

Die ID's und Key's können jederzeit über die Administration geändert werden ohne die Anmeldedaten zu ändern.

Ein ‘Update’ ist das mitteilen von neuen informationen zu meiner IP. Macht das ein Router (z.B. FritzBox) kann diese Kommunikation auf das Mitteilen einer neuen IP begrenzt werden… der Router weiß wann sich die IP ändert. Macht das ein Rechner in meinem Netzwerk, weiß dieser oft nichts über einen IP-Wechsel. DynDns-Clients fragen über externe Dienste die eigene IP an und teilen diese dann dem DNS-Dienst mit. So kann das auch bei SRVHome erfolgen, ist aber nicht nötig. Durch das Aufrufen des Updates von SRVHome können wir bereits die IP ( IPV4 ) ermitteln und diese dann auch nutzen.

Der einfachste Aufruf für einen Update ist:

http://www.srvhome.de/update?user=<ID>&pw=<Key>
in Linux reicht ein:

curl “http://www.srvhome.de/update?user=<ID>&pw=<Key>”
oder
http://<ID>:<key>@www.srvhome.de/update

will ich nicht das die ermittelte IP verwendet wird, sondern eine andere IP eingetragen wird (z.B. wenn meine Aufrufe über einen Proxy erfolgen), wird der Aufruf um ip=www.xxx.yyy.zzz erweitert. www.xxx.yyy.zzz ist dabei die IP die verwendet werden soll.
Beispiel: 

http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&ip=111.222.33.44

curl “http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&ip=111.222.33.44”
oder
curl “http://h9cuDZ8Edswe3:98d7DksnTwbn549@www.srvhome.de/update?ip=111.222.33.44”

Soll auch ein DNS-Eintrag für ipv6 erfolgen, muß ich diesen in den Aufrufparametern mit angeben: aaaa=2001:db8:0:8d3:0:8a2e:70:7344
Beispiel:

http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&aaaa=2001:db8:0:8d3:0:8a2e:70:7344

curl “http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&aaaa=2001:db8:0:8d3:0:8a2e:70:7344”
oder
curl “http://h9cuDZ8Edswe3:98d7DksnTwbn549@www.srvhome.de/update?aaaa=2001:db8:0:8d3:0:8a2e:70:7344”

Will ich einen TXT-Eintrag für Let’s Encrypt erzeugen, ist der Aufruf mit folgenden Daten zu erweitern: encrypt=<data>
Beispiel:

http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&encrypt=duewifhewfweg89fw3kjfh3893h2f2lk3jf389

curl “http://www.srvhome.de/update?user=h9cuDZ8Edswe3&pw=98d7DksnTwbn549&encrypt=duewifhewfweg89fw3kjfh3893h2f2lk3jf389”
oder
curl “http://h9cuDZ8Edswe3:98d7DksnTwbn549@www.srvhome.de/update?encrypt=duewifhewfweg89fw3kjfh3893h2f2lk3jf389”

Alle Daten können gemeinsam übermittelt werden. Werden bei ‘encrypt’ und ‘aaaa’ keine Daten angegeben, wird der DNS-Eintrag entfernt. Will ich z.B. einen ipv6 Eintrag haben, so muß diese IP immer mit übermittelt werden.

Alle Aufrufe können über HTTP oder HTTPS übermittelt werden.

Im Falle des update-Aufruf haben wir keine zwangsweise Nutzung von HTTPS vorgesehen entgegen der Nutzung der Administration. Somit können auch einfach Clients die Updates ausführen die oft aufgrund ihrer geringen Leistungsfähigkeit kein https unterstützen.

Jeder DNS-Eintrag kann einzeln mit Daten versorgt werden. Hierzu müssen nur die ID's und Keys der einzelnen Hosts verwendet werden. Sollen alle Hosteinträge von mir mit den gleichen Daten versorgt werden, muß ich meine ID's und Keys verwenden die meinem Account zugeordnet sind.

Frequently Asked Questions

01. FAQ Update

Logge dich in SRVHome ein. In der Auflistung deiner Hostnamen wird auch die zuletzt verwendete IP angezeigt.

Die IP wird mit einer ‘TTL’ von 300 im DNS-Server eingetragen. Das bedeutet dass die IP im schlechtesten Falle erst nach 300 Sekunden (=5Minuten) durch den DNS-Server angezeigt wird. In der Realität ist diese Zeit viel kürzer. Wurde der DNS-Eintrag vor mehr als 5 Minuten zuletzt angefragt, wird es bei einem Update zu keiner Verzögerung kommen.

Der DNS-Eintrag wird mit einer TTL von 300 ausgeliefert. Es macht keinen Sinn einen IP-Wechsel schneller mitzuteilen da auch alle lokalen DNS-Forwarder oder DNS-Speicher die 300 Sekunden berücksichtigen. Ein Update alle 5 Minuten ist daher ausreichend und wird auch empfohlen. Ist mein Router oder Server über den Wechsel einer IP informiert, dann sollte dieser sofort den Update ausführen.

Der Update-Aufruf ist wie folgt aufgebaut:
[ ] = optional
< > = Wert

http[s]://[<ID>:<key>@]www.srvhome.de/update[?][user=<ID>][&][pw=<key>][&][ip=<ip>][&][aaaa=<ipv6>][&][encrypt=<Let’s_encrypt_value>][&][out=json]


Werden Parameter an ‘/update’ angehängt, muß die url nach ‘/update’ ein ? haben.

Alle weiteren Parameter werden durch ein ‘&’ voneinander getrennt.

Parameter haben immer das Format ‘name=wert’

  • <ID> = ID aus dem SRVHome-Portal Nutzer- oder Host gebunden.
  • <key> = key aus dem SRVHome-Portal passend zur ID.
  • <ip> = ipv4 IP. Diese kann automatisch erkannt werden.
  • <ipv6> = ipv6 IP. Diese kann nicht automatisch von SRVHome erkannt werden
  • <Let’s_encrypt_value> = Acme Challenge von Let’s Encrypt

Alle Update-Aufrufe können, mit der Methode Get, als HTTP oder HTTPS-Aufrufe erfolgen.

Wird die Basic-Auth-Methode verwendet (http://ID:key@www.srvhome.de/update…) dann werden die parameter ‘user’ und ‘pw’ nicht benötigt. Nicht alle Client unterstützen heute noch die Basic-Auth- Methode mit der gezeigten Notation. Hier muß darauf geachtet werden ob der Client dies unterstützt oder einfach auf die parameter ausgewichen werden. Werden Basic-Auth und die Parameter verwendet, so hat Basic-Auth den Vorrang.

Wird ‘out=json’ angehängt, so erhält man als Antwort des Aufrufs ein Json.

Um einen Eintrag zu löschen, muß dieser nur leer gelassen werden.

Beispiel:

http://www.srvhome.de/update?user=IDdesHost&pw=keyDesHost&aaaa=&encrypt=
In diesem Beispiel wird eine IP gesetzt, der Wert für IPV6 gelöscht und der Let's encrypt-Token gelöscht.

Löschen heißt in diesem Zusammenhang das der DNS-Server auf diese Anfrage (z.B. IPV6 und den Token) nicht antworten wird.

Werden Daten nicht übergeben, bleiben diese im Update unberücksichtigt: 

http://www.srvhome.de/update?user=IDdesHost&pw=keyDesHost&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334
In diesem Fall bleibt der Let's Encrypt-Token unberührt. Die IP und IPV6 werden gesetzt

Es kann vorkommen das man einen Let's Encrypt Token setzen möchte, die IP soll aber unberührt bleiben. Die IP ist ein Sonderfall. Ein weglassen würde bedeuten das die IP der Anfrage genommen wird. Um dies zu umgehen gibt es für die IP ein Schlüsselwort 'no'. Wird dies angegeben, bleibt auch die IP unberücksichtigt. 

http://www.srvhome.de/update?user=IDdesHost&pw=keyDesHost&ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334
Dieser Aufruf setzt nur die IPV6.

Antwort: Plain Text: Fehler oder IP ‘change false’ wenn keine änderung vorgenommen wurde. Wurden änderungen vorgenommen werden ab dieser Zeile die übergebenen Daten ausgeben. ‘host …. ’ mit der ID für die Hosts mit diesem Aufruf berücksichtigt werden gefolgt von ‘aaaa’, ‘ip’ und/oder ‘encrypt’ abhängig davon was an diesem Host geändert wurde. Antwort bei keiner Änderung: 
OK 1.2.3.4
change false
Antwort, encrypt und aaaa wurde übergeben aber nur aaaa wurde bei zwei host geändert: 
OK 1.2.3.4
encrypt vw0edffr4r3
aaaa aabb:ccdd:eeff::221
host 08d32rr4r424t865 aaaa
host sdafgwq09832rr2 aaaa
Fehler: 
FAIL 1.2.3.4
wrong auth
Json: Bei einer Antwort im Json-Format werden entgegen dem Plain Text-Format auch die Daten angezeigt die nicht übergeben wurden. In diesen Fällen sind die Werte leer. 
{
	"success" : true,
	"ip" : "1.2.3.4",
	"change" : true,
	"encrypt" : "",
	"aaaa" : "",
	"hosts" : [
		"08d32rr4r424t865" : {
			"ip" : false,
			"encrypt" : false,
			"aaaa" : false
		},
		"sdafgwq09832rr2" : {
			"ip" : true,
			"encrypt" : true,
			"aaaa" : true
		},
	]

}

02. FAQ Zugangsdaten

Logge dich bei SRVHome ein und aktualisiere dein ID/Key. Die alte ID/Key-Kombination wird dadurch ungültig. Beachte dabei welche Kombination du resetest. Die Nutzer gebundene Kombination ist für alle deine Hosts zuständig. Einzelne Hosts haben eigene ID/Key-kombinationen.

03. FAQ IP

Logge dich in SRVHome ein und ändere die IP beim Host-Eintrag. Für diesen Eintrag solltest du dann keinen Update ausführen. Hast du mehrer Host-Einträge, so darfst du auch keinen Update mit der Nutzer gebundenen ID/Key-Kombination ausführen.

Das kann passieren wenn zwei Geräte die IP setzen. Wenn z.B. ein Router einen Update vornimmt und ein Rechner im Netzwerk. Abhängig vom Zeitpunkt der DNS-Anfrage wird entweder die eine oder die Andere IP ausgeliefert. Das kann auch passieren wenn man Nutzer bezogene ID/Keys in kombination mit Host bezogene ID/Keys verwendet. Man darf nur eine Art verwenden weil sich sonst die Daten überschreiben.

04. FAQ Let's Encrypt

Ein Problem schafft man sich oft selber. Man möchte wissen was im DNS-Server gespeichert ist und guckt nach (z.B. über ‘dig’ unter Linux). Das nachsehen bewirkt dass eine Anfrage an den DNS-Server geschickt wird. Diese wird auf dem Server gespeichert über einen Zeitraum von 300 Sekunden. Ändere ich den Inhalt, wird dieser erst spätestens 300 Sekunden später ausgeliefert (TTL).

Das ganze wird sogar noch undurchsichtiger. Man denke an die Aufschrift ‘Nach dem öffnen innerhalb von 3 Tagen verzehren’ … Ich gehe zum Kühlschrank und entnehme meine Lieblingsspeise, geöffnet! Wann wurde das denn geöffnet? Sind die 3 Tage schon vorbei? Oder beginnen sie erst?

Mache ich eine Anfrage beim DNS-Server, weiß mein lokaler Speicher wann ich die Anfrage gemacht habe und macht einen countdown über die TTL-Zeit. Ist aber kein Inhalt im DNS-Server gespeichert, wird die Anfrage auch gespeichert nur niemand sagt mir wie lange noch. Da ich nicht weiß wie lange die erste Anfrage her ist, kann das zu sehr verwirrenden Ergebnissen führen. Ich kann sagen das SRVHome das nur 300 Sekunden speichert, wie lange das in lokalen Speichern ist, kann man nur schwer sagen.

Ich kann also nur empfehlen einen Inhalt in ‘encrypt’ zu senden, dabei ist es egal was da steht, nur es sollte ein Inhalt sein.

Zwischen den Versuchen sollten mindestens 300 Sekunden vergehen.

05. FAQ Allgemein

Den Thermostat, die Cloud, Wetterdaten und vieles mehr lassen sich über eine IP abfragen. Man muß nur einen eigenen Port für die einzelnen Dienste verwenden und diese dann in seinem Router freigeben. Das ist eine der Möglichkeiten die man hat. Spätestens wenn man auch SSL verwenden will, wird es aufwendig. Hierzu gibt es eine einfachere Methode: HAProxy. Hierbei handelt es sich um einen Load Balancer dessen Aufgabe es ist Anfragen an eine Server-Farm zu leiten. Da die Konfiguration des HAProxy relativ einfach ist, kann man diese hervorragende Software auch für kleine Anwendungen verwenden. Bei HAProxy handelt es sich um einen Level 7 Proxy im HTTP-Mode. Dies bedeutet dass Anfragen an HAProxy gehen, dieser sieht nach was er damit tun soll und leitet die Anfrage dann an entsprechende Backends weiter. Man hat die Möglichkeit durch eine Konfiguration Pfade zu definieren die dann zu unterschiedlichen Diensten leiten. http://meindienst.srvhome.de/thermostat/ leitet dann an den Thermostat. http://meindienst.srvhome.de/solar/ leitet an die Steuerung der Solaranlage usw. Das ganze ist nicht nur auf HTTP-Anfragen begrenzt. HAProxy kann auch mehrere Zertifikate verwalten und auch diese dann richtig zuordnen. Ein Aufruf von https://meindienst.srvhome.de/thermostat/ kann dann intern weiter ein HTTP-Aufruf sein, nach außen ist die Datenübertragung dann verschlüsselt ohne das der Thermostat die Fähigkeit der verschlüsselung besitzen muß… Cool oder?

Die Lösung hierfür ist HAProxy. Lese unter ‘Ich habe mehrer Dienste die ich verwenden möchte, wie geht das?’ wofür das gut ist. HAProxy kann auch mit mehr als einem Zertifikat umgehen. Hier ein dank an ‘Willy Tarreau’ der HAProxy ins leben gerufen hat.

Das ist kein Problem des DNS-Eintrages sondern dem Umstand geschuldet das von einem 'internen' Netz nicht auf die 'externe' eigene IP zugegriffen werden kann wenn dies nicht explizit in der Firewall vorgesehen ist. Der DYN-DNS-Eintrag zeigt aber auf die 'externe' IP. Das ganze über die Firewall zu regeln ist nur ein Weg, der steinigste Weg. Einfacher geht das über einen DNS-Eintrag in meinem Router (z.B. Fritzbox). Ich habe in sehr vielen Routern die Möglichkeit den eigenen IP's einen DNS-Namen zu geben. Nehmen wir an, mein DYN-DNS-Name lautet 'peter.srvhome.de'. Wenn ich nun in meinem Router der IP des Web-Servers (192.168.1.22) den DNS-Namen 'peter.srvhome.de' gebe, dann werde ich bei der Eingabe dieses Namens im Browser auf meinen Webserver landen. Und wofür dann ein DYN-DNS? Bin ich Zuhause, wird mein Router die DNS-Einträge bereitstellen. Kennt der Router den Eintag nicht, dann wird der Router extern anfragen wie die IP lautet. Wenn ich nun unterwegs bin wird die Namensauflösung durch die Server stattfinden die der Mobil-Anbieter bereitstellt und der wird dann bei srvhome.de anfragen. Und wenn ich nun bei einem Freund im Netz bin? Nun, der Router des Freundes weiß nichts von einem internen Eintrag. Dessen Router wird auch bei srvhome.de anfragen und erhält die richtige IP.

Der Kontakt zu uns

Fragen? Anregungen? Kontaktiere uns !

Alle Felder mit (*) gekennzeichnet sind notwendig.

All Rights Reserved | Copyright 2016 © The Bizium template by pFind's Goodies