Drie adresbeslissingen voordat je IoT-sensoren achter een VPN zet
Drie adressen vervullen drie taken: de openbare hub, de geauthenticeerde sitepartner en het privéadres van de sensor. Plan elk ervan voordat je iets openbaars toewijst.
Drie adressen raken verstrengeld in elk IoT-over-VPN-plan, en het zijn niet hetzelfde soort beslissing. Eén is hoe een externe operator het tunnel-eindpunt vindt, één is hoe de site bewijst dat zij de site is, en één is waar de dienst van de sensor werkelijk luistert. Beantwoord ze in die volgorde en het ontwerp valt meestal vanzelf op zijn plaats. Beantwoord ze als één vraag en je eindigt met openbare adressen toekennen aan apparaten die er nooit een nodig hadden. Een sensor achter een uitgaande sitetunnel is bereikbaar voor een geautoriseerde operator zonder enige inkomende regel die naar de sensor wijst.
Begin met wie initieert
Wie belt bepaalt bijna alles daarna. Wanneer de site naar een hub belt, heeft de site geen inkomende bereikbaarheid nodig, en de hub heeft een naam of adres nodig dat de site kan oplossen. Die ene keuze haalt het grootste deel van het debat over statische openbare adressering weg voordat het begint.
De drie rollen scheiden zich dan netjes, en de tabel hieronder is de kortste vorm van de beslissing.
| 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 |
Elke rij heeft een andere eigenaar, en dat is het echte punt. De hub is van wie de VPN-dienst draait, de sitepartner van het netwerkteam, en het adres van de sensor van wie het apparaat bezit.
Het hubadres is bootstrap, geen bestemming
Een naam die naar een onderhouden openbaar adres oplost, is genoeg voor de hub. Een DNS-record kan het eindpunt volgen wanneer het verhuist, zonder elke siteconfiguratie met de hand te bewerken. Wat DNS niet doet, is bereikbaarheid creëren of een client verversen die het oude antwoord cachet, en dat zijn aparte problemen met aparte oplossingen.
Als je site-naar-site-tunnels zonder hub draait, geldt dezelfde logica in een andere vorm: één kant heeft een bereikbaar eindpunt nodig, of beide kanten bellen een derde partij. Iemand moet dat adres en de verlengingen ervan nog steeds bezitten.
De sitepartner is een identiteit met een prefix eraan
De partner is eerst een identiteit en ten tweede een prefix. In WireGuard-termen houdt de partner een sleutelpaar en de AllowedIPs-vermelding van de hub bindt die sleutel aan de prefix van de site. In IKEv2-termen identificeert een certificaat of vooraf gedeelde sleutel de site, en de verkeersselectoren zeggen wat zij mag dragen. Alleen één helft wijzigen breekt de regeling, en daarom mag een adreswijziging nooit als identiteitswijziging worden behandeld.
Houd eigendom van de sleutel of het certificaat bij de site in plaats van bij de hubbeheerder, zodat een wisseling van provider geen wisseling van identiteit wordt.
De prefix is het deel dat mensen vergeten te plannen. De hub moet het subnet van de sensor aan de juiste partner koppelen, en de client van de operator heeft er een route naartoe nodig; een route die alleen op de client bestaat, stuurt verkeer een tunnel in die het stil laat vallen. Schrijf de prefix in het site-record naast de sleutelvingerafdruk, zodat een vervangen gateway niet ongemerkt met andere dekking kan opkomen.
Het adres van de sensor is van de toepassing
Een privéadres uit het plan van de site is voldoende, en wat het nodig heeft is stabiliteit in plaats van openbare bereikbaarheid: een DHCP-reservering, een statische toewijzing of een naam in de eigen zone van de site. Als het apparaat niet kan worden hernummerd, is vertaling op de gateway van de site een legitiem antwoord zolang de vertaling gedocumenteerd is en het retourverkeer die volgt.
Nog een gewoonte die de moeite waard is: plak het openbare hubadres nooit in een next-hop-veld op de host van de sensor. De VPN installeert zijn eigen pad, en een gewone Ethernet-buurschap met een openbaar eindpunt is een fictie die overtuigend uitziende configuratie oplevert.
Antwoorden zijn de helft die wordt overgeslagen. Het apparaat moet zijn antwoord terug naar de tunnel sturen, ofwel via een route naar de client van de operator ofwel via dezelfde gateway die het verzoek heeft vertaald. Een sensor met de verkeerde standaardgateway accepteert het verzoek en antwoordt in het niets, en de notities over doorsturen leggen uit waarom aankomst en antwoordroutering twee vereisten zijn en niet één.
Beslis, en schrijf dan de grens
Schrijf de toegangsgrens op voordat iemand verbindt. Beperk de gateway tot het IoT-segment en tot de specifieke diensten die de operator nodig heeft, want een werkende route wordt gemakkelijk per ongeluk algemene toegang. Houd alleen-lezen monitoring en configuratiebevoegdheid als aparte rollen met aparte identiteiten, en benoem de persoon die toegang intrekt wanneer het contract eindigt.
Goedkeuring hoort bij de netwerkeigenaar, en in een DMZ staan is geen toegangsbeleid.
De test na uitrol is saai en beslissend: één verzoek binnen de toegestane prefix dat slaagt, een teller die op de gateway oploopt, en één bewuste poging buiten de prefix die mislukt.