Tri adresaj decidoj antaŭ ol meti IoT-sensilojn malantaŭ VPN
Tri adresoj plenumas tri taskojn: la publika hubo, la aŭtentigita reteja peer kaj la privata adreso de la sensilo. Planu ĉiun antaŭ ol atribui ion publikan.
Tri adresoj implikiĝas en ĉiu plano de IoT tra VPN, kaj ili ne estas la sama speco de decido. Unu estas kiel fora operatoro trovas la tunelan finpunkton, unu estas kiel la retejo pruvas, ke ĝi estas la retejo, kaj unu estas kie la servo de la sensilo efektive aŭskultas. Respondu ilin en tiu ordo kaj la dezajno preskaŭ mem aperas. Respondu ilin kiel unu demandon kaj vi finiĝos atribuante publikajn adresojn al aparatoj, kiuj neniam bezonis unu. Sensilo malantaŭ elira reteja tunelo estas atingebla de rajtigita operatoro sen iu ajn enira regulo direktita al la sensilo.
Komencu per tiu, kiu iniciatas
Kiu vokas determinas preskaŭ ĉion poste. Kiam la retejo vokas hubon, la retejo bezonas nenian eniran atingeblon, kaj la hubo bezonas nomon aŭ adreson, kiun la retejo povas solvi. Tiu unu elekto forigas plejparton de la debato pri statika publika adresado antaŭ ol ĝi komenciĝas.
La tri roloj tiam apartiĝas pure, kaj la tabelo sube estas la plej mallonga formo de la decido.
| 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 |
Ĉiu vico havas alian posedanton, kaj tio estas la vera punkto. La hubo apartenas al tiu, kiu funkciigas la VPN-servon, la reteja peer al la reta teamo, kaj la adreso de la sensilo al tiu, kiu posedas la aparaton.
La huba adreso estas startigo, ne celo
Nomo, kiu solviĝas al prizorgata publika adreso, sufiĉas por la hubo. DNS-rikordo povas sekvi la finpunkton, kiam ĝi moviĝas, sen mane redakti ĉiun retejan agordon. Kion DNS ne faras, estas krei atingeblon aŭ refreŝigi klienton, kiu kaŝmemorigas la malnovan respondon, kaj tiuj estas apartaj problemoj kun apartaj solvoj.
Se vi funkciigas tunelojn retejo-al-retejo sen hubo, la sama logiko validas en alia formo: unu flanko bezonas atingeblan finpunkton, aŭ ambaŭ flankoj vokas trian partion. Iu ankoraŭ devas posedi tiun adreson kaj ĝiajn renovigojn.
La reteja peer estas identeco kun aldonita prefikso
La peer estas unue identeco kaj due prefikso. En terminoj de WireGuard la peer tenas ŝlosilan paron, kaj la AllowedIPs-rikordo de la hubo ligas tiun ŝlosilon al la prefikso de la retejo. En terminoj de IKEv2 atestilo aŭ antaŭe dividita ŝlosilo identigas la retejon, kaj ĝiaj trafikaj selektiloj diras, kion ĝi rajtas porti. Ŝanĝi nur unu duonon rompas la aranĝon, kaj tial adresa ŝanĝo neniam traktiĝu kiel identeca ŝanĝo.
Tenu la posedon de la ŝlosilo aŭ atestilo ĉe la retejo anstataŭ ĉe la huba operatoro, por ke ŝanĝo de provizanto ne fariĝu ŝanĝo de identeco.
La prefikso estas la parto, kiun homoj forgesas plani. La hubo devas ligi la sensilan subreton al la ĝusta peer, kaj la kliento de la operatoro bezonas itineron al ĝi; itinero, kiu ekzistas nur ĉe la kliento, sendas trafikon en tunelon, kiu silente forĵetas ĝin. Skribu la prefikson en la retejan rikordon apud la ŝlosila fingrospuro, por ke anstataŭiga pordego ne povu aperi kun malsama kovrado nerimarkite.
La adreso de la sensilo apartenas al la aplikaĵo
Privata adreso el la plano de la retejo sufiĉas, kaj kion ĝi bezonas estas stabileco anstataŭ publika atingeblo: DHCP-rezervo, statika atribuo aŭ nomo en la propra zono de la retejo. Se la aparato ne povas esti renumerita, traduko ĉe la reteja pordego estas legitima respondo, kondiĉe ke la traduko estas dokumentita kaj la revena trafiko sekvas ĝin.
Ankoraŭ unu kutimo inda konservi: neniam algluu la publikan huban adreson en kampon de sekva salto ĉe la gastiganto de la sensilo. La VPN instalas sian propran vojon, kaj ordinara Ethernet-apudeco al publika finpunkto estas fikcio, kiu produktas konvinke aspektan agordon.
Respondoj estas la duono, kiu estas preterlasata. La aparato devas sendi sian respondon reen al la tunelo, aŭ per itinero al la kliento de la operatoro aŭ per la sama pordego, kiu tradukis la peton. Sensilo kun la malĝusta implicita pordego akceptas la peton kaj respondas en nenion, kaj la notoj pri plusendado klarigas, kial alveno kaj responda enkursigado estas du postuloj, ne unu.
Decidu, poste skribu la limon
Skribu la alirlimon antaŭ ol iu konektiĝos. Limigu la pordegon al la IoT-segmento kaj al la specifaj servoj, kiujn la operatoro bezonas, ĉar funkcianta itinero emas fariĝi ĝenerala aliro akcidente. Tenu legadnuran observadon kaj agordon kiel apartajn rolojn kun apartaj identecoj, kaj nomu la personon, kiu forigas aliron, kiam la kontrakto finiĝas.
Aprobo apartenas al la reta posedanto, kaj esti en DMZ ne estas alirpolitiko.
La testo post deplojo estas enuiga kaj konkluda: unu peto ene de la permesita prefikso, kiu sukcesas, nombrilo, kiu pliiĝas ĉe la pordego, kaj unu intenca provo ekster la prefikso, kiu malsukcesas.