Tři rozhodnutí o adresách, než dáte IoT senzory za VPN
Tři adresy plní tři úlohy: veřejný hub, ověřený protějšek lokality a privátní adresa senzoru. Naplánujte každou, než cokoli veřejného přidělíte.
Tři adresy se v každém plánu IoT přes VPN zamotají a nejsou to stejná rozhodnutí. Jedna je, jak vzdálený operátor najde koncový bod tunelu, jedna je, jak lokalita prokáže, že je lokalitou, a jedna je, kde služba senzoru skutečně naslouchá. Odpovězte v tomto pořadí a návrh vám většinou vypadne sám. Odpovězte na ně jako na jedinou otázku a skončíte u přidělování veřejných adres zařízením, která je nikdy nepotřebovala. Senzor za odchozím tunelem lokality je dosažitelný oprávněným operátorem bez jediného příchozího pravidla namířeného na senzor.
Začněte tím, kdo iniciuje
Kdo vytáčí, určuje téměř vše další. Když lokalita vytáčí hub, lokalita nepotřebuje příchozí dosažitelnost a hub potřebuje jméno nebo adresu, kterou lokalita dokáže přeložit. Tato jediná volba odstraní většinu debaty o statickém veřejném adresování, než začne.
Tři role se pak čistě oddělí a tabulka níže je nejkratší formou rozhodnutí.
| 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ý řádek má jiného vlastníka, a to je ten skutečný bod. Hub patří tomu, kdo provozuje VPN službu, protějšek lokality síťovému týmu a adresa senzoru tomu, kdo vlastní zařízení.
Adresa hubu je bootstrap, ne cíl
Jméno, které se překládá na udržovanou veřejnou adresu, hubu stačí. DNS záznam může sledovat koncový bod, když se přesune, bez ruční úpravy každé konfigurace lokality. Co DNS nedělá, je vytváření dosažitelnosti nebo obnovení klienta, který kešuje starou odpověď, a to jsou oddělené problémy s oddělenými řešeními.
Pokud provozujete tunely lokalita-lokalita bez hubu, platí stejná logika v jiné podobě: jedna strana potřebuje dosažitelný koncový bod, nebo obě strany vytáčejí třetí stranu. Někdo tu adresu a její obnovy stále musí vlastnit.
Protějšek lokality je identita s připojeným prefixem
Protějšek je nejprve identita a teprve potom prefix. V termínech WireGuardu drží protějšek pár klíčů a záznam AllowedIPs hubu váže tento klíč na prefix lokality. V termínech IKEv2 identifikuje lokalitu certifikát nebo předem sdílený klíč a její selektory provozu říkají, co může nést. Změna jen jedné poloviny uspořádání rozbije, a proto se změna adresy nikdy nesmí brát jako změna identity.
Vlastnictví klíče nebo certifikátu držte u lokality, ne u operátora hubu, aby se změna poskytovatele nestala změnou identity.
Prefix je část, kterou lidé zapomenou naplánovat. Hub musí přidružit podsíť senzoru ke správnému protějšku a klientský program operátora k ní potřebuje trasu; trasa, která existuje jen na klientovi, posílá provoz do tunelu, který ho tiše zahodí. Zapište prefix do záznamu lokality vedle otisku klíče, aby se náhradní brána nemohla objevit s jiným pokrytím, aniž by si toho někdo všiml.
Adresa senzoru patří aplikaci
Privátní adresa z plánu lokality stačí a potřebuje stabilitu, ne veřejnou dosažitelnost: rezervaci DHCP, statické přidělení nebo jméno ve vlastní zóně lokality. Pokud zařízení nelze přečíslovat, překlad na bráně lokality je legitimní odpověď, dokud je překlad zdokumentovaný a zpětný provoz ho následuje.
Ještě jeden zvyk, který stojí za to udržet: nikdy nevkládejte veřejnou adresu hubu do pole dalšího skoku na hostiteli senzoru. VPN si instaluje vlastní cestu a běžné ethernetové sousedství s veřejným koncovým bodem je fikce, která vytváří přesvědčivě vypadající konfiguraci.
Odpovědi jsou ta polovina, která se přeskakuje. Zařízení musí poslat svou odpověď zpět směrem k tunelu, buď trasou ke klientovi operátora, nebo přes stejnou bránu, která požadavek přeložila. Senzor se špatnou výchozí bránou požadavek přijme a odpoví do prázdna, a poznámky k předávání vysvětlují, proč jsou příchod a směrování odpovědi dva požadavky, a ne jeden.
Rozhodněte a pak zapište hranici
Zapište hranici přístupu, než se kdokoli připojí. Omezte bránu na segment IoT a na konkrétní služby, které operátor potřebuje, protože funkční trasa má ve zvyku se náhodou stát obecným přístupem. Udržujte monitorování pouze pro čtení a oprávnění ke konfiguraci jako oddělené role s oddělenými identitami a jmenujte osobu, která přístup odebere, až smlouva skončí.
Schválení patří vlastníkovi sítě a být v DMZ není přístupová politika.
Test po nasazení je nudný a průkazný: jeden požadavek uvnitř povoleného prefixu, který uspěje, počítadlo, které na bráně vzroste, a jeden záměrný pokus mimo prefix, který selže.