Drie adresbesluite voordat jy IoT-sensors agter 'n VPN plaas
Drie adresse doen drie take: die publieke hub, die geauthentiseerde werfportuur en die sensor se private adres. Beplan elkeen voordat jy iets publieks toeken.
Drie adresse raak in elke IoT-oor-VPN-plan verstrengel, en hulle is nie dieselfde soort besluit nie. Een is hoe 'n afgeleë operateur die tonnel-eindpunt vind, een is hoe die werf bewys dat dit die werf is, en een is waar die sensor se diens werklik luister. Beantwoord hulle in daardie orde en die ontwerp val meestal vanself uit. Beantwoord hulle as 'n enkele vraag en jy eindig daarmee om publieke adresse toe te ken aan toestelle wat nooit een nodig gehad het nie. 'n Sensor agter 'n uitgaande werftonnel is bereikbaar vir 'n gemagtigde operateur sonder enige inkomende reël wat na die sensor wys.
Begin by wie inisieer
Wie skakel bepaal byna alles verder. Wanneer die werf na 'n hub uitbel, het die werf geen inkomende bereikbaarheid nodig nie, en die hub het 'n naam of adres nodig wat die werf kan oplos. Daardie enkele keuse verwyder die meeste van die statiese publieke adresseringsdebat voordat dit begin.
Die drie rolle skei dan netjies, en die tabel hieronder is die kortste vorm van die besluit.
| 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 ry het 'n ander eienaar, en dit is die werklike punt. Die hub behoort aan wie ook al die VPN-diens bedryf, die werfportuur aan die netwerkspan, en die sensoradres aan wie die toestel besit.
Die hub-adres is opstart, nie 'n bestemming nie
'n Naam wat na 'n onderhoude publieke adres oplos, is genoeg vir die hub. 'n DNS-rekord kan die eindpunt volg wanneer dit beweeg, sonder om elke werfkonfigurasie met die hand te redigeer. Wat DNS nie doen nie, is bereikbaarheid skep of 'n kliënt verfris wat die ou antwoord kas nie, en dit is aparte probleme met aparte oplossings.
As jy werf-tot-werf-tonnels sonder 'n hub bedryf, geld dieselfde logika in 'n ander vorm: een kant het 'n bereikbare eindpunt nodig, of beide kante bel 'n derde party. Iemand moet steeds daardie adres en die hernuwing daarvan besit.
Die werfportuur is 'n identiteit met 'n voorvoegsel daaraan
Die portuur is eerste 'n identiteit en tweede 'n voorvoegsel. In WireGuard-terme hou die portuur 'n sleutelpaar en die hub se AllowedIPs-inskrywing bind daardie sleutel aan die werf se voorvoegsel. In IKEv2-terme identifiseer 'n sertifikaat of vooraf gedeelde sleutel die werf, en sy verkeerskeuses sê wat dit mag dra. Om enige helfte alleen te verander breek die reëling, en daarom mag 'n adresverandering nooit as 'n identiteitsverandering behandel word nie.
Hou sleutel- of sertifikaat-eienaarskap by die werf eerder as by die hub-operateur, sodat 'n verandering van verskaffer nie 'n verandering van identiteit word nie.
Die voorvoegsel is die deel wat mense vergeet om te beplan. Die hub moet die sensor-subnet aan die regte portuur koppel, en die operateur se kliënt het 'n roete daarvoor nodig; 'n roete wat net op die kliënt bestaan, stuur verkeer in 'n tonnel in wat dit stilweg laat val. Skryf die voorvoegsel in die werfrekord langs die sleutelvingerafdruk, sodat 'n vervangingspoort nie ongemerk met ander dekking kan opkom nie.
Die sensoradres behoort aan die toepassing
'n Private adres uit die werf se plan is genoeg, en wat dit nodig het, is stabiliteit eerder as publieke bereikbaarheid: 'n DHCP-reservering, 'n statiese toekenning, of 'n naam in die werf se eie sone. As die toestel nie hernommer kan word nie, is vertaling op die werfpoort 'n geldige antwoord solank die vertaling gedokumenteer is en die terugkeerverkeer dit volg.
Nog 'n gewoonte wat die moeite werd is om te hou: plak nooit die publieke hub-adres in 'n volgende-hop-veld op die sensor se gasheer nie. Die VPN installeer sy eie pad, en 'n gewone Ethernet-aangrensing aan 'n publieke eindpunt is 'n fiksie wat oortuigende voorkoms in konfigurasie lewer.
Antwoorde is die helfte wat oorgeslaan word. Die toestel moet sy antwoord terug na die tonnel stuur, hetsy deur 'n roete na die operateur se kliënt of deur dieselfde poort wat die versoek vertaal het. 'n Sensor met die verkeerde verstekpoort aanvaar die versoek en antwoord in niks in, en die aanstuur-notas verduidelik waarom aankoms- en antwoordroetering twee vereistes is eerder as een.
Besluit, dan skryf die grens
Skryf die toegangsgrens neer voordat iemand koppel. Beperk die poort tot die IoT-segment en tot die spesifieke dienste wat die operateur nodig het, want 'n werkende roete word dikwels per ongeluk algemene toegang. Hou lees-alleen-monitering en konfigurasiegesag as aparte rolle met aparte identiteite, en noem die persoon wat toegang verwyder wanneer die kontrak eindig.
Goedkeuring behoort aan die netwerkeienaar, en om in 'n DMZ te wees is nie 'n toegangsbeleid nie.
Die toets ná ontplooiing is vervelig en afdoende: een versoek binne die toegelate voorvoegsel wat slaag, 'n teller wat op die poort toeneem, en een doelbewuste poging buite die voorvoegsel wat misluk.