Auf diesem – seit einigen Jahren veranstalteten – Forum treffen sich auch in diesem Jahr wieder eine Vielzahl von Anbietern und Anwendern von Remote-Technik (und damit auch M2M über Mobilfunk/GPRS/EDGE/UMTS).

Die Vortrags-Sessions:

• IT-Security und Kommunikation für Hersteller und Betreiber
• Verkaufbare Services einführen und managen mit Best-practice und Integration
• Mobile Funklösungen für Kommunikation und Security
• Serviceplattformen am Beispiel der Medizintechnik
• Serviceplattformen in Maschinenbau und anderen Branchen
• ConditionMonitoring und Datamining für predictive Maintenance
• Remote in der Haustechnik

Die große Bandbreite macht aus meiner Sicht den Reiz der Veranstaltung aus. Von Anwendungsbeispielen wie “Beste Milchqualität von 15 Millionen Kühen” über technische Themen “Mit OpenVPN zur sicheren Remote- Kommunikation” bis hin zu Geschäftsmodellen “Digitale Wertschöpfung durch mobile Service- Lösungen” wird ein intressanter Überblick geboten.

Am 11. Februar wird die Veranstaltung durch einen Workshoptag mit den Themen “Mit Sicherheit gute Remoteservice” und “Bezahlte Remoteservices einführen oder den Verkauf forcieren” abgerundet.

Auf den ersten Blick fehlt bei dieser Veranstaltung aus meiner Sicht nur das Thema Datenschutz.

OpenVPN findet auch in M2M-Hardware (z.B. Mobilfunk-Routern) und M2M-Diensten (z.B mdex fixed.IP) zunehmend Verbreitung. Die Gründe hierfür sind sicher vielfältig, u.a.:

• “kostenlos” und Open Source
• im Vergleich zu IPSec sehr einfach zu konfigurieren
• sicher, effektiv und robust
• für praktisch alle Plattformen erhältlich

Der am 18.12.2008 neu gegründete Verein will sich nun verstärkt um den Bereich Community/Support (Forum, ehemals “OpenVPN-Forum.de”) und der Dokumentation (Wiki) widmen. Der Vorstand outet sich in seinem Mailing an die Mitglieder des OpenVPN-Forum.de wie folgt:

Welche Ziele verfolgt der Verein?

In erster Linie dient der Verein der Stärkung der Community rund um OpenVPN. Um dieses Ziel zu erreichen, planen wir eine Erweiterung und Vergrößerung unseres bisherigen Angebots:

• mehrsprachiges Forum
• mehrsprachige Knowledgebase
• Integration der bestehenden Bestandteile in ein einheitliches Portal
• Verbesserung der Zuverlässigkeit und Geschwindigkeit unserer Dienste
• bessere Verbreitung von OpenVPN in Hard- und Softwarelösungen
• Aufbau einer besseren Kommunikation zwischen Entwicklern rund um OpenVPN und Partnerprojekten

Mitglied können sowohl Privatpersonen als auch Unternehmen werden. Sollten wir euer Interesse geweckt haben so könnt ihr euch für weitere Infomationen auf portal.openvpn.eu informieren.

Aus meiner Sicht ein wirklich gutes Vorhaben das die Unterstützung aller Nutzer von OpenVPN – und das sind schon sehr viele – verdient.

Ein auf einer stabilen organisatorischen und finanziellen Basis operierendes Forum und Wiki können für die Open Source Lösung OpenVPN einen optimalen Support bieten. Häufig besser (und menschlicher) als irgendwelche exorbitant bepreisten silver/gold oder platinum Vereinbarungen global operierender Konzerne.

OpenVPN auf dem M2M-Blog: http://m2m-blog.de/tag/openvpn/


@Eike: Vielen Dank für den Hinweis!

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 aktuelle MOROS unterstützt nun GPRS/EDGE Class 12 und funkt somit bis zu 230 kBit/sec schnell. Die Steigerung der Geschwindigkeit macht sich insbesondere bei der Anbindung kompletter Netzwerke und der Fernwartung positiv bemerkbar.

Die restlichen Eigenschaften blieben unverändert:

Der Alleskönner der Regensburger bringt – mit Ausnahme eines Netzteiles – alles mit, was man benötigt, um einen industietauglichen Fernzugriff auf einzelne Geräte oder ganze IP-Netze zu realisieren. Je nach Anforderung per Mobilfunk (GPRS oder Dial-Up), ISDN oder analogem Telefonnetz.

In der Variante PRO werden zusätzlich sichere Verbindungen auf Basis von OpenVPN (Client- und Server) und Redundanz per Dial-Back-Up unterstützt.

Interessant:
Auf dem Gehäuse des MOROS sind auch Felder zur Kennzeichnung des Übertragungsstandards vorhanden, heute sind GPRS und EDGE genutzt. Das Feld UMTS ist auch schon vorhanden. Wir können nun tippen, wann MOROS denn nun auch als UMTS Version verfügbar sein wird. Vielleicht zur SPS/Drives im November 2008?

In diesem Zusammenhang vielleicht auch interessant:
EDGE – Sinn oder Unsinn für M2M-Anwendungen?
Praxistest: Geschwindigkeit von EDGE

Im Mittelpunkt stehen natürlich die jeweiligen EXOR-Produkte:

• Zur Fernwartung: Der sog. ServiceRouter (UMTS Router auf Linux-Basis mit OpenVPN)
• Zum Fernwirken: iCEX (cellular & ethernet explorer) – ein Datenlogger, der Zustandsänderungen von SPS über verschiedene Modems (u.a. auch GPRS) an einen speziellen OPC-Server übertragen kann.

Der Themenüberblick der Veranstaltung:

1. Tag: Fernwarten mit dem ServiceRouter über Ethernet oder UMTS/HSDPA

• Grundlagen der Netzwerktechnik
• Netzwerkplanung für die Workshop Anwendung
• ServiceRouter Konfiguration, Konfiguration der WAN und LAN Seite, erstellen eines 1024bit VPN Zertifikates, erstellen von VPN Client Schlüsseln
• Verbindungsaufbau über UMTS/HSDPA in die SPS

2. Tag: Fernwirken mit iCEX über GPRS, Zugriff auf Maschinendaten Weltweit

• Aufbau der Applikation mit iCEX, RealityGateway, ROPC. Grundlegende Funktion und Kommunikation.
• Planung der zu erstellenden Anwendung
• Konfiguration des iCEX und des Reality Gateways
• Konfiguration des ROPC
• Projektierung einer Vuniq SCADA Visualisierung
• Steuern über Handy
• Zusammenfassung, Fragen, Abschlussdiskussion

Die zweitägige Veranstaltung kostet 900,– EUR zzgl. MwSt. und findet 2008 am 12./13. Juni und 23./24. Oktober in Wuppertal statt. Wer Interesse hat, kann sich mit diesem Formular anmelden.

Schade ist, dass man die Tage nicht einzeln buchen kann, denn aus meiner Sicht sind die Zielgruppen für die beiden Tage durchaus unterschiedlich.


Zum Vergleich:

• Beispielsweise bietet die Firma SKS Kommunikationssysteme GmbH zum Thema Fernwirken eine Lösung auf Basis eines sehr ähnlichen Konzeptes an: Die Übermittlung der Zustandsänderungen der SPS erfolgt über eine erweiterte Firmware eines GPRS/UMTS-Modems, die Visualierung auf einem zentralen Server.
• Über weltweite Fernwartung mit OpenVPN habe ich hier einen Artikel geschrieben.

Heute wird dazu meist (noch) auf den guten alten analogen Telefonanschluß zurückgegriffen, eine einfache und recht zuverlässig funtionierende Technik. Allerdings mit einigen Einschränkungen:

• Wenn der Kunde nicht die Leitung stellt, entsteht ein erheblicher logistischer Aufwand zur Schaltung des Telefonanschlusses.
• Wenn der Kunde einen Anschluß seiner Telefonanlage stellt: Achtung vor Änderungen! Eine Umstellung beim Kunden auf VoIP (Voice over IP) ist häufig ein überraschendes Ende für die Modemtechnik.
• Wenn kein analoger Telefonanschluß möglich ist, muss meist auf ein GSM-Modem ausgewichen werden. Bei Wählverbindungen (CSD – Circuit switched Data) ist die Datenrate aber meist auf magere 9600 Bit/sec begrenzt.
• Wenn regelmäßig Informationen abgerufen werden sollen, entstehen hohe Verbindungsgebühren.
• Wenn nur bei Bedarf angewählt wird – z.B. zur Fernwartung – werden Leitungsausfälle nicht erkannt. Fehlermeldungen kommen so evtl. nicht “durch”.

Lange Zeit war dieser Weg “State of Art” und tatsächlich auch meist die einzige Möglichkeit.

Mit der für wirtschaftlich interessante Bereiche flächendeckenden Ausbreitung von Mobilfunk (Coverage Maps) und Internet ergibt sich aber eine interessante – und in vielen Belangen – überlegene Alternative:

OpenVPN-Tunnel durchs Internet mit GPRS/EDGE/UMTS-Terminierung am Endgerät

Nutzt man das Internet für die internationale Verbindung und für die lokale Anbindung des Endgerätes ein lokales Mobilfunknetz, so ergibt sich etwa folgendes Bild:

Im Detail:

• Als Endgerät findet ein GPRS (oder EDGE/UMTS/HSDPA) Router mit integriertem OpenVPN Client (hier gibts eine Übersicht) Verwendung.
• Der Router nutzt eine lokale SIM-Karte um sich über den lokalen APN mit dem Internet zu verbinden.
• Wenn in der Anlage keine Mobilfunk-Coverage vorhanden ist, kann auch jeder andere Internet-Zugang genutzt werden (z.B. DSL, Wimax oder Kabel-Modem).

Der Clou:

Der Roaming-Vorgang (d.h. die Grenzüberschreitung) findet im Internet statt – zum Nulltarif, denn im Internet kennt man keine Roaming-Aufschäge.

Im Ergebnis erhält man einen weltweiten, sicheren und günstigen Remote-Zugang. Da sich die GPRS-Tarife weltweit häufig in etwa gleichen (meist sogar günstiger als in Deutschland), muss eine Fernwartung einer Anlage im Ausland nicht teurer sein als die einer Anlage in Deutschland!

Die Kosten
Monatlich sind zwischen 15 EUR und 35 EUR für ein großes GPRS-Datenpaket bzw. Flatrate auf Anlagenseite zu kalkulieren. Weitere Verbindungsabhängige Gebühren fallen nicht an – für weltweite Fernwartung ist das eher ein “Schnäppchen”.

Warum OpenVPN?
Verbindungen zu GPRS/EDGE/UMTS-Endgeräten haben einige Hürden zu überwinden, z.B. private und dynamische IP-Adressen (und das daraus resultierende NAT) und die Firewall des jeweiligen Mobilfunknetzes. Mit OpenVPN lassen sich diese Hürden einfach und elegant überwinden:

• Ein Router mit OpenVPN kann automatisch (von “innen” heraus) aus dem Mobilfunknetz die Verbindung mit dem Server initiieren.
• OpenVPN kommt ohne Probleme mit NAT zurecht (ist beim Übergang von Mobilfunknetzen auf das Internet fast immer anzutreffen)
• OpenVPN schafft einen performanten und sicheren Tunnel duch das “wilde” Internet
• OpenVPN ist einfach (im Vergleich zu IPsec sehr einfach) zu konfigurieren

Die Zentrale?
Einen Haken hat das Konzept aber doch noch: In der Zentrale muss ein OpenVPN-Server aufgebaut werden. Nach etwas Einarbeitung für Firmen mit IT-Abteilung sicher kein unlösbares Problem, aber auch an die Umgebung (Rechenzentrum, Redundanz, 24/365 Wartung) muss gedacht werden.

Aber es gibt auch Dienstleister, die professionell betriebene OpenVPN-Zugänge auf monatlicher Basis vermieten und so dem Thema die Komplexität und den Schrecken nehmen:

Die Firma mdex bietet mit dem Produkt fixed.IP einen professionell betriebenen OpenVPN Anlaufpunkt für praktisch alle Router mit OpenVPN (auch für DSL-Endgeräte).

Der Routerhersteller eWon bietet zur Kundenbindung mit Talk2M einen ähnlichen Dienst an: Nur für Endgeräte der eigenen Marke und beschränkt auf immer nur eine jeweils manuell zu startende aktive Verbindung (d.h. kein “always online”, sondern i.d.R. Wakeup per SMS).

Resourcen zu OpenVPN im Internet:

• OpenVPN Homepage
• Deutsches OpenVPN Portal mit Forum und Wiki

In diesem Zusammenhang vielleicht auch interessant:

• M2M mit OpenVPN: Betrachtung von Overhead und Datenvolumen

Konkret befassen sich die Veranstaltungen mit dem Insys- Produkt MoRoS (Modem- Router – Switch), dem Schweizer Taschenmesser der Regensburger. MoRoS bringt – mit Ausnahme eines Netzteiles – alles mit, was man benötigt, um einen industietauglichen Fernzugriff auf einzelne Geräte oder ganze IP-Netze zu realisieren. Je nach Anforderung per Mobilfunk (GPRS oder Dial-Up), ISDN oder analogem Telefonnetz. In der Variante PRO werden zusätzlich sichere Verbindungen auf Basis von OpenVPN (Client- und Server) und Redundanz per Dial-Back-Up unterstützt.

Wer eine M2M-Anwendung plant oder sich für die Technologie interessiert, sollte sich nicht davon abschrecken lassen, dass die Veranstaltung offiziell MoRoS Infonachmittag heißt. In der Agenda wird neben der Produktvorstellung auch eine kurze Erläuterung Industrial Ethernet und TCP/IP, eine LIVE Demo und Raum für Diskussionen versprochen.

Wann hat man schon einmal die Möglichkeit sich kompakt, kostenlos und häufig auch in der Nähe zum Stand von M2M – auch über Mobilfunk – zu informieren?

Die auf der Veranstaltung vorgestellten Funktionsweisen können allgemeingültig auch mit anderen Routern nachvollzogen werden. Allerdings wird die Meßlatte aufgrund des Funktionsumfanges des MoRoS vermutlich recht hoch gelegt.

Die Termine:

• Kassel, 01.04.2008
• Osnabrück, 10.04.2008
• Nürnberg, 15.04.2008
• Ludwigsburg, 16.04.2008
• Rosenheim, 29.04.2008
• Bremen, 06.05.2008
• Koblenz, 08.05.2008
• Reutlingen, 27.05.2008
• Dresden, 29.05.2008

Anmelden kann man sich hier auf der Website von Insys.

[UPDATE]

INSYS hat noch einmal zwei Termine nachgelegt:

• Bremen, 17.06.2008
• Ludwigsburg, 03.07.2008

Unter der Überschrift “Nicht ganz dicht” gab es einen Bericht über die Gefahren der Fernwartung von Maschinen in der Produktion:

“Hightech-Maschinen werden nicht von Menschen gesteuert, sondern von Computern. Darauf haben Spione und Saboteure nur gewartet: Sie nutzen Sicherheitslücken in der Produktion aus. [...]“

Weiter im Beitrag wurde beschrieben, dass in einem Beispiel in der Produktion ein Modem an die Steuerung einer CNC-Maschine angeschlossen wurde. Im beschriebenen Fall für den Zugang eines Konstruktionsbüros.

Kurz darauf kam ein Konkurrent mit genau dem dort zu produzierenden Bauteil auf den Markt. Die ungesicherte(!) Modemverbindung war das Informationsleck. Nicht untypisch wird berichtet, da in der Produktion häufig die IT-Sicherheit zu kurz komme.

Aus eigener Erfahrung gibt es noch eine weitere Ursache für den einfachem Modem-Einsatzin der Produktion: Die Umgehung der IT-Abteilung! Häufig ist ein Fernzugriff (wie hier vom Konstruktionsbüro) kaum im Unternehmen duchzusetzen, die Einrichtung eines Fernzugriffs für den Partner zu aufwändig (Firewall-Administation) oder Produktion und IT sprechen einfach nicht miteinander.

Dabei ist Abhilfe eigentlich ganz einfach:

Im Bereich der industriellen M2M Kommunikation gibt es inzwischen GPRS-Router/Modems mit integriertem VPN (z.B. MoRos Pro von Insys). Jeder Maschinenhersteller kann solch ein Gerät installieren ohne die IT-Sicherheit in der jeweiligen Produktion zu gefährden (sofern die Steuerung in der Maschine nicht routet). Eine Installation ist zudem logistisch einfach zu bewerkstelligen, außer Strom ist keine weiterer Infrastruktur (wie LAN oder Telefon) erforderlich.

Wer den Aufwand eines VPNs auf der Zentralenseite scheut, kann heute auch sehr günstig auf sog. managed VPNs (Infos z.B. hier) zurückgreifen.

Die Router sind für industrielle Anwedungen vorgesehen, die Montage erfolgt auf der Hutschiene und die Spannungsversorgung über Gleichspannung. Das “V2″ unterscheidet sich vom “L1″ lediglich durch die Unterstützung von IPSec VPNs.

Die Features im Überblick:

• Firewall und DynDNS Client
• Bidirektionale GPRS/EDGE Kommunikation
• Volle Nutzung der EDGE Bandbreite, max. 236.8 KB/s (Down-/Uplink)
• Ethernet Schnittstelle zur Applikation
• DHCP-Server
• Eingangsspannungsbereich (12…60 VDC)
• Temperaturbereich (-20 °C bis +60 °C)
• IPsec VPN-Tunnel (nur “V2″)

Quelle: Pressemitteilung Dr. Neuhaus Telekommunikation vom 21.2.2008

Wer sich für das Innenleben des “V2″ interessiert, wird bei Innominate fündig. Die VPN-Einheit kommt von dort. [Korrektur]: Das TAINY EMOD basiert nicht mehr auf dem innominate mGuard wie das Vorgängermodell Tainy GMOD. Das TAINY EMOD läuft unter Linux 2.6 auf einem ARM9 von Atmel.

Drei Anmerkungen fallen mir dazu ein:

1. DynDNS ist nicht immer so ohne weiteres in den GPRS/EDGE/UMTS-Netzen in Deutschland möglich. Dazu braucht man eine öffentliche IP-Adresse und die bekommt an häufig einfach nicht. Beispielweise weil der Tarif an einen speziellen APN gekoppelt ist (wie bei Vodafone M2M-Tarifen). Auch bei privaten APNs (T-Mobile IP VPN, Vodafone CorporateDataAccess) gibts private IPs.
2. Wer mit öffentlichen IP-Adressen (und DynDNS) arbeitet, muss sich darüber im klaren sein, dass er auch jedes IP-Paket was er aus dem “wilden Internet” empfängt, auch bezahlen muss. Und das – jeder der schon einmal in einen Firewall-Log geschaut hat kennt es – kann ein stetiger Strom sein. Ein großes Datenpaket ist also Pflicht!
3. Für das V2 hätte ich mir zusätzlich (oder alternativ) zu IPsec noch OpenVPN gewünscht, dieser Open-Source-Tunnel auf Basis von SSL verbreitet sich auch in der M2M-Welt immer mehr und kommt zudem auch ohne Probleme mit NAT klar. Aber das kann ja noch mit der nächsten Firmware-Version kommen.
   

.Vergleichbare Router für die Hutschiene gibt es z.B. auch bei:

• INSYS (Moros und MorosPro Router)
• netModule (NB2210)
• Hy-Line (trueCon)