Tre decisioni di indirizzo prima di mettere sensori IoT dietro una VPN
Tre indirizzi svolgono tre compiti: l’hub pubblico, il peer del sito autenticato e l’indirizzo privato del sensore. Pianificali tutti prima di assegnare qualcosa di pubblico.
Tre indirizzi si intrecciano in ogni piano di IoT su VPN, e non sono lo stesso tipo di decisione. Uno è come un operatore remoto trova l’estremità del tunnel, uno è come il sito dimostra di essere il sito, e uno è dove il servizio del sensore ascolta davvero. Rispondi in quell’ordine e il progetto viene quasi da sé. Rispondi come a una sola domanda e finirai per assegnare indirizzi pubblici a dispositivi che non ne hanno mai avuto bisogno. Un sensore dietro un tunnel di sito in uscita è raggiungibile da un operatore autorizzato senza alcuna regola in ingresso che punti al sensore.
Inizia da chi inizia
Chi compone determina quasi tutto il resto. Quando il sito compone verso un hub, il sito non ha bisogno di raggiungibilità in ingresso, e l’hub ha bisogno di un nome o di un indirizzo che il sito possa risolvere. Questa sola scelta elimina gran parte del dibattito sull’indirizzamento pubblico statico prima ancora che inizi.
I tre ruoli si separano poi in modo netto, e la tabella qui sotto è la forma più breve della decisione.
| 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 |
Ogni riga ha un proprietario diverso, e questo è il punto vero. L’hub appartiene a chi gestisce il servizio VPN, il peer del sito al team di rete, e l’indirizzo del sensore a chi possiede il dispositivo.
L’indirizzo dell’hub è un bootstrap, non una destinazione
Un nome che risolve su un indirizzo pubblico mantenuto basta per l’hub. Un record DNS può seguire l’estremità quando si sposta, senza modificare a mano ogni configurazione di sito. Ciò che il DNS non fa è creare raggiungibilità o aggiornare un client che tiene in cache la vecchia risposta, e questi sono problemi separati con correzioni separate.
Se gestisci tunnel da sito a sito senza hub, la stessa logica vale in un’altra forma: un lato ha bisogno di un’estremità raggiungibile, oppure entrambi i lati compongono un terzo. Qualcuno deve comunque possedere quell’indirizzo e i suoi rinnovi.
Il peer del sito è un’identità con un prefisso allegato
Il peer è prima un’identità e poi un prefisso. In termini WireGuard il peer detiene una coppia di chiavi e la voce AllowedIPs dell’hub lega quella chiave al prefisso del sito. In termini IKEv2 un certificato o una chiave precondivisa identifica il sito e i suoi selettori di traffico dicono che cosa può trasportare. Cambiare una sola metà rompe l’accordo, ed è per questo che un cambio di indirizzo non va mai trattato come un cambio di identità.
Mantieni la proprietà della chiave o del certificato presso il sito invece che presso l’operatore dell’hub, così un cambio di fornitore non diventa un cambio di identità.
Il prefisso è la parte che la gente dimentica di pianificare. L’hub deve associare la sottorete del sensore al peer giusto, e il client dell’operatore ha bisogno di una rotta verso di essa; una rotta che esiste solo sul client manda il traffico in un tunnel che lo scarta in silenzio. Scrivi il prefisso nel record del sito accanto all’impronta della chiave, così un gateway sostitutivo non può comparire con una copertura diversa senza che nessuno se ne accorga.
L’indirizzo del sensore appartiene all’applicazione
Un indirizzo privato dal piano del sito è sufficiente, e ciò che gli serve è la stabilità invece della raggiungibilità pubblica: una prenotazione DHCP, un’assegnazione statica o un nome nella zona del sito stesso. Se il dispositivo non può essere rinumerato, la traduzione sul gateway del sito è una risposta legittima purché la traduzione sia documentata e il traffico di ritorno la segua.
Un’altra abitudine che vale la pena mantenere: non incollare mai l’indirizzo pubblico dell’hub in un campo di next hop sull’host del sensore. La VPN installa il proprio percorso, e un’adiacenza Ethernet ordinaria verso un’estremità pubblica è una finzione che produce una configurazione dall’aspetto convincente.
Le risposte sono la metà che viene saltata. Il dispositivo deve rimandare la risposta verso il tunnel, o tramite una rotta verso il client dell’operatore o tramite lo stesso gateway che ha tradotto la richiesta. Un sensore con il gateway predefinito sbagliato accetta la richiesta e risponde nel nulla, e le note sull’inoltro spiegano perché arrivo e instradamento della risposta sono due requisiti e non uno.
Decidi, poi scrivi il confine
Scrivi il confine di accesso prima che qualcuno si colleghi. Limita il gateway al segmento IoT e ai servizi specifici di cui l’operatore ha bisogno, perché una rotta funzionante tende a diventare accesso generale per caso. Mantieni il monitoraggio in sola lettura e l’autorità di configurazione come ruoli separati con identità separate, e nomina la persona che rimuove l’accesso alla fine del contratto.
L’approvazione appartiene al proprietario della rete, e trovarsi in una DMZ non è una politica di accesso.
Il test dopo la distribuzione è noioso e conclusivo: una richiesta dentro il prefisso consentito che riesce, un contatore che si incrementa sul gateway e un tentativo deliberato fuori dal prefisso che fallisce.