Tre vendime adresash përpara se të vendosni sensorë IoT pas një VPN
Tre adresa kryejnë tre detyra: hub-i publik, partneri i faqes i vërtetuar dhe adresa private e sensorit. Planifikoni secilën përpara se të ndani diçka publike.
Tre adresa ndërlidhen në çdo plan IoT mbi VPN, dhe nuk janë i njëjti lloj vendimi. Njëra është si një operator në distancë gjen pikën fundore të tunelit, tjetra është si faqja provon se është faqja, dhe tjetra është ku shërbimi i sensorit dëgjon vërtet. Përgjigjuni në atë rend dhe dizajni kryesisht del vetë. Përgjigjuni si një pyetje e vetme dhe do të përfundoni duke caktuar adresa publike pajisjeve që nuk kishin nevojë kurrë për një të tillë. Një sensor pas një tuneli dalës të faqes është i arritshëm nga një operator i autorizuar pa asnjë rregull hyrës që tregon drejt sensorit.
Filloni me atë se kush nis
Kush merr lidhjen përcakton pothuajse gjithçka më pas. Kur faqja merr lidhje me një hub, faqja nuk ka nevojë për arritshmëri hyrëse, dhe hub-i ka nevojë për një emër ose adresë që faqja mund ta zgjidhë. Ky zgjedhje e vetme heq pjesën më të madhe të debatit për adresimin publik statik përpara se ai të fillojë.
Tre rolet pastaj ndahen pastër, dhe tabela më poshtë është forma më e shkurtër e vendimit.
| 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 |
Çdo rresht ka një pronar tjetër, dhe kjo është pika e vërtetë. Hub-i i përket atij që drejton shërbimin VPN, partneri i faqes ekipit të rrjetit, dhe adresa e sensorit atij që zotëron pajisjen.
Adresa e hub-it është nisje, jo destinacion
Një emër që zgjidhet në një adresë publike të mirëmbajtur mjafton për hub-in. Një regjistrim DNS mund të ndjekë pikën fundore kur ajo zhvendoset, pa redaktuar me dorë çdo konfigurim faqeje. Ajo që DNS nuk bën është të krijojë arritshmëri ose të rifreskojë një klient që ruan përgjigjen e vjetër, dhe këto janë probleme të ndara me zgjidhje të ndara.
Nëse drejtoni tunele faqe-në-faqe pa hub, e njëjta logjikë vlen në një formë tjetër: njëra anë ka nevojë për një pikë fundore të arritshme, ose të dyja anët marrin lidhje me një palë të tretë. Dikush duhet të zotërojë ende atë adresë dhe rinovimet e saj.
Partneri i faqes është identitet me një prefiks të bashkangjitur
Partneri është së pari identitet dhe së dyti prefiks. Në termat e WireGuard partneri mban një çift çelësash dhe regjistrimi AllowedIPs i hub-it e lidh atë çelës me prefiksin e faqes. Në termat e IKEv2 një certifikatë ose çelës i ndarë paraprakisht identifikon faqen dhe përzgjedhësit e saj të trafikut thonë çfarë mund të mbajë. Ndryshimi i vetëm njërës gjysmë prish rregullimin, prandaj një ndryshim adrese nuk duhet të trajtohet kurrë si ndryshim identiteti.
Mbajeni pronësinë e çelësit ose certifikatës te faqja dhe jo te operatori i hub-it, që një ndryshim ofruesi të mos bëhet ndryshim identiteti.
Prefiksi është pjesa që njerëzit harrojnë ta planifikojnë. Hub-i duhet të lidhë nënrrjetin e sensorit me partnerin e duhur, dhe klienti i operatorit ka nevojë për një rrugë drejt tij; një rrugë që ekziston vetëm te klienti e dërgon trafikun në një tunel që e hedh në heshtje. Shkruani prefiksin në regjistrimin e faqes pranë gjurmës së gishtit të çelësit, që një portë zëvendësuese të mos shfaqet me mbulim tjetër pa u vënë re.
Adresa e sensorit i përket aplikacionit
Një adresë private nga plani i faqes mjafton, dhe ajo që i nevojitet është qëndrueshmëria dhe jo arritshmëria publike: një rezervim DHCP, një caktim statik ose një emër në zonën e vetë faqes. Nëse pajisja nuk mund të rinumërohet, përkthimi në portën e faqes është përgjigje legjitime për sa kohë përkthimi është dokumentuar dhe trafiku i kthimit e ndjek.
Një zakon tjetër që ia vlen të mbahet: mos e ngjitni kurrë adresën publike të hub-it në një fushë të hapit tjetër në hostin e sensorit. VPN-ja instalon rrugën e vet, dhe një fqinjësi Ethernet e zakonshme me një pikë fundore publike është një trillim që prodhon konfigurim me pamje bindëse.
Përgjigjet janë gjysma që anashkalohet. Pajisja duhet ta dërgojë përgjigjen e vet përsëri drejt tunelit, ose përmes një rruge drejt klientit të operatorit ose përmes të njëjtës portë që përktheu kërkesën. Një sensor me portë standarde të gabuar e pranon kërkesën dhe përgjigjet në hiç, dhe shënimet për përcjelljen shpjegojnë përse mbërritja dhe rrugëtimi i përgjigjes janë dy kërkesa e jo një.
Vendosni, pastaj shkruani kufirin
Shkruani kufirin e aksesit përpara se dikush të lidhet. Kufizoni portën te segmenti IoT dhe te shërbimet specifike që i nevojiten operatorit, sepse një rrugë që funksionon priret të bëhet akses i përgjithshëm aksidentalisht. Mbajeni monitorimin vetëm-lexim dhe autoritetin e konfigurimit si role të ndara me identitete të ndara, dhe emërtoni personin që heq aksesin kur mbaron kontrata.
Miratimi i përket pronarit të rrjetit, dhe të jesh në një DMZ nuk është politikë aksesi.
Testi pas vendosjes është i mërzitshëm dhe përcaktues: një kërkesë brenda prefiksit të lejuar që ka sukses, një numërues që rritet në portë, dhe një përpjekje e qëllimshme jashtë prefiksit që dështon.