Tri se adrese 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 mjesto dokazuje da jest mjesto, 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šit ćete tako da dodjeljujete javne adrese uređajima kojima nikada nije bila potrebna. Senzor iza odlaznog tunela mjesta dostupan je ovlaštenom operateru bez ijednog ulaznog pravila usmjerenog na senzor.

Počnite s tim tko inicira

Tko poziva određuje gotovo sve dalje. Kada mjesto poziva čvorište, mjestu ne treba ulazna dostupnost, a čvorištu treba ime ili adresa koju mjesto može razriješiti. Taj jedan izbor uklanja većinu rasprave o statičkom javnom adresiranju prije nego što počne.

Tri se uloge zatim čisto razdvajaju, a tablica ispod najkraći je oblik odluke.

DecisionWhat you are actually choosingUsual default
Hub endpointHow the tunnel service is publishedA DNS name, no inbound rule toward the site
Site peerHow the site proves its identity and which prefixes it carriesOne key pair or certificate per site, prefix in the tunnel config
Sensor serviceHow the application is addressed inside the siteA stable private address from the site plan

Svaki redak ima drugog vlasnika i to je prava poanta. Čvorište pripada onome tko vodi VPN uslugu, par mjesta mrežnom timu, a adresa senzora onome tko posjeduje uređaj.

Adresa čvorišta je bootstrap, a ne odredište

Ime koje se razrješava na održavanu javnu adresu dovoljno je za čvorište. DNS zapis može slijediti krajnju točku kada se premjesti, bez ručnog uređivanja svake konfiguracije mjesta. Ono što DNS ne čini jest stvaranje dostupnosti ili osvježavanje klijenta koji kešira stari odgovor, a to su odvojeni problemi s odvojenim rješenjima.

Ako vodite tunel mjesto-mjesto bez čvorišta, ista logika vrijedi u drugom obliku: jedna strana treba dostupnu krajnju točku ili obje strane pozivaju treću stranu. Netko i dalje mora posjedovati tu adresu i njezina obnavljanja.

Par mjesta je identitet s pridruženim prefiksom

Par je prvo identitet, a drugo prefiks. U terminima WireGuarda par drži par ključeva, a AllowedIPs zapis čvorišta veže taj ključ na prefiks mjesta. U terminima IKEv2 certifikat ili unaprijed dijeljeni ključ identificira mjesto, a njegovi selektori prometa govore što smije nositi. Promjena samo jedne polovice kvari raspored, zbog čega se promjena adrese nikada ne smije tretirati kao promjena identiteta.

Držite vlasništvo nad ključem ili certifikatom kod mjesta, a ne kod operatera čvorišta, kako promjena pružatelja ne bi postala promjena identiteta.

Prefiks je dio koji ljudi zaborave planirati. Čvorište mora povezati podmrežu senzora s pravim parom, 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 mjesta uz otisak ključa, kako zamjenski gateway ne bi neprimjetno nastupio s drukčijom pokrivenošću.

Adresa senzora pripada aplikaciji

Privatna adresa iz plana mjesta dovoljna je, a potrebna joj je stabilnost, a ne javna dostupnost: DHCP rezervacija, statička dodjela ili ime u vlastitoj zoni mjesta. Ako se uređaj ne može prenumerirati, prevođenje na gatewayu mjesta 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 čvorišta 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 polovica 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 tko 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.

Povezani članci