Trei decizii de adresă înainte de a pune senzori IoT în spatele unui VPN
Trei adrese îndeplinesc trei roluri: hubul public, partenerul de site autentificat și adresa privată a senzorului. Planificați fiecare înainte de a aloca ceva public.
Trei adrese se încurcă în orice plan IoT prin VPN, și nu sunt același tip de decizie. Una este cum un operator la distanță găsește punctul final al tunelului, alta este cum site-ul dovedește că este site-ul, și alta este unde serviciul senzorului chiar ascultă. Răspundeți în acea ordine și proiectarea iese aproape de la sine. Răspundeți ca la o singură întrebare și veți ajunge să atribuiți adrese publice unor dispozitive care nu au avut niciodată nevoie de una. Un senzor din spatele unui tunel de site ieșind este accesibil pentru un operator autorizat fără nicio regulă de intrare care să indice spre senzor.
Începeți cu cine inițiază
Cine apelează determină aproape tot restul. Când site-ul apelează un hub, site-ul nu are nevoie de accesibilitate de intrare, iar hubul are nevoie de un nume sau o adresă pe care site-ul o poate rezolva. Această singură alegere elimină cea mai mare parte a dezbaterii despre adresarea publică statică înainte ca ea să înceapă.
Cele trei roluri se separă apoi curat, iar tabelul de mai jos este cea mai scurtă formă a deciziei.
| 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 |
Fiecare rând are alt proprietar, și acesta este punctul real. Hubul aparține celui care operează serviciul VPN, partenerul de site echipei de rețea, iar adresa senzorului celui care deține dispozitivul.
Adresa hubului este de pornire, nu o destinație
Un nume care se rezolvă la o adresă publică întreținută este suficient pentru hub. O înregistrare DNS poate urmări punctul final când acesta se mută, fără a edita manual fiecare configurație de site. Ce nu face DNS este să creeze accesibilitate sau să reîmprospăteze un client care memorează răspunsul vechi, iar acestea sunt probleme separate cu soluții separate.
Dacă operați tuneluri site-la-site fără hub, aceeași logică se aplică într-o altă formă: o parte are nevoie de un punct final accesibil, sau ambele părți apelează o terță parte. Cineva trebuie să dețină în continuare acea adresă și reînnoirile ei.
Partenerul de site este o identitate cu un prefix atașat
Partenerul este mai întâi identitate și apoi prefix. În termenii WireGuard, partenerul deține o pereche de chei, iar intrarea AllowedIPs a hubului leagă acea cheie de prefixul site-ului. În termenii IKEv2, un certificat sau o cheie partajată anticipat identifică site-ul, iar selectoarele sale de trafic spun ce poate transporta. Schimbarea doar a unei jumătăți strică aranjamentul, de aceea o schimbare de adresă nu trebuie tratată niciodată ca o schimbare de identitate.
Păstrați proprietatea cheii sau certificatului la site, nu la operatorul hubului, astfel încât o schimbare de furnizor să nu devină o schimbare de identitate.
Prefixul este partea pe care oamenii uită să o planifice. Hubul trebuie să asocieze subrețeaua senzorului cu partenerul corect, iar clientul operatorului are nevoie de o rută către ea; o rută care există doar pe client trimite traficul într-un tunel care îl aruncă în tăcere. Scrieți prefixul în înregistrarea site-ului lângă amprenta cheii, ca un gateway de schimb să nu poată apărea cu altă acoperire fără ca cineva să observe.
Adresa senzorului aparține aplicației
O adresă privată din planul site-ului este suficientă, iar ceea ce are nevoie este stabilitate, nu accesibilitate publică: o rezervare DHCP, o atribuire statică sau un nume în zona proprie a site-ului. Dacă dispozitivul nu poate fi renumerotat, traducerea pe gateway-ul site-ului este un răspuns legitim atâta timp cât traducerea este documentată și traficul de retur o urmează.
Încă un obicei care merită păstrat: nu lipiți niciodată adresa publică a hubului într-un câmp de următorul salt pe gazda senzorului. VPN-ul instalează propria cale, iar o adiacență Ethernet obișnuită cu un punct final public este o ficțiune care produce o configurație cu aspect convingător.
Răspunsurile sunt jumătatea care este omisă. Dispozitivul trebuie să trimită răspunsul înapoi spre tunel, fie prin intermediul unei rute către clientul operatorului, fie prin același gateway care a tradus cererea. Un senzor cu gateway-ul implicit greșit acceptă cererea și răspunde în gol, iar notele despre redirecționare explică de ce sosirea și rutarea răspunsului sunt două cerințe, nu una.
Decideți, apoi scrieți limita
Scrieți limita de acces înainte ca cineva să se conecteze. Restrângeți gateway-ul la segmentul IoT și la serviciile specifice de care are nevoie operatorul, pentru că o rută funcțională tinde să devină acces general din greșeală. Păstrați monitorizarea doar în citire și autoritatea de configurare ca roluri separate cu identități separate și numiți persoana care retrage accesul la încheierea contractului.
Aprobarea aparține proprietarului rețelei, iar faptul de a fi într-un DMZ nu este o politică de acces.
Testul după implementare este plictisitor și concludent: o cerere în interiorul prefixului permis care reușește, un contor care crește pe gateway și o încercare deliberată în afara prefixului care eșuează.