Tre adresseavgjerder før du set IoT-sensorar bak ein VPN

Tre adresser blir blanda saman i kvar IoT-over-VPN-plan, og dei er ikkje same type avgjerd. Éi er korleis ein fjernoperatør finn tunnelendepunktet, éi er korleis nettstaden beviser at det er nettstaden, og éi er kvar tenesta til sensoren faktisk lyttar. Svar dei i den rekkjefølgja, og designet fell stort sett ut av seg sjølv. Svar dei som eitt spørsmål, og du endar med å tildele offentlege adresser til einingar som aldri trong ei. Ein sensor bak ein utgåande nettstadstunnel er nåbar for ein autorisert operatør utan noka innkomande regel som peikar på sensoren.

Start med kven som initierer

Kven som ringjer, avgjer nesten alt vidare. Når nettstaden ringjer til ein hub, treng nettstaden inga innkomande nåbarheit, og huben treng eit namn eller ei adresse som nettstaden kan slå opp. Det eine valet fjernar det meste av debatten om statisk offentleg adressering før han byrjar.

Dei tre rollene skil seg så reint, og tabellen nedanfor er den kortaste forma for avgjerda.

Kvar rad har ein annan eigar, og det er det eigentlege poenget. Huben tilhøyrer den som driv VPN-tenesta, nettstadspartnaren nettverksteamet, og adressa til sensoren den som eig eininga.

Hubadressa er oppstart, ikkje ein destinasjon

Eit namn som løyser seg opp til ei vedlikehalden offentleg adresse, er nok for huben. Ein DNS-post kan følgje endepunktet når det flyttar seg, utan å redigere kvar nettstadskonfigurasjon for hand. Det DNS ikkje gjer, er å skape nåbarheit eller oppdatere ein klient som bufrer det gamle svaret, og det er separate problem med separate løysingar.

Viss du køyrer nettstad-til-nettstad-tunnelar utan hub, gjeld same logikk i ei anna form: éi side treng eit nåbart endepunkt, eller båe sider ringjer ein tredjepart. Nokon må framleis eige den adressa og fornyingane av henne.

Nettstadspartnaren er ein identitet med eit prefiks festa

Partnaren er identitet først og prefiks deretter. I WireGuard-termar held partnaren eit nøkkelpar, og AllowedIPs-oppføringa til huben bind den nøkkelen til prefikset til nettstaden. I IKEv2-termar identifiserer eit sertifikat eller ein førehandsdel nøkkel nettstaden, og trafikkveljarane seier kva han kan bera. Å endre berre éin halvdel bryt ordninga, og difor må ei adresseendring aldri handsamast som ei identitetsendring.

Hald eigarskapen til nøkkelen eller sertifikatet hos nettstaden i staden for hos huboperatøren, slik at eit byte av leverandør ikkje blir eit byte av identitet.

Prefikset er den delen folk gløymer å planleggje. Huben må knyte subnettet til sensoren til rett partnar, og klienten til operatøren treng ei rute dit; ei rute som berre finst på klienten, sender trafikk inn i ein tunnel som stille slepp han. Skriv prefikset i nettstadsposten ved sida av nøkkelfingeravtrykket, slik at ein utskifta gateway ikkje kan dukke opp med anna dekning utan at nokon merkar det.

Adressa til sensoren tilhøyrer applikasjonen

Ei privat adresse frå planen til nettstaden er tilstrekkeleg, og det ho treng, er stabilitet framfor offentleg nåbarheit: ein DHCP-reservasjon, ei statisk tildeling eller eit namn i den eigne sona til nettstaden. Viss eininga ikkje kan omnummererast, er omsetjing på gatewayen til nettstaden eit legitimt svar så lenge omsetjinga er dokumentert og returtrafikken følgjer henne.

Ein vane til som er verd å halde på: lim aldri den offentlege hubadressa inn i eit neste-hopp-felt på verten til sensoren. VPN-en installerer sin eigen veg, og eit vanleg Ethernet-naboskap til eit offentleg endepunkt er ein fiksjon som gir ein konfigurasjon som ser overtydande ut.

Svar er den halvdelen som blir hoppa over. Eininga må sende svaret sitt tilbake mot tunnelen, anten gjennom ei rute til klienten til operatøren eller gjennom same gateway som omsette førespurnaden. Ein sensor med feil standardgateway godtek førespurnaden og svarar ut i ingenting, og notata om vidaresending forklarer kvifor framkomst og svarruting er to krav og ikkje eitt.

Avgjer, og skriv så grensa

Skriv ned tilgangsgrensa før nokon koplar til. Avgrense gatewayen til IoT-segmentet og til dei spesifikke tenestene operatøren treng, fordi ei fungerande rute har ein tendens til å bli allmenn tilgang ved eit uhell. Hald overvaking berre for lesing og konfigurasjonsmyndigheit som separate rollar med separate identitetar, og namnge personen som fjernar tilgang når kontrakten renn ut.

Godkjenning høyrer til netteigaren, og å vere i ein DMZ er ikkje ein tilgangspolicy.

Testen etter utrulling er keisam og avgjerande: éin førespurnad innanfor det tillatne prefikset som lykkast, ein teljar som aukar på gatewayen, og eitt medvite forsøk utanfor prefikset som mislykkast.