Trīs adreses lēmumi pirms IoT sensoru ievietošanas aiz VPN
Trīs adreses pilda trīs uzdevumus: publiskais mezgls, autentificētais vietas partneris un sensora privātā adrese. Izplānojiet katru pirms kaut ko publisku piešķirt.
Trīs adreses sapinās katrā IoT pār VPN plānā, un tās nav viena veida lēmums. Viena ir, kā attālināts operators atrod tuneļa galapunktu, otra ir, kā vieta pierāda, ka tā ir vieta, un trešā ir, kur sensora pakalpojums patiešām klausās. Atbildiet uz tām šajā secībā, un dizains lielākoties iznāk pats. Atbildiet kā uz vienu jautājumu, un jūs nonāksit pie publisku adrešu piešķiršanas ierīcēm, kurām tās nekad nebija vajadzīgas. Sensors aiz izejošā vietas tuneļa ir sasniedzams pilnvarotam operatoram bez neviena ienākoša noteikuma, kas norādītu uz sensoru.
Sāciet ar to, kas uzsāk
Kas zvana, nosaka gandrīz visu turpmāko. Kad vieta zvana uz mezglu, vietai nav vajadzīga ienākoša sasniedzamība, un mezglam vajag vārdu vai adresi, ko vieta var atrisināt. Šī vienīgā izvēle novērš lielāko daļu statiskās publiskās adresācijas strīda, pirms tas sākas.
Trīs lomas tad skaidri atdalās, un tabula zemāk ir īsākā lēmuma forma.
| 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 |
Katrai rindai ir cits īpašnieks, un tas ir īstais jēga. Mezgls pieder tam, kas uztur VPN pakalpojumu, vietas partneris tīkla komandai, un sensora adrese tam, kam pieder ierīce.
Mezgla adrese ir sāknēšana, nevis galamērķis
Vārds, kas atrisinās uz uzturētu publisku adresi, mezglam ir pietiekams. DNS ieraksts var sekot galapunktam, kad tas pārvietojas, bez katras vietas konfigurācijas manuālas rediģēšanas. Ko DNS nedara, ir sasniedzamības radīšana vai klienta atsvaidzināšana, kas kešo veco atbildi, un tās ir atsevišķas problēmas ar atsevišķiem risinājumiem.
Ja uzturat vietas-uz-vietu tuneļus bez mezgla, tā pati loģika darbojas citā formā: vienai pusei vajag sasniedzamu galapunktu, vai arī abas puses zvana trešajai pusei. Kādam tomēr jāpieder šai adresei un tās atjaunojumiem.
Vietas partneris ir identitāte ar pievienotu prefiksu
Partneris vispirms ir identitāte un otrkārt prefikss. WireGuard izteiksmē partneris tur atslēgu pāri, un mezgla AllowedIPs ieraksts saista šo atslēgu ar vietas prefiksu. IKEv2 izteiksmē sertifikāts vai iepriekš kopīgota atslēga identificē vietu, un tās trafika selektori saka, ko tā drīkst pārnēsāt. Mainot tikai vienu pusi, vienošanās sabrūk, tāpēc adreses maiņa nekad nav jāuzskata par identitātes maiņu.
Turiet atslēgas vai sertifikāta īpašumtiesības vietā, nevis mezgla operatorā, lai pakalpojumu sniedzēja maiņa nekļūtu par identitātes maiņu.
Prefikss ir tā daļa, ko cilvēki aizmirst izplānot. Mezglam jāsaista sensora apakštīkls ar pareizo partneri, un operatora klientam vajag maršrutu uz to; maršruts, kas pastāv tikai klientā, sūta trafiku tunelī, kas to klusi izmet. Ierakstiet prefiksu vietas ierakstā blakus atslēgas nospiedumam, lai nomainītais vārteja nevarētu nepamanīti parādīties ar citu pārklājumu.
Sensora adrese pieder lietojumprogrammai
Privāta adrese no vietas plāna ir pietiekama, un tai vajag stabilitāti, nevis publisku sasniedzamību: DHCP rezervāciju, statisku piešķiršanu vai vārdu pašas vietas zonā. Ja ierīci nevar pārnumurēt, tulkošana vietas vārtejā ir leģitīma atbilde, ja tulkošana ir dokumentēta un atgriezeniskais trafiks tai seko.
Vēl viens ieradums, ko vērts saglabāt: nekad neielīmējiet publisko mezgla adresi nākamā lēciena laukā sensora resursdatorā. VPN uzstāda savu ceļu, un parasta Ethernet kaimiņattiecība ar publisku galapunktu ir fikcija, kas rada pārliecinoši izskatāmu konfigurāciju.
Atbildes ir tā puse, kas tiek izlaista. Ierīcei sava atbilde jāsūta atpakaļ uz tuneli, vai nu pa maršrutu uz operatora klientu, vai caur to pašu vārteju, kas tulkoja pieprasījumu. Sensors ar nepareizu noklusējuma vārteju pieņem pieprasījumu un atbild nekurienē, un pārsūtīšanas piezīmes izskaidro, kāpēc ierašanās un atbildes maršrutēšana ir divas prasības, nevis viena.
Izlemiet, tad pierakstiet robežu
Pierakstiet piekļuves robežu, pirms kāds piesakās. Ierobežojiet vārteju ar IoT segmentu un konkrētajiem pakalpojumiem, kas operatoram vajadzīgi, jo strādājošs maršruts mēdz nejauši kļūt par vispārēju piekļuvi. Turiet tikai lasīšanas uzraudzību un konfigurācijas pilnvaras kā atsevišķas lomas ar atsevišķām identitātēm un nosauciet personu, kas noņem piekļuvi, kad līgums beidzas.
Apstiprinājums pieder tīkla īpašniekam, un atrašanās DMZ nav piekļuves politika.
Pārbaude pēc ieviešanas ir garlaicīga un izšķiroša: viens pieprasījums atļautajā prefiksā, kas izdodas, skaitītājs, kas palielinās vārtejā, un viens tīšs mēģinājums ārpus prefiksa, kas neizdodas.