Három címdöntés, mielőtt IoT-érzékelőket tesz egy VPN mögé
Három cím három feladatot lát el: a nyilvános hub, a hitelesített telephelyi peer és az érzékelő privát címe. Tervezze meg mindegyiket, mielőtt bármi nyilvánosat kiosztana.
Három cím gabalyodik össze minden IoT-VPN-tervben, és ezek nem ugyanolyan döntések. Az egyik az, hogyan találja meg a távoli üzemeltető az alagút végpontját, a másik az, hogyan bizonyítja a telephely, hogy ő a telephely, a harmadik pedig az, hogy hol figyel valójában az érzékelő szolgáltatása. Válaszoljon rájuk ebben a sorrendben, és a tervezés szinte magától kialakul. Válaszoljon rájuk egyetlen kérdésként, és oda jut, hogy nyilvános címeket oszt olyan eszközöknek, amelyeknek soha nem volt rájuk szükségük. Egy kimenő telephelyi alagút mögötti érzékelő elérhető egy jogosult üzemeltető számára anélkül, hogy bármilyen bejövő szabály az érzékelőre mutatna.
Kezdje azzal, ki kezdeményez
Hogy ki tárcsáz, szinte mindent meghatároz. Amikor a telephely egy hub felé tárcsáz, a telephelynek nincs szüksége bejövő elérhetőségre, a hubnak pedig olyan névre vagy címre van szüksége, amelyet a telephely fel tud oldani. Ez az egyetlen választás a statikus nyilvános címzés vitájának nagy részét még a kezdet előtt megszünteti.
A három szerep aztán tisztán elválik, és az alábbi táblázat a döntés legrövidebb formája.
| 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 |
Minden sor más tulajdonosé, és ez a lényeg. A hub azé, aki a VPN-szolgáltatást üzemelteti, a telephelyi peer a hálózati csapaté, az érzékelő címe pedig azé, aki az eszközt birtokolja.
A hub címe indítás, nem cél
Egy fenntartott nyilvános címre feloldódó név elegendő a hubnak. A DNS-rekord követheti a végpontot, amikor az átkerül, anélkül hogy minden telephelyi konfigurációt kézzel kellene szerkeszteni. Amit a DNS nem tesz meg, az az elérhetőség létrehozása vagy egy régi választ gyorsítótárazó kliens frissítése, és ezek külön problémák külön megoldásokkal.
Ha hub nélküli telephely-telephely alagutakat üzemeltet, ugyanez a logika más formában érvényes: az egyik oldalnak elérhető végpontra van szüksége, vagy mindkét oldal egy harmadik felet tárcsáz. Valakinek továbbra is birtokolnia kell azt a címet és annak megújításait.
A telephelyi peer identitás, amelyhez prefix kapcsolódik
A peer először identitás, másodszor prefix. WireGuard-értelemben a peer kulcspárt tart, és a hub AllowedIPs bejegyzése ehhez a kulcshoz köti a telephely prefixét. IKEv2-értelemben egy tanúsítvány vagy előre megosztott kulcs azonosítja a telephelyet, forgalomválasztói pedig megmondják, mit szállíthat. Ha csak az egyik felét változtatja meg, a rendszer felborul, ezért a címváltozást soha nem szabad identitásváltozásként kezelni.
A kulcs vagy tanúsítvány tulajdonjogát a telephelynél tartsa, ne a hub üzemeltetőjénél, hogy a szolgáltatóváltás ne váljon identitásváltássá.
A prefix az a rész, amelynek tervezéséről az emberek megfeledkeznek. A hubnak az érzékelő alhálózatát a megfelelő peerhez kell rendelnie, és az üzemeltető kliensének útvonalra van szüksége hozzá; egy csak a kliensen létező útvonal olyan alagútba küldi a forgalmat, amely csendben eldobja. Írja be a prefixet a telephely rekordjába a kulcs ujjlenyomata mellé, hogy egy csereátjáró ne jelenhessen meg észrevétlenül más lefedettséggel.
Az érzékelő címe az alkalmazásé
A telephely tervéből származó privát cím elegendő, és amire szüksége van, az a stabilitás, nem a nyilvános elérhetőség: DHCP-foglalás, statikus kiosztás vagy név a telephely saját zónájában. Ha az eszköz nem számozható át, az átjárón végzett átírás jogos válasz, feltéve hogy az átírás dokumentált, és a visszirányú forgalom követi.
Még egy szokás, amelyet érdemes megtartani: soha ne illessze be a hub nyilvános címét az érzékelő gazdagépének következő ugrás mezőjébe. A VPN a saját útvonalát telepíti, és egy nyilvános végpont felé mutató közönséges Ethernet-szomszédság olyan fikció, amely meggyőzően kinéző konfigurációt eredményez.
A válaszok az a fél, amelyet kihagynak. Az eszköznek vissza kell küldenie a válaszát az alagút felé, vagy az üzemeltető kliense felé vezető útvonalon, vagy ugyanazon az átjárón keresztül, amely a kérést átírta. A rossz alapértelmezett átjáróval rendelkező érzékelő elfogadja a kérést és a semmibe válaszol, és a továbbítási megjegyzések elmagyarázzák, miért két követelmény az érkezés és a válasz útvonalválasztása, nem egy.
Döntsön, majd írja le a határt
Írja le a hozzáférési határt, mielőtt bárki csatlakozna. Korlátozza az átjárót az IoT-szegmensre és azokra a konkrét szolgáltatásokra, amelyekre az üzemeltetőnek szüksége van, mert egy működő útvonal hajlamos véletlenül általános hozzáféréssé válni. A csak olvasható megfigyelést és a konfigurációs jogosultságot tartsa külön szerepkörökként külön identitásokkal, és nevezze meg azt a személyt, aki a szerződés lejártakor eltávolítja a hozzáférést.
A jóváhagyás a hálózat tulajdonosáé, és a DMZ-ben lenni nem hozzáférési szabályzat.
Az üzembe helyezés utáni teszt unalmas és döntő: egy kérés az engedélyezett prefixen belül, amely sikerül, egy számláló, amely nő az átjárón, és egy szándékos kísérlet a prefixen kívül, amely meghiúsul.