Tri rozhodnutia o adresách, než dáte IoT senzory za VPN
Tri adresy plnia tri úlohy: verejný hub, overený partner lokality a privátna adresa senzora. Naplánujte každú, kým čokoľvek verejné pridelíte.
Tri adresy sa v každom pláne IoT cez VPN zamotajú a nie sú to rovnaké rozhodnutia. Jedna je, ako vzdialený operátor nájde koncový bod tunela, jedna je, ako lokalita preukáže, že je lokalitou, a jedna je, kde služba senzora skutočne počúva. Odpovedzte v tomto poradí a návrh vám väčšinou vypadne sám. Odpovedzte na ne ako na jedinú otázku a skončíte pri prideľovaní verejných adries zariadeniam, ktoré ich nikdy nepotrebovali. Senzor za odchádzajúcim tunelom lokality je dosiahnuteľný oprávneným operátorom bez jediného prichádzajúceho pravidla namiereného na senzor.
Začnite tým, kto iniciuje
Kto vytáča, určuje takmer všetko ďalšie. Keď lokalita vytáča hub, lokalita nepotrebuje prichádzajúcu dosiahnuteľnosť a hub potrebuje meno alebo adresu, ktorú lokalita dokáže preložiť. Táto jediná voľba odstráni väčšinu debaty o statickom verejnom adresovaní, skôr než sa začne.
Tri roly sa potom čisto oddelia a tabuľka nižšie je najkratšou formou rozhodnutia.
| 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 |
Každý riadok má iného vlastníka, a to je ten skutočný bod. Hub patrí tomu, kto prevádzkuje VPN službu, partner lokality sieťovému tímu a adresa senzora tomu, kto vlastní zariadenie.
Adresa hubu je bootstrap, nie cieľ
Meno, ktoré sa prekladá na udržiavanú verejnú adresu, hubu stačí. DNS záznam môže sledovať koncový bod, keď sa presunie, bez ručnej úpravy každej konfigurácie lokality. Čo DNS nerobí, je vytváranie dosiahnuteľnosti alebo obnovenie klienta, ktorý kešuje starú odpoveď, a to sú oddelené problémy s oddelenými riešeniami.
Ak prevádzkujete tunely lokalita-lokalita bez hubu, platí rovnaká logika v inej podobe: jedna strana potrebuje dosiahnuteľný koncový bod alebo obe strany vytáčajú tretiu stranu. Niekto tú adresu a jej obnovy stále musí vlastniť.
Partner lokality je identita s pripojeným prefixom
Partner je najprv identita a až potom prefix. V termínoch WireGuardu drží partner pár kľúčov a záznam AllowedIPs hubu viaže tento kľúč na prefix lokality. V termínoch IKEv2 identifikuje lokalitu certifikát alebo vopred zdieľaný kľúč a jej selektory prevádzky hovoria, čo môže niesť. Zmena len jednej polovice usporiadanie rozbije, a preto sa zmena adresy nikdy nesmie brať ako zmena identity.
Vlastníctvo kľúča alebo certifikátu držte pri lokalite, nie pri operátorovi hubu, aby sa zmena poskytovateľa nestala zmenou identity.
Prefix je časť, ktorú ľudia zabudnú naplánovať. Hub musí priradiť podsieti senzora správneho partnera a klientský program operátora k nej potrebuje trasu; trasa, ktorá existuje len na klientovi, posiela prevádzku do tunela, ktorý ju ticho zahodí. Zapíšte prefix do záznamu lokality vedľa odtlačku kľúča, aby sa náhradná brána nemohla objaviť s iným pokrytím, bez toho aby si to niekto všimol.
Adresa senzora patrí aplikácii
Privátna adresa z plánu lokality stačí a potrebuje stabilitu, nie verejnú dosiahnuteľnosť: rezerváciu DHCP, statické pridelenie alebo meno vo vlastnej zóne lokality. Ak zariadenie nemožno prečíslovať, preklad na bráne lokality je legitímna odpoveď, pokiaľ je preklad zdokumentovaný a spätná prevádzka ho nasleduje.
Ešte jeden zvyk, ktorý sa oplatí udržať: nikdy nevkladajte verejnú adresu hubu do poľa ďalšieho skoku na hostiteľovi senzora. VPN si inštaluje vlastnú cestu a bežné ethernetové susedstvo s verejným koncovým bodom je fikcia, ktorá vytvára presvedčivo vyzerajúcu konfiguráciu.
Odpovede sú tá polovica, ktorá sa preskakuje. Zariadenie musí poslať svoju odpoveď späť smerom k tunelu, buď trasou ku klientovi operátora, alebo cez tú istú bránu, ktorá požiadavku preložila. Senzor s nesprávnou predvolenou bránou požiadavku prijme a odpovie do prázdna, a poznámky k prepájaniu vysvetľujú, prečo sú príchod a smerovanie odpovede dve požiadavky, a nie jedna.
Rozhodnite a potom zapíšte hranicu
Zapíšte hranicu prístupu, než sa ktokoľvek pripojí. Obmedzte bránu na segment IoT a na konkrétne služby, ktoré operátor potrebuje, pretože funkčná trasa má vo zvyku sa náhodou stať všeobecným prístupom. Udržujte monitorovanie len na čítanie a konfiguračnú právomoc ako oddelené roly s oddelenými identitami a vymenujte osobu, ktorá prístup odoberie, keď sa zmluva skončí.
Schválenie patrí vlastníkovi siete a byť v DMZ nie je prístupová politika.
Test po nasadení je nudný a priebojný: jedna požiadavka vnútri povoleného prefixu, ktorá uspeje, počítadlo, ktoré na bráne vzrastie, a jeden úmyselný pokus mimo prefixu, ktorý zlyhá.