Tri odluke o adresama prije nego IoT senzore stavite iza VPN-a
Tri adrese obavljaju tri posla: javni hub, autentificirani peer lokacije i privatna adresa senzora. Planirajte svaku prije nego što dodijelite bilo što javno.
Tri adrese se zapetljaju u svakom IoT-preko-VPN planu i one nisu ista vrsta odluke. Jedna je kako udaljeni operater pronalazi krajnju točku tunela, jedna je kako lokacija dokazuje da jeste lokacija, a jedna je gdje usluga senzora zapravo sluša. Odgovorite na njih tim redom i dizajn uglavnom ispadne sam. Odgovorite na njih kao na jedno pitanje i završite tako što dodjeljujete javne adrese uređajima kojima nikada nije bila potrebna. Senzor iza odlaznog tunela lokacije dostupan je ovlaštenom operateru bez ijednog ulaznog pravila usmjerenog na senzor.
Počnite s tim ko inicira
Ko poziva određuje gotovo sve dalje. Kada lokacija poziva hub, lokaciji ne treba ulazna dostupnost, a hubu treba ime ili adresa koju lokacija može razriješiti. Taj jedan izbor uklanja većinu rasprave o statičkom javnom adresiranju prije nego što počne.
Tri uloge se zatim čisto razdvajaju, a tabela ispod je najkraći oblik odluke.
| 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 |
Svaki red ima drugog vlasnika i to je prava poanta. Hub pripada onome ko vodi VPN uslugu, peer lokacije mrežnom timu, a adresa senzora onome ko posjeduje uređaj.
Adresa huba je bootstrap, a ne odredište
Ime koje se razrješava na održavanu javnu adresu dovoljno je za hub. DNS zapis može slijediti krajnju točku kada se premjesti, bez ručnog uređivanja svake konfiguracije lokacije. Ono što DNS ne radi jest stvaranje dostupnosti ili osvježavanje klijenta koji kešira stari odgovor, a to su odvojeni problemi s odvojenim rješenjima.
Ako vodite tunel lokacija-lokacija bez huba, ista logika vrijedi u drugom obliku: jedna strana treba dostupnu krajnju točku ili obje strane pozivaju treću stranu. Neko i dalje mora posjedovati tu adresu i njena obnavljanja.
Peer lokacije je identitet s pridruženim prefiksom
Peer je prvo identitet, a drugo prefiks. U terminima WireGuarda peer drži par ključeva, a AllowedIPs zapis huba veže taj ključ na prefiks lokacije. U terminima IKEv2 certifikat ili unaprijed dijeljeni ključ identificira lokaciju, a njeni selektori prometa govore šta smije nositi. Promjena samo jedne polovine kvari raspored, zbog čega se promjena adrese nikada ne smije tretirati kao promjena identiteta.
Držite vlasništvo nad ključem ili certifikatom kod lokacije, a ne kod operatera huba, kako promjena provajdera ne bi postala promjena identiteta.
Prefiks je dio koji ljudi zaborave planirati. Hub mora povezati podmrežu senzora s pravim peerom, a operaterov klijent treba rutu do nje; ruta koja postoji samo na klijentu šalje promet u tunel koji ga tiho odbacuje. Upišite prefiks u zapis lokacije uz otisak ključa, kako zamjenski gateway ne bi neprimjetno nastupio s drukčijom pokrivenošću.
Adresa senzora pripada aplikaciji
Privatna adresa iz plana lokacije je dovoljna, a potrebna joj je stabilnost, a ne javna dostupnost: DHCP rezervacija, statička dodjela ili ime u vlastitoj zoni lokacije. Ako se uređaj ne može prenumerisati, prevođenje na gatewayu lokacije legitiman je odgovor sve dok je prevođenje dokumentirano i povratni promet ga slijedi.
Još jedna navika koju vrijedi zadržati: nikada ne lijepite javnu adresu huba u polje sljedećeg skoka na hostu senzora. VPN postavlja svoju stazu, a obična Ethernet susjednost s javnom krajnjom točkom fikcija je koja proizvodi uvjerljivo izgledajuću konfiguraciju.
Odgovori su polovina koja se preskače. Uređaj mora poslati svoj odgovor natrag prema tunelu, bilo rutom do operaterovog klijenta ili kroz isti gateway koji je preveo zahtjev. Senzor s pogrešnim zadanim gatewayom prihvaća zahtjev i odgovara u ništa, a napomene o prosljeđivanju objašnjavaju zašto su dolazak i rutiranje odgovora dva zahtjeva, a ne jedan.
Odlučite, pa zapišite granicu
Zapišite granicu pristupa prije nego se bilo ko poveže. Ograničite gateway na IoT segment i na konkretne usluge koje operater treba, jer radna ruta s vremenom slučajno postane opći pristup. Držite nadzor samo za čitanje i ovlast konfiguracije kao odvojene uloge s odvojenim identitetima i imenujte osobu koja uklanja pristup kada ugovor istekne.
Odobrenje pripada vlasniku mreže, a biti u DMZ-u nije politika pristupa.
Test nakon postavljanja je dosadan i konačan: jedan zahtjev unutar dopuštenog prefiksa koji uspije, brojač koji se poveća na gatewayu i jedan namjeran pokušaj izvan prefiksa koji ne uspije.