Tre adressebeslutninger, før du sætter IoT-sensorer bag en VPN

Tre adresser bliver rodet sammen i enhver IoT-over-VPN-plan, og de er ikke den samme slags beslutning. Én er, hvordan en fjernoperatør finder tunnelendepunktet, én er, hvordan stedet beviser, at det er stedet, og én er, hvor sensorens tjeneste faktisk lytter. Besvar dem i den rækkefølge, og designet falder stort set ud af sig selv. Besvar dem som ét spørgsmål, og du ender med at tildele offentlige adresser til enheder, der aldrig havde brug for en. En sensor bag en udgående stedstunnel kan nås af en autoriseret operatør uden nogen indgående regel, der peger på sensoren.

Start med hvem der initierer

Hvem der ringer op, bestemmer næsten alt derefter. Når stedet ringer ud til et hub, har stedet ikke brug for indgående tilgængelighed, og hubben har brug for et navn eller en adresse, som stedet kan slå op. Det ene valg fjerner det meste af debatten om statisk offentlig adressering, før den begynder.

De tre roller skilles derefter rent, og tabellen nedenfor er den korteste form for beslutningen.

Hver række har en anden ejer, og det er den egentlige pointe. Hubben tilhører den, der driver VPN-tjenesten, stedpeeren netværksteamet, og sensorens adresse den, der ejer enheden.

Hubadressen er bootstrap, ikke en destination

Et navn, der opløses til en vedligeholdt offentlig adresse, er nok til hubben. En DNS-post kan følge endepunktet, når det flytter sig, uden at redigere hver stedkonfiguration manuelt. Det, DNS ikke gør, er at skabe tilgængelighed eller opdatere en klient, der cacher det gamle svar, og det er separate problemer med separate løsninger.

Hvis du kører sted-til-sted-tunneler uden hub, gælder samme logik i en anden form: den ene side har brug for et tilgængeligt endepunkt, eller begge sider ringer til en tredje part. Nogen skal stadig eje den adresse og dens fornyelser.

Stedpeeren er en identitet med et præfiks knyttet til

Peeren er en identitet først og et præfiks derefter. I WireGuard-termer holder peeren et nøglepar, og hubbens AllowedIPs-post knytter den nøgle til stedets præfiks. I IKEv2-termer identificerer et certifikat eller en forudelt nøgle stedet, og dets trafikvælgere siger, hvad det må bære. Ændring af kun den ene halvdel ødelægger arrangementet, og derfor må en adresseændring aldrig behandles som en identitetsændring.

Behold nøgle- eller certifikatejerskab hos stedet i stedet for hos huboperatøren, så et skift af udbyder ikke bliver et skift af identitet.

Præfikset er den del, folk glemmer at planlægge. Hubben skal knytte sensorens undernet til den rigtige peer, og operatørens klient har brug for en rute til det; en rute, der kun findes på klienten, sender trafik ind i en tunnel, der stiltiende dropper den. Skriv præfikset i stedets post ved siden af nøglefingeraftrykket, så en udskiftet gateway ikke kan dukke op med en anden dækning uden at nogen opdager det.

Sensoradressen tilhører applikationen

En privat adresse fra stedets plan er tilstrækkelig, og det, den har brug for, er stabilitet frem for offentlig tilgængelighed: en DHCP-reservation, en statisk tildeling eller et navn i stedets egen zone. Hvis enheden ikke kan omnummereres, er oversættelse på stedets gateway et legitimt svar, så længe oversættelsen er dokumenteret, og returtrafikken følger den.

Én vane mere, der er værd at beholde: sæt aldrig hubbens offentlige adresse ind i et næste-hop-felt på sensorens vært. VPN'et installerer sin egen vej, og en almindelig Ethernet-forbindelse til et offentligt endepunkt er en fiktion, der giver overbevisende udseende konfiguration.

Svar er den halvdel, der bliver sprunget over. Enheden skal sende sit svar tilbage mod tunnelen, enten gennem en rute til operatørens klient eller gennem den samme gateway, der oversatte anmodningen. En sensor med den forkerte standardgateway accepterer anmodningen og svarer ud i ingenting, og noterne om videresendelse forklarer, hvorfor ankomst og svar-routing er to krav og ikke ét.

Beslut, og skriv så grænsen

Skriv adgangsgrænsen ned, før nogen tilslutter. Begræns gatewayen til IoT-segmentet og til de specifikke tjenester, operatøren har brug for, fordi en fungerende rute har en tendens til at blive generel adgang ved et uheld. Hold overvågning kun til læsning og konfigurationsmyndighed som separate roller med separate identiteter, og navngiv den person, der fjerner adgang, når kontrakten udløber.

Godkendelse tilhører netværksejeren, og at være i en DMZ er ikke en adgangspolitik.

Testen efter udrulning er kedelig og afgørende: én anmodning inden for det tilladte præfiks, der lykkes, en tæller, der stiger på gatewayen, og ét bevidst forsøg uden for præfikset, der mislykkes.