Tre adressebeslutninger før du setter IoT-sensorer bak en VPN
Tre adresser gjør tre jobber: den offentlige huben, den autentiserte nettstedspartneren og sensorens private adresse. Planlegg hver av dem før du tildeler noe offentlig.
Tre adresser blandes sammen i hver IoT-over-VPN-plan, og de er ikke samme type beslutning. Én er hvordan en fjernoperatør finner tunnelendepunktet, én er hvordan nettstedet beviser at det er nettstedet, og én er hvor tjenesten til sensoren faktisk lytter. Svar dem i den rekkefølgen, og designet faller stort sett ut av seg selv. Svar dem som ett spørsmål, og du ender med å tildele offentlige adresser til enheter som aldri trengte en. En sensor bak en utgående nettstedstunnel er nåbar for en autorisert operatør uten noen innkommende regel som peker på sensoren.
Start med hvem som initierer
Hvem som ringer, bestemmer nesten alt videre. Når nettstedet ringer til en hub, trenger nettstedet ingen innkommende nåbarhet, og huben trenger et navn eller en adresse som nettstedet kan slå opp. Det ene valget fjerner det meste av debatten om statisk offentlig adressering før den begynner.
De tre rollene skilles så rent, og tabellen nedenfor er den korteste formen for beslutningen.
| 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 |
Hver rad har en annen eier, og det er det egentlige poenget. Huben tilhører den som driver VPN-tjenesten, nettstedspartneren nettverksteamet, og sensorens adresse den som eier enheten.
Hubadressen er oppstart, ikke en destinasjon
Et navn som løses opp til en vedlikeholdt offentlig adresse, er nok for huben. En DNS-post kan følge endepunktet når det flytter seg, uten å redigere hver nettstedskonfigurasjon for hånd. Det DNS ikke gjør, er å skape nåbarhet eller oppdatere en klient som bufrer det gamle svaret, og det er separate problemer med separate løsninger.
Hvis du kjører nettsted-til-nettsted-tunneler uten hub, gjelder samme logikk i en annen form: én side trenger et nåbart endepunkt, eller begge sider ringer en tredjepart. Noen må fortsatt eie den adressen og fornyelsene av den.
Nettstedspartneren er en identitet med et prefiks festet
Partneren er identitet først og prefiks deretter. I WireGuard-termer holder partneren et nøkkelpar, og AllowedIPs-oppføringen til huben binder den nøkkelen til prefikset til nettstedet. I IKEv2-termer identifiserer et sertifikat eller en forhåndsdelt nøkkel nettstedet, og trafikkvelgerne sier hva det kan bære. Å endre bare én halvdel bryter ordningen, og derfor må en adresseendring aldri behandles som en identitetsendring.
Hold eierskapet til nøkkelen eller sertifikatet hos nettstedet i stedet for hos huboperatøren, slik at et bytte av leverandør ikke blir et bytte av identitet.
Prefikset er delen folk glemmer å planlegge. Huben må knytte sensorens subnett til riktig partner, og klienten til operatøren trenger en rute dit; en rute som bare finnes på klienten, sender trafikk inn i en tunnel som stille slipper den. Skriv prefikset i nettstedsposten ved siden av nøkkelfingeravtrykket, slik at en utskiftet gateway ikke kan dukke opp med en annen dekning uten at noen merker det.
Sensoradressen tilhører applikasjonen
En privat adresse fra planen til nettstedet er tilstrekkelig, og det den trenger, er stabilitet framfor offentlig nåbarhet: en DHCP-reservasjon, en statisk tildeling eller et navn i nettstedets egen sone. Hvis enheten ikke kan omnummereres, er oversettelse på gatewayen til nettstedet et legitimt svar så lenge oversettelsen er dokumentert og returtrafikken følger den.
Én vane til som er verdt å beholde: lim aldri den offentlige hubadressen inn i et neste-hopp-felt på verten til sensoren. VPN-en installerer sin egen vei, og en vanlig Ethernet-naboskap til et offentlig endepunkt er en fiksjon som gir overbevisende utseende konfigurasjon.
Svar er den halvdelen som hoppes over. Enheten må sende svaret sitt tilbake mot tunnelen, enten gjennom en rute til klienten til operatøren eller gjennom samme gateway som oversatte forespørselen. En sensor med feil standardgateway godtar forespørselen og svarer ut i ingenting, og notatene om videresending forklarer hvorfor ankomst og svarruting er to krav og ikke ett.
Bestem, og skriv så grensen
Skriv ned tilgangsgrensen før noen kobler til. Begrens gatewayen til IoT-segmentet og til de spesifikke tjenestene operatøren trenger, fordi en fungerende rute har en tendens til å bli generell tilgang ved uhell. Hold overvåking kun for lesing og konfigurasjonsmyndighet som separate roller med separate identiteter, og navngi personen som fjerner tilgang når kontrakten utløper.
Godkjenning tilhører netteieren, og å være i en DMZ er ikke en tilgangspolicy.
Testen etter utrulling er kjedelig og avgjørende: én forespørsel innenfor det tillatte prefikset som lykkes, en teller som øker på gatewayen, og ett bevisst forsøk utenfor prefikset som mislykkes.