Ein VPN (Virtual Private Network) baut einen verschlüsselten Tunnel zwischen zwei Endpunkten auf. Im IoT-Bereich gibst du damit meist einem Mobilfunkgerät einen sicheren Weg zurück zu deinen Servern oder deinem Firmennetz. Das Gerät verhält sich dann so, als wäre es in deinem Büro angeschlossen, obwohl es über ein öffentliches Mobilfunknetz am anderen Ende der Welt verbunden ist.
Dieser Artikel erklärt, was ein IoT-VPN ist, wann es sich lohnt und was Simbase unterstützt. Anleitungen zur Einrichtung findest du unter Private Netzwerke und IPsec.
Ein VPN-Tunnel zwischen einem Mobilfunkgerät und einem entfernten Endpunkt bietet dir:
Verschlüsselung bei der Übertragung. Der Datenverkehr im Tunnel ist für niemanden auf dem Netzwerkpfad lesbar.
Authentifizierung. Beide Seiten weisen ihre Identität nach, bevor der Tunnel steht. Geräte ohne gültige Zugangsdaten können keinen Tunnel aufbauen.
Logische Netzwerkzugehörigkeit. Sobald der Tunnel steht, erscheint das Gerät als Teil des entfernten Netzwerks. Es erreicht interne Ressourcen über deren interne Adressen.
Kontrolle über das Routing. Du entscheidest, welcher Verkehr durch den Tunnel läuft und welcher direkt ins Internet geht.
Ein VPN ersetzt TLS nicht für die Verschlüsselung auf Anwendungsebene. Es ist eine Transportschicht darunter. Die meisten IoT-Designs nutzen TLS ohnehin, ein VPN kommt nur dazu, wenn es einen konkreten Grund gibt.
Ein VPN erhöht den Betriebsaufwand und die CPU-Last auf dem Gerät. Setz es ein, wenn einer dieser Fälle zutrifft:
Geräte sollen auf interne Dienste zugreifen. Geräte müssen eine Datenbank, AD/LDAP, einen internen MQTT-Broker oder eine andere Ressource in deinem Firmennetz erreichen. Ein VPN holt das Gerät in dieses Netz.
Compliance verlangt verschlüsselten Transport über TLS hinaus. Manche regulierten Branchen (Gesundheitswesen, Behörden, Verteidigung) verlangen, dass jeder Verkehr zwischen sensiblen Endpunkten durch einen verschlüsselten Tunnel läuft, unabhängig von der Verschlüsselung auf Anwendungsebene.
Du verbindest dich mit dem Netz eines Kunden oder Partners. Viele B2B-IoT-Projekte leiten den Verkehr der SIM in das VPN des Kunden. So steuert das IT-Team des Kunden Routing und Richtlinien.
Du bündelst alles auf einen internen Endpunkt. Ein zentraler VPN-Endpunkt ist praktisch, wenn viele Geräte einen einzelnen internen Dienst erreichen müssen, den du nicht öffentlich zugänglich machen willst.
Du brauchst eine feste Quell-IP für den Geräteverkehr. Ein VPN-Konzentrator lässt den gesamten Geräteverkehr von einer Quell-IP kommen. Das vereinfacht Allowlisting auf Partnersystemen.
Du brauchst nur Verschlüsselung. Das übernimmt TLS bei HTTPS, MQTTS und jedem anderen modernen Anwendungsprotokoll.
Das Gerät spricht nur mit öffentlichen APIs. Ein VPN bringt hier nichts.
Ein einzelnes Gerät soll von außen erreichbar sein. Eine öffentliche IP ist einfacher als ein VPN.
Du willst den Standort des Geräts verbergen. Mobilfunkbetreiber wissen immer, wo das Gerät ist, und ein VPN ändert daran nichts.
Simbase unterstützt zwei Site-to-Site-VPN-Protokolle, die auf Ebene des Netzwerk-Gateways konfiguriert werden. Ein dritter Connector, NAT, gibt SIMs eine öffentliche IP ohne Tunnel:
| Protokoll | Geeignet für | Anleitung |
|---|---|---|
IPsec | Produktive Deployments, die Fernzugriff und bidirektionale Kommunikation brauchen | |
WireGuard | Gelegentlichen Zugriff auf Geräte, Prototypen und kleinere Deployments |
IPsec
WireGuard
Beide werden einmalig auf Seiten von Simbase eingerichtet. Der Verkehr deiner Flotte läuft ohne Konfiguration pro Gerät durch den Tunnel. Das ist im Betrieb viel einfacher, als auf jedem Gerät einen VPN-Client einzurichten.
Nutze IPsec, wenn Geräte dauerhaft aus deinem Netz erreichbar sein müssen, wenn Verkehr in beide Richtungen fließt oder wenn du VPN-Appliances anbindest, die dein IT-Team schon betreibt (Cisco ASA, Palo Alto, Fortinet und ähnliche). Es ist die Standardwahl für den Produktivbetrieb.
Nutze WireGuard, wenn du Geräte nur gelegentlich statt dauerhaft erreichen musst, etwa für Wartung, Diagnose oder zum Abrufen von Logs. Es ist schneller eingerichtet und leichter zu debuggen und passt daher auch gut für Prototypen.
Es gibt zwei Wege, Geräte "in ein VPN" zu bringen:
| Ansatz | Was | Wann |
|---|---|---|
Netzwerkebene (Simbase Site-to-Site) | Das Simbase-Gateway terminiert das VPN zu deinem Netz. Geräte senden ihren Verkehr ganz normal, das Routing passiert weiter oben im Netz. | Die meisten IoT-Flotten. Einfacherer Betrieb, keine Zertifikatsverwaltung pro Gerät, funktioniert mit jedem Gerät. |
Geräteebene (Client auf dem Gerät) | Jedes Gerät betreibt einen eigenen VPN-Client (OpenVPN, WireGuard usw.). | Wenn Geräte Netze erreichen müssen, zu denen Simbase keinen Tunnel hat, wenn Authentifizierung pro Gerät wichtig ist oder wenn du Site-to-Site von Simbase nicht nutzen kannst. |
Netzwerkebene (Simbase Site-to-Site)
Geräteebene (Client auf dem Gerät)
Nicht, wenn es nur um Vertraulichkeit geht. TLS schützt die Daten bei der Übertragung bereits. Ein VPN lohnt sich, wenn du Netze verbinden, eine konkrete Compliance-Vorgabe erfüllen oder den gesamten Geräteverkehr über eine Quell-IP leiten musst.
Nein. Simbase terminiert den Tunnel am Netzwerk-Gateway. Geräte senden ihren Verkehr ganz normal, das Routing passiert weiter oben im Netz. Einen Client auf dem Gerät brauchst du nur, wenn du ein Netz erreichen musst, zu dem Simbase keinen Tunnel hat, oder wenn jedes Gerät eine eigene Identität braucht.
IPsec für produktive Deployments, bei denen Geräte dauerhaften Fernzugriff und bidirektionale Kommunikation brauchen, besonders wenn dein IT-Team schon IPsec-Appliances betreibt. WireGuard für gelegentlichen Zugriff, Wartung, Diagnose oder Prototypen.
Etwas. Verschlüsselung erzeugt Overhead pro Paket, und das Routing durch einen Tunnel erhöht die Latenz gegenüber dem direkten Weg ins Internet. Bei den meisten IoT-Verkehrsmustern ist der Effekt vernachlässigbar. Bei Deployments mit hohem Durchsatz oder latenzkritischen Anwendungen solltest du ihn aber einplanen.
Private Netzwerke: WireGuard einrichten
IPsec: einen IPsec-Tunnel aufbauen
Öffentliche IPs: für Erreichbarkeit von außen ohne VPN
APN (privater APN): für eine noch engere Netzwerkintegration

