Centraligu la VPN-aliron de partneroj sen kunigi la partnerojn
Partnerspecifaj VPN-oj sur komuna kluzo finas tekkomputilajn konfliktojn sed kreas komunan servon. Tenu la rajtigon, enkursigon kaj identecon de ĉiu partnero aparte.
La propono estas racia: kvin partneraj tuneloj disigitaj sur dekduo da tekkomputiloj, kvin aroj da klientaj versioj, kvin skriptoj por la subtena servo, kaj unu inĝeniero, kiu scias kiel ili kunfalas. Transloki ilin al regata alira nivelo solvas la disvastiĝon de finpunktoj. Ĝi ankaŭ kreas novan objekton en via arkitekturo, komunan aliran servon, kiu nun bezonas sian propran rajtigmodelon, kaj la fiasko, kiun ĉiuj subtaksas, estas centra aparato kun ĉiuj tuneloj ŝaltitaj, kiu silente fariĝas transita reto inter organizoj, kiuj neniam konsentis esti najbaroj. Tiu risko estas dizajna decido, ne io, kion la aparataro faras per si mem. La laboro sube montras, kiel mi konservas la komforton sen akcepti la hazardan kromefikon.
Komencu per la kontrakto, kiun ĉiu partnero jam subskribis
Antaŭ iu ajn agordo, konfirmu, ke la partnero entute permesas komunan kluzon aŭ retejan ligon. Persona fora alirkonto, postulo pri aparata stato aŭ interaga MFA-fluo eble ne transdoneblas al nesuperrigardata komuna tunelo, kaj grupigi dungitojn malantaŭ unu kopiita klienta identeco estas tiu speco de fuŝsolvo, kiu pluvivas ĝis la partnero revizios siajn protokolojn. Por ĉiu permesita ligo, registru celajn gamojn, privatajn DNS-domajnojn, rajtigitajn internajn fontojn, la posedanton de aŭtentikigo, kaj kio devas okazi, kiam la tunelo fiaskos. Petu la partneron konfirmi la komunan ligon skribe, inkluzive la fontgamojn, kiujn ili akceptos. Parola aprobo kutime ŝanĝas signifon en la semajno, kiam ilia sekureca teamo rotacias.
Tiu registro estas la rezultaĵo. Se vi ne povas skribi ĝin por unu partnero, tiu partnero ne pretas esti centralizita.
Enkursigu laŭ kunteksto, ne nur laŭ celo
Du partneroj fine uzos la saman privatan gamon, ĉar ĉiu organizo elektas el la sama RFC 1918-spaco. Unu ordinara enkursiga tabelo ne povas elekti la ĝustan partneron nur laŭ cela adreso, do koincidantaj gamoj bezonas apartajn enkursigajn kuntekstojn aŭ alian interkonsentitan dizajnon. La modelo de plusenda domajno en RFC 4364 klarigas, kial tiu apartigo gravas, kaj lanĉo ne bezonas funkciigi MPLS por postuli la saman econ de sia kluzplatformo.
Demandu la platformon rekte: ĉu du partneroj povas dividi unu celan prefikson kaj tamen distingiĝi laŭ tio, el kiu dungita kunteksto la sesio venis? Se la respondo estas ne, tiu limigo formas la dizajnon pli ol iu ajn funkciolisto de vendanto.
Kie la respondo estas jes, la enkursiga kunteksto fariĝas tio, kion vi dokumentas kaj testas, ĉar ĝi estas nevidebla en traceroute.
Decidu, kion la dungito tajpas kaj kion la partnero protokolas
Iu partnera laboro taŭgas por aplikaĵa prokurilo aŭ fora laborujo malfermita en la kunteksto de tiu partnero. Alia laboro bezonas enkursigitan retaliron el aprobita dungita segmento, kaj ambaŭ produktas malsamajn fontajn adresojn kaj malsamajn reviziajn spurojn ĉe la malproksima fino. Komuna tradukita fonta adreso povas plenumi permesliston dum ĝi kaŝas, kiu aparato faris kion, do konservu fidindan registron de dungito-al-sesio kaj tenu la aplikaĵan aŭtentikigon anstataŭ trakti kluzan adreson kiel identecon, kio estas komforta ĝuste ĝis la momento, kiam la partnero demandas, kiu faris tion.
Poste trairu unu realan taskon el la flanko de la dungito: kion ili klakas, kion oni petas de ili, kaj kion la partnero vidus, se ĝi petus protokolan enskribon. Se tiu trairo ne estas ripetebla, la dizajno ne estas finita.
Malpermesu eksplicite la transiron inter partneroj
Komuna aparataro neniam devus implici komunan fidon. Aldonu la malpermeson kiel intencitan regulon kun nomita posedanto, ne kiel akcidenton de mankanta agordo, kaj testu ĝin en ambaŭ direktoj per peto, kiu alie sukcesus. La testo gravas, ĉar permeson, kiu nur mankas, povas restarigi la sekva inĝeniero, kiu aldonas itineron por solvi nesaman plendon.
Skribu la malpermeson en la partneran registron apud la permesoj, por ke la intenco postvivu personarajn ŝanĝojn.
Funkciigu ĝin kiel komunan servon, ne kiel pli grandan tekkomputilon
Tunela renovigo, rotacio de legitimiloj, kapacito kaj anstataŭigo de kluzo nun ĉiuj fariĝas ŝanĝoj de komuna servo, kio signifas, ke ili bezonas horaron kaj komunikvojon, kiujn unuopaj tekkomputiloj neniam postulis. Partnera atestilo eksvalidiĝanta sabate ne plu estas la malŝalto de unu uzanto; ĝi estas ĉiuj sesioj de tiu partnero samtempe.
Akceptu la nivelon nur kiam rifuzita peto inter partneroj fiaskas ĝuste laŭ la intenco kaj permesita peto de dungito atingas la ĝustan celon kun la ĝusta fonto. Forigi la tekkomputilan konflikton tenante la limon de ĉiu partnero sendifekta estas la tuta celo; dizajno, en kiu ĉiu fora prefikso atingeblas de ĉiu skribotablo, nur movis la problemon.
Tenu malgrandan tabelon de partnero, kunteksto, permesitaj gamoj kaj posedanto. Ĝi estos la unua afero, kiun iu petos en okazaĵo.