Drei Adressentscheidungen, bevor IoT-Sensoren hinter ein VPN kommen
Drei Adressen erfüllen drei Aufgaben: der öffentliche Hub, der authentifizierte Standort-Peer und die private Adresse des Sensors. Planen Sie jede, bevor Sie etwas Öffentliches vergeben.
Drei Adressen verheddern sich in jedem IoT-über-VPN-Plan, und sie sind nicht dieselbe Art von Entscheidung. Eine ist, wie ein entfernter Betreiber den Tunnelendpunkt findet, eine ist, wie der Standort beweist, dass er der Standort ist, und eine ist, wo der Dienst des Sensors tatsächlich lauscht. Beantworten Sie sie in dieser Reihenfolge, und das Design ergibt sich meist von selbst. Beantworten Sie sie als eine einzige Frage, und Sie landen beim Zuweisen öffentlicher Adressen an Geräte, die nie eine brauchten. Ein Sensor hinter einem ausgehenden Standorttunnel ist für einen autorisierten Betreiber erreichbar, ohne dass eine eingehende Regel auf den Sensor zeigt.
Beginnen Sie damit, wer initiiert
Wer wählt, bestimmt fast alles Weitere. Wenn der Standort zu einem Hub hinauswählt, braucht der Standort keine eingehende Erreichbarkeit, und der Hub braucht einen Namen oder eine Adresse, die der Standort auflösen kann. Diese eine Wahl beseitigt den größten Teil der Debatte über statische öffentliche Adressierung, bevor sie beginnt.
Die drei Rollen trennen sich dann sauber, und die Tabelle unten ist die kürzeste Form der Entscheidung.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Jede Zeile hat einen anderen Eigentümer, und das ist der eigentliche Punkt. Der Hub gehört dem, der den VPN-Dienst betreibt, der Standort-Peer dem Netzwerkteam und die Sensoradresse dem, der das Gerät besitzt.
Die Hub-Adresse ist Bootstrap, kein Ziel
Ein Name, der zu einer gepflegten öffentlichen Adresse auflöst, genügt für den Hub. Ein DNS-Eintrag kann dem Endpunkt folgen, wenn er umzieht, ohne jede Standortkonfiguration von Hand zu bearbeiten. Was DNS nicht leistet, ist Erreichbarkeit zu schaffen oder einen Client zu aktualisieren, der die alte Antwort zwischenspeichert, und das sind getrennte Probleme mit getrennten Lösungen.
Wenn Sie Standort-zu-Standort-Tunnel ohne Hub betreiben, gilt dieselbe Logik in anderer Form: Eine Seite braucht einen erreichbaren Endpunkt, oder beide Seiten wählen eine dritte Partei. Jemand muss diese Adresse und ihre Verlängerungen weiterhin besitzen.
Der Standort-Peer ist eine Identität mit angehängtem Präfix
Der Peer ist zuerst eine Identität und zweitens ein Präfix. In WireGuard-Begriffen hält der Peer ein Schlüsselpaar, und der AllowedIPs-Eintrag des Hubs bindet diesen Schlüssel an das Präfix des Standorts. In IKEv2-Begriffen identifiziert ein Zertifikat oder ein vorab geteilter Schlüssel den Standort, und seine Traffic-Selektoren sagen, was er tragen darf. Ändert man nur eine Hälfte, bricht die Anordnung, und deshalb darf eine Adressänderung niemals als Identitätsänderung behandelt werden.
Halten Sie das Eigentum an Schlüssel oder Zertifikat beim Standort statt beim Hub-Betreiber, damit ein Anbieterwechsel nicht zu einem Identitätswechsel wird.
Das Präfix ist der Teil, den man zu planen vergisst. Der Hub muss das Sensor-Subnetz dem richtigen Peer zuordnen, und der Client des Betreibers braucht eine Route dorthin; eine Route, die nur auf dem Client existiert, schickt Verkehr in einen Tunnel, der ihn still verwirft. Schreiben Sie das Präfix in den Standortdatensatz neben den Schlüsselfingerabdruck, damit ein Ersatz-Gateway nicht unbemerkt mit anderer Abdeckung hochkommen kann.
Die Sensoradresse gehört zur Anwendung
Eine private Adresse aus dem Standortplan genügt, und was sie braucht, ist Stabilität statt öffentlicher Erreichbarkeit: eine DHCP-Reservierung, eine statische Zuweisung oder ein Name in der eigenen Zone des Standorts. Wenn das Gerät nicht umnummeriert werden kann, ist Übersetzung am Standort-Gateway eine legitime Antwort, solange die Übersetzung dokumentiert ist und der Rückverkehr ihr folgt.
Eine weitere Gewohnheit, die es zu behalten lohnt: Kleben Sie die öffentliche Hub-Adresse niemals in ein Next-Hop-Feld auf dem Host des Sensors. Das VPN installiert seinen eigenen Pfad, und eine gewöhnliche Ethernet-Nachbarschaft zu einem öffentlichen Endpunkt ist eine Fiktion, die überzeugend aussehende Konfiguration erzeugt.
Antworten sind die Hälfte, die übersprungen wird. Das Gerät muss seine Antwort zurück in Richtung Tunnel schicken, entweder über eine Route zum Client des Betreibers oder über dasselbe Gateway, das die Anfrage übersetzt hat. Ein Sensor mit dem falschen Standard-Gateway nimmt die Anfrage an und antwortet ins Nichts, und die Weiterleitungsnotizen erklären, warum Ankunft und Antwort-Routing zwei Anforderungen sind und nicht eine.
Entscheiden, dann die Grenze schreiben
Schreiben Sie die Zugriffsgrenze auf, bevor sich jemand verbindet. Beschränken Sie das Gateway auf das IoT-Segment und auf die Dienste, die der Betreiber braucht, denn eine funktionierende Route wird leicht versehentlich zum allgemeinen Zugang. Halten Sie Nur-Lese-Überwachung und Konfigurationsbefugnis als getrennte Rollen mit getrennten Identitäten und benennen Sie die Person, die den Zugang entfernt, wenn der Vertrag endet.
Die Freigabe gehört dem Netzwerkeigentümer, und in einer DMZ zu stehen ist keine Zugriffsrichtlinie.
Der Test nach dem Einsatz ist langweilig und eindeutig: eine Anfrage innerhalb des erlaubten Präfixes, die gelingt, ein Zähler, der am Gateway steigt, und ein bewusster Versuch außerhalb des Präfixes, der scheitert.