Tatlong desisyon sa address bago ilagay ang mga IoT sensor sa likod ng VPN
Tatlong address ang may tatlong tungkulin: ang pampublikong hub, ang awtentikadong kapares ng site at ang pribadong address ng sensor. Planuhin ang bawat isa bago maglaan ng anumang pampubliko.
Tatlong address ang nagsasapawan sa bawat planong IoT sa VPN, at hindi sila ang parehong uri ng desisyon. Ang isa ay kung paano hinahanap ng malayong operator ang dulo ng tunnel, ang isa ay kung paano pinatutunayan ng site na ito ang site, at ang isa ay kung saan talaga nakikinig ang serbisyo ng sensor. Sagutin ang mga ito sa ganoong pagkakasunod-sunod at halos kusang lumalabas ang disenyo. Sagutin ang mga ito bilang isang tanong at mapupunta ka sa pagbibigay ng pampublikong address sa mga device na hindi kailanman nangailangan nito. Ang sensor sa likod ng palabas na tunnel ng site ay naaabot ng awtorisadong operator nang walang anumang papasok na patakaran na nakaturo sa sensor.
Magsimula sa kung sino ang nagsisimula
Kung sino ang tumatawag ang nagtatakda ng halos lahat ng sumusunod. Kapag tumatawag ang site sa isang hub, hindi kailangan ng site ang papasok na maabot, at kailangan ng hub ang pangalan o address na kayang lutasin ng site. Ang isang pagpiling iyon ay nag-aalis ng malaking bahagi ng debate sa static na pampublikong addressing bago pa ito magsimula.
Pagkatapos ay malinaw na naghihiwalay ang tatlong tungkulin, at ang talahanayan sa ibaba ang pinakamaikling anyo ng desisyon.
| 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 |
Bawat hilera ay may ibang may-ari, at iyon ang tunay na punto. Ang hub ay pag-aari ng nagpapatakbo ng serbisyong VPN, ang kapares ng site ng koponan ng network, at ang address ng sensor ng nagmamay-ari ng device.
Ang address ng hub ay bootstrap, hindi destinasyon
Ang pangalang lumulutas sa isang pinapanatiling pampublikong address ay sapat na para sa hub. Maaaring sundan ng rekord ng DNS ang dulo kapag gumalaw ito, nang hindi kinakailangang i-edit nang manu-mano ang bawat konfigurasyon ng site. Ang hindi ginagawa ng DNS ay lumikha ng maabot o mag-refresh ng kliyenteng nag-cache ng lumang sagot, at magkaibang problema ang mga iyon na may magkaibang solusyon.
Kung nagpapatakbo ka ng site-to-site na tunnel nang walang hub, ganoon pa rin ang lohika sa ibang anyo: kailangan ng isang panig ng maabot na dulo, o tumatawag ang dalawang panig sa ikatlong partido. May kailangan pa ring magmay-ari ng address na iyon at ng mga pag-renew nito.
Ang kapares ng site ay pagkakakilanlan na may nakakabit na prefix
Ang kapares ay pagkakakilanlan muna at prefix pagkatapos. Sa mga termino ng WireGuard, may hawak ang kapares ng pares ng susi at ang entry na AllowedIPs ng hub ay nagbibigkis sa susi na iyon sa prefix ng site. Sa mga termino ng IKEv2, tinutukoy ng sertipiko o paunang ibinahaging susi ang site at sinasabi ng mga tagapili ng trapiko nito kung ano ang maaari nitong dalhin. Ang pagbabago ng isang kalahati lamang ay sumisira sa kaayusan, kaya ang pagbabago ng address ay hindi kailanman dapat ituring na pagbabago ng pagkakakilanlan.
Panatilihin ang pagmamay-ari ng susi o sertipiko sa site at hindi sa operator ng hub, upang ang pagpapalit ng provider ay hindi maging pagpapalit ng pagkakakilanlan.
Ang prefix ay ang bahaging nakakalimutang planuhin. Kailangang iugnay ng hub ang subnet ng sensor sa tamang kapares, at kailangan ng kliyente ng operator ng ruta patungo roon; ang rutang nasa kliyente lamang ay nagpapadala ng trapiko sa tunnel na tahimik na nagtatapon nito. Isulat ang prefix sa rekord ng site sa tabi ng fingerprint ng susi, upang ang kapalit na gateway ay hindi lumitaw na may ibang saklaw nang walang nakakapansin.
Ang address ng sensor ay pag-aari ng aplikasyon
Sapat na ang pribadong address mula sa plano ng site, at ang kailangan nito ay katatagan at hindi pampublikong maabot: reserbasyon ng DHCP, static na paglalaan, o pangalan sa sariling sona ng site. Kung hindi muling mabibigyan ng numero ang device, ang pagsasalin sa gateway ng site ay lehitimong sagot hangga't ang pagsasalin ay nakadokumento at sinusundan ito ng trapikong pabalik.
Isa pang ugali na dapat panatilihin: huwag kailanman idikit ang pampublikong address ng hub sa field ng susunod na hop sa host ng sensor. Naglalagay ang VPN ng sarili nitong landas, at ang ordinaryong Ethernet na pagkakalapit sa pampublikong dulo ay isang kathang-isip na gumagawa ng konfigurasyong mukhang kapani-paniwala.
Ang mga sagot ang kalahating madalas laktawan. Kailangang ipadala ng device ang sagot nito pabalik sa tunnel, alinman sa ruta patungo sa kliyente ng operator o sa parehong gateway na nagsalin ng kahilingan. Ang sensor na may maling default na gateway ay tumatanggap ng kahilingan at sumasagot sa wala, at ang mga tala sa pagpapasa ay nagpapaliwanag kung bakit ang pagdating at pagruruta ng sagot ay dalawang pangangailangan at hindi isa.
Magpasya, pagkatapos isulat ang hangganan
Isulat ang hangganan ng pag-access bago may kumonekta. Limitahan ang gateway sa segment ng IoT at sa mga partikular na serbisyong kailangan ng operator, dahil ang gumaganang ruta ay madaling maging pangkalahatang pag-access nang hindi sinasadya. Panatilihing magkahiwalay na tungkulin na may magkahiwalay na pagkakakilanlan ang pagsubaybay na basahin-lamang at ang awtoridad sa konfigurasyon, at pangalanan ang taong nag-aalis ng pag-access kapag natapos ang kontrata.
Ang pag-apruba ay pag-aari ng may-ari ng network, at ang pagiging nasa DMZ ay hindi patakaran sa pag-access.
Ang pagsubok pagkatapos ng deployment ay boring at tiyak: isang kahilingang nasa loob ng pinapayagang prefix na nagtagumpay, isang counter na tumataas sa gateway, at isang sinadyang pagtatangka sa labas ng prefix na nabigo.