Trys adresai susipainioja kiekviename IoT per VPN plane, ir tai nėra to paties tipo sprendimas. Vienas yra tai, kaip nuotolinis operatorius randa tunelio galinį tašką, kitas – kaip vietovė įrodo, kad ji yra vietovė, o trečias – kur jutiklio paslauga iš tikrųjų klausosi. Atsakykite į juos ta tvarka ir dizainas daugiausia išeina savaime. Atsakykite kaip į vieną klausimą ir galiausiai priskirsite viešus adresus įrenginiams, kuriems jų niekada nereikėjo. Jutiklis už išeinančio vietovės tunelio pasiekiamas įgaliotam operatoriui be jokios įeinančios taisyklės, nukreiptos į jutiklį.

Pradėkite nuo to, kas inicijuoja

Kas skambina, lemia beveik viską toliau. Kai vietovė skambina mazgui, vietovei nereikia įeinančio pasiekiamumo, o mazgui reikia vardo ar adreso, kurį vietovė gali išspręsti. Šis vienas pasirinkimas pašalina didžiąją dalį ginčo dėl statinio viešo adresavimo, kol jis dar neprasidėjo.

Trys vaidmenys tada atsiskiria švariai, o žemiau esanti lentelė yra trumpiausia sprendimo forma.

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

Kiekviena eilutė turi skirtingą savininką, ir tai yra tikroji esmė. Mazgas priklauso tam, kas valdo VPN paslaugą, vietovės partneris – tinklo komandai, o jutiklio adresas – tam, kas turi įrenginį.

Mazgo adresas yra paleidimas, o ne paskirties vieta

Vardo, kuris išsprendžiamas į prižiūrimą viešą adresą, mazgui pakanka. DNS įrašas gali sekti galinį tašką, kai jis juda, nereikia rankiniu būdu redaguoti kiekvienos vietovės konfigūracijos. Ko DNS nedaro – nesukuria pasiekiamumo ir neatnaujina kliento, kuris kaupia seną atsakymą, ir tai atskiros problemos su atskirais sprendimais.

Jei valdote vietovių į vietovę tunelius be mazgo, ta pati logika galioja kitoje formoje: vienai pusei reikia pasiekiamo galinio taško, arba abi pusės skambina trečiajai šaliai. Kažkas vis tiek turi turėti tą adresą ir jo atnaujinimus.

Vietovės partneris yra tapatybė su prijungtu priešdėliu

Partneris pirmiausia yra tapatybė, o antra – priešdėlis. WireGuard terminais partneris laiko raktų porą, o mazgo AllowedIPs įrašas susieja tą raktą su vietovės priešdėliu. IKEv2 terminais sertifikatas arba iš anksto bendrinamas raktas identifikuoja vietovę, o jos srauto selektoriai sako, ką ji gali nešti. Pakeitus tik vieną pusę, susitarimas sugenda, todėl adreso pakeitimas niekada neturi būti laikomas tapatybės pakeitimu.

Laikykite rakto arba sertifikato nuosavybę vietovėje, o ne mazgo operatoriuje, kad tiekėjo pakeitimas netaptų tapatybės pakeitimu.

Priešdėlis yra ta dalis, kurią žmonės pamiršta suplanuoti. Mazgas turi susieti jutiklio potinklį su tinkamu partneriu, o operatoriaus klientui reikia maršruto į jį; maršrutas, egzistuojantis tik kliente, siunčia srautą į tunelį, kuris jį tyliai numeta. Įrašykite priešdėlį vietovės įraše šalia rakto piršto atspaudo, kad pakeistas tinklo šliuzas negalėtų nepastebimai iškilti su kitokia aprėptimi.

Jutiklio adresas priklauso programai

Privataus adreso iš vietovės plano pakanka, o jam reikia stabilumo, o ne viešo pasiekiamumo: DHCP rezervacijos, statinio priskyrimo arba vardo vietovės pačios zonoje. Jei įrenginio negalima pernumeruoti, vertimas vietovės šliuze yra teisėtas atsakymas, jei vertimas dokumentuotas ir grįžtamasis srautas juo vadovaujasi.

Dar vienas įprotis, kurį verta išlaikyti: niekada neįklijuokite viešo mazgo adreso į kito šuolio lauką jutiklio hoste. VPN įdiegia savo kelią, o įprastas Ethernet kaimyniškumas su viešu galiniu tašku yra fikcija, sukurianti įtikinamai atrodančią konfigūraciją.

Atsakymai yra ta pusė, kuri praleidžiama. Įrenginys turi siųsti savo atsakymą atgal link tunelio, arba maršrutu į operatoriaus klientą, arba per tą patį šliuzą, kuris išvertė užklausą. Jutiklis su netinkamu numatytuoju šliuzu priima užklausą ir atsako į nieką, o persiuntimo pastabos paaiškina, kodėl atvykimas ir atsakymo maršrutizavimas yra du reikalavimai, o ne vienas.

Nuspręskite, tada užrašykite ribą

Užrašykite prieigos ribą, kol niekas neprisijungė. Apribokite šliuzą IoT segmentui ir konkrečioms paslaugoms, kurių reikia operatoriui, nes veikiantis maršrutas linkęs netyčia tapti bendra prieiga. Laikykite tik skaitymo stebėjimą ir konfigūravimo įgaliojimus kaip atskirus vaidmenis su atskiromis tapatybėmis ir įvardykite asmenį, kuris pašalina prieigą pasibaigus sutarčiai.

Patvirtinimas priklauso tinklo savininkui, o buvimas DMZ nėra prieigos politika.

Bandymas po diegimo yra nuobodus ir lemiamas: viena užklausa leistiname priešdėlyje, kuri pavyksta, skaitiklis, kuris padidėja šliuze, ir vienas sąmoningas bandymas už priešdėlio ribų, kuris nepavyksta.

Susiję straipsniai