Trije adresbeslutten foardat jo IoT-sensoren efter in VPN sette
Trije adressen dogge trije taken: de iepenbiere hub, de autentisearre side-pear en it privee-adres fan de sensor. Plan elts foardat jo eat iepenbier tawize.
Trije adressen reitsje trochinoar yn elk IoT-oer-VPN-plan, en se binne net deselde soarte beslissing. Ien is hoe't in ôfstâne operator it tunnel-einpunt fynt, ien is hoe't de side bewiist dat it de side is, en ien is wêr't de tsjinst fan de sensor eins harket. Beäntwurdzje se yn dy oarder en it ûntwerp falt meast fan sels út. Beäntwurdzje se as ien fraach en jo einigje mei iepenbiere adressen ta te wizen oan apparaten dy't der nea ien nedich hiene. In sensor efter in útgeande side-tunnel is berikber foar in autorisearre operator sûnder ien ynkommende regel dy't nei de sensor wiist.
Begjin mei wa't inisjearret
Wa't skillet bepaalt hast alles wat folget. As de side nei in hub skillet, hat de side gjin ynkommende berikberens nedich, en de hub hat in namme of adres nedich dat de side oplosse kin. Dy iene kar hellet it measte fan it debat oer statyske iepenbiere adressaasje fuort foardat it begjint.
De trije rollen skiede har dan skjin, en de tabel hjirûnder is de koartste foarm fan 'e beslissing.
| 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 |
Elke rige hat in oare eigner, en dat is it echte punt. De hub heart by wa't de VPN-tsjinst rint, it side-pear by it netwurkteam, en it adres fan de sensor by wa't it apparaat hat.
It hub-adres is opstart, net in bestimming
In namme dy't nei in ûnderholden iepenbier adres oplost, is genôch foar de hub. In DNS-record kin it einpunt folgje as it ferpleatst, sûnder elke side-konfiguraasje mei de hân te bewurkjen. Wat DNS net docht, is berikberens meitsje of in kliïnt ferfarskje dy't it âlde antwurd yn 't ûnthâld hat, en dat binne aparte problemen mei aparte oplossings.
As jo side-oant-side-tunnels sûnder hub driuwe, jildt deselde logika yn in oare foarm: ien kant hat in berikber einpunt nedich, of beide kanten skilje in tredde partij. Immen moat dat adres en de fernijïngen dêrfan noch altyd hawwe.
It side-pear is in identiteit mei in foarheaksel deroan
It pear is earst in identiteit en twadde in foarheaksel. Yn WireGuard-termen hâldt it pear in kaaipaar en de AllowedIPs-ynskriuwing fan 'e hub bynt dat kaaike oan it foarheaksel fan 'e side. Yn IKEv2-termen identifisearret in sertifikaat of foarôf dield kaaike de side, en syn ferkearsselektors sizze wat it drage mei. It feroarjen fan mar ien helte brekt de regeling, en dêrom mei in adresferoaring nea as in identiteitsferoaring behannele wurde.
Hâld it eigendom fan it kaaike of sertifikaat by de side ynstee fan by de hub-operator, sadat in feroaring fan provider gjin feroaring fan identiteit wurdt.
It foarheaksel is it part dat minsken ferjitte te plannen. De hub moat it sensor-subnet oan it juste pear keppelje, en de kliïnt fan 'e operator hat in rûte dêrfoar nedich; in rûte dy't allinnich op 'e kliïnt bestiet, stjoert ferkear in tunnel yn dy't it stilwei falle lit. Skriuw it foarheaksel yn 'e side-record njonken de kaaifingerprint, sadat in ferfongen gateway net ûnfernomen mei oare dekking opkomme kin.
It sensoradres heart by de applikaasje
In privee-adres út it plan fan 'e side is genôch, en wat it nedich hat is stabiliteit ynstee fan iepenbiere berikberens: in DHCP-reservearring, in statyske tawizing, of in namme yn 'e eigen sône fan 'e side. As it apparaat net ommeroepe wurde kin, is oersetting op 'e gateway fan 'e side in jildich antwurd salang't de oersetting dokumintearre is en it weromferkear it folget.
Noch in gewoante dy't de muoite wurdich is om te hâlden: plak nea it iepenbiere hub-adres yn in folgjende-hop-fjild op 'e host fan 'e sensor. De VPN set syn eigen paad, en in gewoane Ethernet-buorskip oan in iepenbier einpunt is in fiksje dy't oertsjûgjende konfiguraasje opsmyt.
Antwurden binne de helte dy't oerslein wurdt. It apparaat moat syn antwurd werom nei de tunnel stjoere, itsij fia in rûte nei de kliïnt fan 'e operator, itsij fia deselde gateway dy't it fersyk oerset hat. In sensor mei de ferkearde standertgateway akseptearret it fersyk en antwurdet yn 't neat, en de notysjes oer trochstjoeren ferklearje wêrom't oankomst en antwurd-routing twa easken binne en net ien.
Beslis, en skriuw dan de grins
Skriuw de tagongsgrins del foardat immen ferbynt. Behein de gateway ta it IoT-segment en ta de spesifike tsjinsten dy't de operator nedich hat, want in wurkjende rûte wurdt by ûngelok maklik algemiene tagong. Hâld monitoring allinnich-lêze en konfiguraasje-befoechdheid as aparte rollen mei aparte identiteiten, en neam de persoan dy't tagong fuorthellet as it kontrakt einiget.
Goedkarring heart by de netwurkeigner, en yn in DMZ stean is gjin tagongsbelied.
De test nei útrulling is saai en beslissend: ien fersyk binnen it tastiene foarheaksel dat slagget, in teller dy't op 'e gateway omheech giet, en ien bewuste poging bûten it foarheaksel dy't mislearret.