Seit einigen Tagen ist bei mdex eine neue Version der web.direct Anbindung in Betrieb. Einiges hat sich dort getan, so ist es  inzwischen möglich auch andere Ports als Port 80  zu erreichen und die Anmeldung für web.direct wurden von der my-mdex Portal-Anmeldung getrennt. Weiterhin kann die Datenübertragung zwischen dem Web-Browser des Nutzers und dem Server bei mdex nun auch per SSL verschlüsselt erfolgen.

Gerade die Trennung der Authentifizierung vom my-mdex Portal ermöglicht eine deutlich vereinfachte automatisierte Abholung von Daten von web.direct-Geräten. So kann man nun mit wenigen Zeilen Shell-Code z.B. eine regelmäßige Abholung eines Kamera-Bildes über Mobilfunk (GPRS/EDGE/UMTS/HSPA) realisieren.

Der nachfolgende Schnipsel demonstriert dies anhand einer TrendNet TV-IP110 Kamera die hinter einem Alix-basierten Mobilfunk Router per web.direct erreichbar ist:

#!/bin/sh
URL='https://admin:mypasswd@m0001115-p80.webdirect.mdex.de/cgi/jpg/image.cgi'
WDPASSWORD=mywdpasswd
 
COOKIES=$HOME/mdex-cookies.txt
HEADERS=/tmp/curl-headers-$$
 
echo Wir versuchen mal das Bild abzuholen, vielleicht ist das Cookie noch gültig
curl -s  -D $HEADERS -b $COOKIES -c $COOKIES $URL -o image.jpg
 
if grep -i 'Location:.*-login.webdirect' $HEADERS > /dev/null 2>&1 ; then
   echo Cookie nicht mehr gültig, also holen wir uns ein neues...
   curl -s -b $COOKIES -c $COOKIES  --form "password=$WDPASSWORD" \
        `grep Location: $HEADERS | sed -e 's/Location: //'` > /dev/null
 
   echo Bild nochmal abholen
   curl -s -D $HEADERS -b $COOKIES -c $COOKIES $URL -o image.jpg
else
   echo Cookie war noch gültig, also war das Bild OK...
fi
 
rm $HEADERS

Grund genug, sich noch einmal Gedanken über die Eignung von DynDNS für M2M-Anwendungen mit Endgeräten im Mobilfunk (GPRS/EDGE und UMTS/HSDPA) zu machen. Spannend sind neben evtl. auftretenden Störungen auch der “Schritt zurück” – ein Blick auf die Details.

DynDNS?

DynDNS – als Synonym für viele vergleichbare Services (hier eine Liste) – kuriert ein Problem vieler Internetanschlüsse. Alle “kleineren” Internetanschlüsse (also z.B. DSL oder GPRS/UMTS) erhalten vom Provider eine sog. dynamische IP-Adresse, also eine Adresse die mit jeder neuen Verbindung (z.B. nach Neustart des Routers oder einer Zwangstrennung) geändert wird. Zum Surfen kein Problem, denn mit welcher IP man im Internet unterwegs ist, ist zumindest für die Funktion meist unwichtig. Problematisch wird es erst, wenn von diesem Anschluss aus ein Dienst angeboten werden soll.

DynDNS dient nun dazu einem solchen Internetanschluss einen festen DNS-Namen (z.B. M2M-Anwendung.DynDNS.org) zuzuweisen, über den dann auf diesen Dienst zugegriffen werden kann.

DynDNS ist also ein Ersatz für feste IP-Adressen. Ob DynDNS ein vollwertiger Ersatz sein kann, hängt von der Anwendung ab.

Öffentliche vs. Private IP-Adressen

Beim Einbuchen wird jedem GPRS/EDGE/UMTS-Endgerät vom Mobilfunknetz entsprechend der Konfiguration des verwendeten Zugangspunktes (APN) eine dynamische IP-Adresse zugewiesen. In den Deutschen Netzen sind dies sind dies häufig private Adressen, die im Internet nicht geroutet und daher nur in lokalen (privaten) Netzen verwendet werden. Erst beim Übergang in das Internet werden solche privaten Adressen durch den Router des Mobilfunknetzes (mittels NAT) in eine öffentliche Adresse überführt. Der Zugriff auf Mobilgeräte, denen eine private IP Adresse zugewiesen wurde, ist vom Internet aus daher auch unter Zuhilfenahme von DynDNS nicht möglich.

Firewalls der Mobilfunknetze

Aber selbst, wenn das Mobilfunknetz eine öffentliche Adresse zuweist, kann noch die Firewall des Mobilfunknetztes “im Wege stehen”. Genau dies ist im deutschen Netz von Vodafone der Fall: Endgeräten wird zwar eine öffentliche IP-Adresse zugewiesen, aber die Firewall blockt sämtliche Zugriffe aus dem Internet ab. Auch hier kann also DynDNS nicht eingesetzt werden.

Was bleibt in Deutschland?

In den deutschen Mobilfunknetzen ist mir nur ein APN im Netz von T-Mobile bekannt, der sowohl öffentliche IP-Adressen vergibt und auch einen (eingeschränkten) Zugriff aus dem Internet zulässt. In den anderen Netzen auch gegen Aufpreis Fehlanzeige – keine große Auswahl.

Checkliste für DynDNS im deutschen Mobilfunk

Zum Mobilfunknetz / zur SIM:

• Derzeit benötigen Sie eine Mobilfunkkarte von T-Mobile, die Zugangspunkte der anderen Netze sind so konfiguriert, dass ein DynDNS-Einsatz nicht möglich ist.
• Auch bei T-Mobile ist die Firewall für aus dem Internet eingehende Pakete nicht vollständig geöffnet, d.h. es geht “Vieles” (z.B. http über Port 80), aber nicht “Alles” (z.B. Ping / icmp).
• Bedenken Sie, dass auch die derzeitige Konfiguration des Netzes bei T-Mobile keine zugesicherte Produkteigenschaft ist, also ohne Ankündigung geändert werden kann. DynDNS könnte also plötzlich nicht mehr funktionieren.
• Wählen Sei ein großes Datenpaket (z.B. 300 MB oder eine Flatrate), wenn Sie DynDNS einsetzen. Denn im Mobilfunk zahlen Sie auch für unerwünschten eingehenden Verkehr, wie z.B. Portscans.

Zum DynDNS Provider:

• Wählen Sie einen DynDNS-Anbieter ihres Vertrauens. Es gibt eines große Anzahl von konstenpflichtigen, aber auch kostenlosen Angeboten.
• Überlegen Sie, ob es wirklich der Namensgeber “DynDNS.org” sein muss. Die große Bekanntheit zieht auch schon mal Denial of Service (DoS) Angriffe an, die dann alle Nutzer des Dienstes plötzlich Offline stehen lassen.
• Überlegen Sie auch, ob Sie nicht statt eines kostenlosen Dienstes lieber einen kostenpflichtigen Dienst mit einer definierten Verfügbarkeit wählen. Denn Sie bekommen “das, was Sie bezahlen” – kein Problem, wenn alles funktioniert, aber im im Falles eines Falles, sind Sie ansonsten kein Kunde, sondern Bittsteller.

Zur Hardware:

• Klar, die verwendete Hardware (oder Software) muss DynDNS unterstützen. Achten Sie aber darauf, dass der DNS-Provider frei konfigurierbar ist.
• Lassen Sie sich die volle Konformität des Routers zu DynDNS zusichern: DynDNS erlaubt zur Lastminimierung eine DNS-Aktualisierung nur nach einer effektiven Änderung der IP-Adresse. Bei häufigeren Änderungen wird man ggf. “abgeklemmt” und ist dann offline.
• Ist Ihr Router wirklich “sicher”? Wichtig, denn bei Verwendung von DynDNS steht Ihr Router ungeschützt im Internet und muss einiges aushalten. Denn auch GPRS/EDGE/UMTS-Router sind nur Computer, häufig auf Linux basierend. Sicher sind sie bei einer sorgfältigen Konfiguration und aktueller Software. Wissen Sie von Ihrem Router, ob auch alle überflüssigen Services wirklich deaktiviert sind? Sind auf Ihrem Router alle Services (z.B. telnet, ntp, ssh…) auf dem aktuellen Stand? Gibt es – für den User nicht erkennbare – Default Passwörter auf dem Router? Das hört sich paranoid an, aber mir ist zumindest ein Mobilfunkrouter bekannt, auf den alle(!) Lücken zutreffen.
• Halten Sie die Firmware Ihres Routers (oder die verwendete Software) immer aktuell.

Zum DynDNS-System:

• Systembedingt gibt es immer kleine Lücke in der Erreichbarkeit nach einem Update der IP-Adresse. Kein Problem, wenn die anfragende Applikation darauf entsprechend reagiert.
• Mails ausgehend von IP-Adressen in einem dynamisch verwalteten Bereich werden in der Regel von Mail-Servern zur Vermeidung von SPAM nicht akzeptiert. Abhilfe kann hier ein (privates) Mail-Relay schaffen.

Fazit

DynDNS ist das Standardwerkzeug, um die Erreichbarkeit von DSL-Anschlüssen mit dynamischen IP-Adressen zu gewährleisten. Mit Einschränkungen kann DynDNS auch erfolgreich für GPRS/EDGE und UMTS/HSDPA verwendet werden, allerdings nicht in den Netzen von Vodafone, E-Plus und O2. Ob DynDNS für die persönliche Anwendung passt, muss letztendlich jeder für sich abwägen.

Alternativen zu DynDNS

Für Großkunden bieten Netzbetreiber mit entsprechendem Vorlauf direkte gesicherte Zugänge in Ihre Netze an, eigentlich gedacht für die Anbindung großer Außendienstkolonnen.

Netzübergreifend bietet mdex mit dem Produkt fixed.IP Sicherheit und Erreichbarkeit durch feste IP-Adresse in geschlossenen Benutzergruppen für GPRS/EDGE und UMTS/HSDPA Endgeräte an.

Die Vorteile beim Einsatz eines VPN sind zahlreich, z.B.

• die Erreichbarkeit von über GPRS angebundenen Geräten („Provider-Firewall“)
• die Kommunikationskosten können gesenkt werden, weil Internetanbindungen meist günstiger als Direktverbindungen sind (siehe auch: M2M mit OpenVPN: Zum Ortstarif um die ganze Welt)
• die Vertraulichkeit der Daten wird gesichert: Schutz vor Manipulation, Aufzeichnung, Ausspähen, etc.
• administrativ und logistisch ergeben sich durch die zusätzliche Authentifizierung der VPN-Teilnehmer neue Möglichkeiten
• Verringerung der Latenzzeiten bei Start einer Datenverbindung

Dazu kommen spezielle Vorteile von OpenVPN:

OpenVPN ist durch seine Flexibilität, Einfachheit und Robustheit geradezu ideal, um Ordnung in die Vielzahl von unterschiedlichen Anbindungsszenarien von Maschinen und deren Fernwartung zu bringen.

Im Gegensatz zu anderen VPN-Implementierungen setzt OpenVPN nicht auf eigene Protokolle auf und kann deshalb Verbindungen in Konstellationen erzeugen, in denen andere Implementierungen chancenlos sind.

Wie jede Medaille hat auch der Einsatz von VPN zwei Seiten. Schon allein die Tatsache, dass man sich mit einer zusätzlichen Technologie befassen muss, stellt einen solchen Nachteil dar. Ein weiterer Nachteil von VPN ist, dass zusätzlicher Datenverkehr erzeugt wird. Dieser kann bei der M2M-Kommunikation für unerwartete und schwierig zu kalkulierende Kosten sorgen. Denn bei GPRS, EDGE und UMTS wird – im Gegensatz zu anderen Diensten – nicht nach Verbindungszeit sondern nach übertragenem Datenvolumen (Traffic) abgerechnet.

Im Folgenden soll der Overhead von OpenVPN betrachtet und eingeschätzt werden:

Funktionsweise von OpenVPN

Bei OpenVPN wird ein virtuelles Netzwerk erzeugt, indem der Client zunächst eine Datenverbindung zum Server herstellt und diese Verbindung aufrecht erhält. Durch diese Verbindung (auch Tunnel genannt) werden die eigentlichen Datenpakete gesendet. Die ursprünglichen Datenpakete müssen also in die Pakete eingebettet werden, die den Tunnel darstellen. Das bedeutet, dass insgesamt mehr Informationen übertragen werden müssen – ein zusätzlicher Overhead entsteht:

Betrachtung des Overhead

Dieser Overhead ist von Fall zu Fall unterschiedlich zu quantifizieren. Er hängt u.a. davon ab:

• wie das VPN konfiguriert ist und
• welche Daten übertragen werden.

OpenVPN kann Daten auf Level 2 (Bridging) oder auf Level 3 (Routing) tunneln:

Beim Bridging werden die zu tunnelnden Daten in neue Ethernet-Pakete gepackt, beim Routing in neue IP-Pakete. Daher führt Bridging zu weniger Overhead, da für die neuen Ethernet-Pakete etwas weniger zusätzliche Informationen übertragen werden müssen als für die neuen IP-Pakete beim Routing.

Bridging erscheint somit im ersten Moment sehr attraktiv, zumal sich als zusätzlicher Vorteil die einfache Vergrößerung des Netzes ergibt. In der Praxis ist Bridging aus Sicht der Netzwerkplanung allerdings nicht einsetzbar, denn der administrative Aufwand im zentralen Netz zur Berücksichtigung der Teilnehmer des erweiterten Netzes steigt. Aus diesem Grund ist Routing in den meisten Fällen die bevorzugte Variante.

Tunnel mit Hilfe von UDP-Paketen erzeugen wiederum weniger Overhead, als Tunnel mit TCP-Paketen. Per Default wird eine UDP-Verbindung bevorzugt. Dies ist nicht nur im geringeren Overhead begründet, sondern auch darin, dass die Latenzzeiten bei einem UDP-Tunnel geringer sind, als bei einem TCP-Tunnel. OpenVPN muss bei beiden Tunnelarten dafür sorgen, dass die Pakete an der Gegenstelle wieder ordentlich ausgepackt und zusammengesetzt werden. Beim bereits verbindungsgesicherten TCP tritt damit unnötige Redundanz auf.

TCP-Tunnel sollten nur eingesetzt werden, wenn sich UDP-Tunnel aus anderen Gründen, z.B. Firewall-Einstellungen nicht realisieren lassen.

Verschlüsselung der Daten vor der Übertragung

Mit OpenVPN ist es möglich, die zu tunnelnden Daten vor der Übertragung zu verschlüsseln und damit zusätzlich zu sichern. Dies ergibt zusätzlichen Overhead.

Hier ein Beispiel für den entstehenden Overhead bei einem verschlüsselten UDP-Tunnel mit Default-Einstellung:

Beim Tunneln von sehr kleinen Datenpaketen wiegt dieser Overhead schwerer als bei großen Datenpaketen. Da aber einerseits das Übertragen von sehr kleinen Datenpaketen auch ohne Tunnel bereits äußerst ineffizient ist und andererseits die 69 Byte bei großen Datenpaketen (theoretisch bis 1500 Byte) auch nicht überproportional viel mehr Traffic ausmachen, sollte der Overhead in den meisten Fällen gerechtfertigt sein.

Komprimierung

OpenVPN kann die zu tunnelnden Daten vor der Übertragung komprimieren. Zum Einsatz kommt hier der LZO-Algorithmus (Lempel-Ziv-Oberhumer). Dieser erreicht zwar nicht ganz die Komprimierungsgrade wie sie z.B. bei ZIP der Fall sind, dafür punktet LZO damit, dass sich die Daten nahezu in Echtzeit ver- und entpacken lassen.

LZO ist eine verlustlose Komprimierung, deshalb gibt es hier Grenzen. Ferner hängt der Komprimierungsgrad stark davon ab, welche Daten übertragen werden. Bereits komprimierte Daten wie z.B. gezippte Dateien oder komprimierte Bilder wie .jpg können nicht viel weiter komprimiert werden. Sehr gut komprimierbar sind Texte wie z.B. HTML, XML oder auch Bilder in Rohdatenformaten wie z.B. Bitmaps. Beim Surfen ergeben sich z.B. Komprimierungsgrade von weit über 60%.

Die per Grundeinstellung adaptive Kompression ist ein weiteres Feature von OpenVPN, um Rechenaufwand einzusparen und die Performance zu erhöhen. Dazu wird der Komprimierungsgrad überwacht. Sinkt der Komprimierungsgrad aufgrund der Datenbeschaffenheit unter einen festgelegten Wert, wird die Kompression so lange deaktiviert bis wieder komprimierbareres Datenmaterial zu versenden ist. Auf diese Weise wird zusätzlich Rechenleistung eingespart.

Weitere Aspekte

Abgesehen von dem Overhead der Tunnelpakete tritt noch zusätzlicher Traffic für das künstliche Netzwerk des VPNs auf. Einige Ursachen sind:

• Abhängig von der Art der Authentifizierung werden zur Authentifizierung Datenpakete übertragen noch bevor ein Tunnel aufgebaut ist.
• Verbindungsüberprüfung: Ein bestehender Tunnel sollte regelmäßig geprüft werden, ob er noch existiert.
• Es sollten in regelmäßigen Abständen Daten durch den Tunnel gesendet werden, damit die für den Tunnel benutzten Ports nicht von Routern geschlossen werden, die die beiden Tunnelenden verbinden (stateful Firwall).
• Vereinbarte Parameter für die Verschlüsselung der Datenpakete sollten regelmäßig erneuert werden.

Eine Beispielanwendung

Ein Feldgerät ist über einen GPRS/EDGE/UMTS-Router mit dem Internet verbunden. Der Router erstellt nach dem Verbindungsaufbau selbständig einen OpenVPN-Tunnel zu einer Leitstelle, in der ein OpenVPN Server läuft. Die Authentifizierung erfolgt über X.509 Zertifikate. Das Feldgerät erzeugt Daten (2000 Byte), die einmal pro Minuteper HTTP von der Leitstelle aus abgerufen werden sollen.

Für die einzelnen Vorgänge wird folgendes angenommen:

• Einwahl ins Internet und anschließender Tunnelaufbau: 13.000 Byte
• Erneutes Aushandeln der Verschlüsselung: 10.000 Byte
• Einmalige Verbindungsüberprüfung (Internetverbindung): 1000 Byte
• Einmalige Verbindungsüberprüfung (VPN-Tunnel): 81 Byte
• Abruf der eigentlichen Daten per HTTP: 3125 Byte

Die 3125 Byte für die eigentlichen Daten wurden empirisch ermittelt und stellen sich zusammen aus

• 2000 Byte Textdatei
• 1021 Byte TCP-Header, HTTP-Header und HTML-Code
• 104 Byte reiner OpenVPN Overhead

Das tägliche Datenaufkommen stellt sich wie folgt zusammen:

Ungefähr 10% des Datenaufkommens sind in diesem Beispiel für die Bereitstellung der Datenverbindung inklusive Tunnel notwendig. Der OpenVPN-Ping wird in diesem Fall nicht ausgeführt, denn auf die Tunnelüberprüfung wird verzichtet, wenn anderweitig Datenaufkommen existiert.

Verkürzung der Latenzzeiten

Ein großer Nachteil bei der Anbindung von Feldgeräten via GPRS kann die hohe Latenzzeit sein. Vor allem für das erste Paket nach einer längeren Übertragungspause können 1000 ms bis 2000 ms verstreichen. Mit einem OpenVPN-Tunnel und dessen Fähigkeit, mit „OpenVPN-Pings“ künstlich Datenverkehr zu erzeugen, kann man diese langen Latenzzeiten am Anfang einer Socketverbindung auf die Zeiten verringern, die sich im Laufe einer längeren Datenübertragung typischerweise einspielen. Dadurch erhöht sich zwar das Datenaufkommen, allerdings kann man auf diese Weise zeitkritische Anwendungen entschärfen, die über GPRS normalerweise nur mit Schwierigkeiten nutzbar wären und nur mit anderen Technologien wie z.B. EDGE oder UMTS funktionieren würden.

Ohne jeglichen Nutz-Datenverkehr und einem

• Ping-Intervall von 15 Sekunden vom Feldgerät zur Leitstelle und einem
• Ping-Intervall von 2 Minuten von der Leitstelle zum Feldgerät

ergibt sich aus {(4 x 60 x 24 x 81 Byte) + (30 x 24 x 81 Byte)}ein tägliches Datenaufkommen von 524.880 Byte.

Dieser „Dauerping“ kostet im Monat also ungefähr 12 MByte. Je nach Mobilfunkvertrag ist das mehr oder weniger akzeptabel und sollte sorgfältig überlegtwerden.

Fazit

Je höher das Datenvolumen ist, desto geringer wird der Anteil, der für den OpenVPN-Overhead und dessen Infrastruktur notwendig ist. Bei einem VPN mit OpenVPN kann durch die Komprimierung sogar der Effekt eintreten, dass weniger Datenaufkommen anfällt.

Resourcen zu OpenVPN im Internet:

• OpenVPN Homepage
• Deutsches OpenVPN Portal mit Forum und Wiki

Der DynDNS-Service wird dazu benutzt, um einem Gerät mit einer öffentlichen, aber dynamsich wechselnden IP-Adresse einen festen DNS-Namen (z.B. M2M-Anwendung.DynDNS.org) zuzuweisen. Über eine spezielle API kann DynDNS die aktuell gültige IP-Adresse mitgeteilt werden. DynDNS trägt diese Adresse dann in ihren DNS-Server ein. Dieser Basis-Service ist kostenlos, lediglich weitergehende Dienste, z.B. für E-Mail sind kostenpflichtig.

Auch viele für M2M-Anwendungen gebräuchliche GPRS/EDGE/UMTS-Router unterstützen DynDNS zur Adressierbarkeit aus dem Internet.

Der Ausfall von DynDNS zeigt jetzt schmerzlich die Abhängigkeit von vermeintlich permanent kostenlos verfügbaren Resourcen.

M2M-Anwendungen, die auf DynDNS basieren sind derzeit nicht erreichbar.

Da Nutzer des kostenlosen Dienstes keinen Vertrag oder SLA haben, können sie derzeit nur warten und hoffen.

Anwendungen, die eine feste IP-Adresse nutzen, sind nicht betroffen.

Feste IP-Adressen für alle SIM-Karten von T-Mobile und Vodafone bekommt man bei mdex. Die Firma I.T.E.N.O.S bietet für SIMs der Marke White ebenfalls eine Option an.

In diesem Zusammenhang vielleicht auch interessant:

• DynDNS für M2M-Anwendungen mit GPRS/EDGE/UMTS?