M2M mit OpenVPN – Betrachtung von Overhead und Datenvolumen

Der Einsatz von VPNs (Virtual Private Network) erfreut sich steigender Beliebtheit bei M2M-Kommunikation.

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:

	20 Byte	:	zusätzlicher IP-Header
	8 Byte	:	zusätzlicher UDP-Header
			optionale Verschlüsselung:
	20 Byte	:	HMAC-SHA1 Signatur
	16 Byte	:	Initialisierungsvektor
	4 Byte	:	Sequenznummer
	1 Byte		Include Paket Tag
	——————————————————————
	69 Byte	:	Gesamt

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 Minute per 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:

	4.500.000 Byte	:	3125 Byte Nutzdaten pro Minute x 1440 Minuten pro Tag
	26.000 Byte	:	2 x Verbindungsaufbau pro Tag
	22.152 Byte	:	24 x stündliche Verbindungskontrolle per DNS-Anfrage
	·240.000 Byte	:	24 x stündliche Key-Renegotiation
	0 Byte	:	2880 x OpenVPN-Ping (1 Ping pro Minute aus- und eingehend)
	———————————————————————————————————————————
	4.788.152 Byte	:	(ca 5 MByte) Gesamt-Datenaufkommen pro Tag.

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 überlegt werden.

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

---

Hat Ihnen dieser Beitrag gefallen? Dann schreiben Sie doch einen Kommentar, oder abonnieren Sie die Artikel und erhalten Sie automatisch neue Beiträge auf Ihrem RSS-Reader. Alternativ können Sie neue Beiträge auch per Email erhalten. Klicken Sie hier, um sich anzumelden.

M2M Weblog | Powered by WordPress | ElegantBlue is a custom theme by Nathan Rice | Translation by Jan Behrmann