Sentraliseer vennoot-VPN-toegang sonder om vennote saam te voeg

Die voorstel is redelik: vyf vennoot-tonnels versprei oor ’n dosyn skootrekenaars, vyf stelle kliëntweergawes, vyf lessenaarondersteuningsprosedures, en een ingenieur wat weet hoe hulle inmekaar pas. Om hulle na ’n beheerde toegangsvlak te skuif, los die eindpunt-uitbreiding op. Dit skep ook ’n nuwe objek in jou argitektuur, ’n gedeelde toegangsdiens wat nou sy eie magtigingsmodel nodig het, en die mislukking wat almal onderskat, is ’n sentrale toestel met elke tonnel geaktiveer wat stilweg ’n deurvoernetwerk word tussen organisasies wat nooit ingestem het om bure te wees nie. Daardie risiko is ’n ontwerpkeuse, nie iets wat die hardeware op sy eie doen nie. Die werk hieronder is hoe ek die gerief behou sonder om die toevallige newe-effek te aanvaar.

Begin by die kontrak wat elke vennoot reeds onderteken het

Voor enige konfigurasie, bevestig dat die vennoot hoegenaamd ’n gedeelde gateway of werfverbinding toelaat. ’n Persoonlike afstandtoegangrekening, ’n toestelpostuur-vereiste of ’n interaktiewe MFA-vloei is dalk nie oordraagbaar na ’n onbewaakte gedeelde tonnel nie, en werknemers agter een gekopieerde kliëntidentiteit saam te bondel is die soort kortpad wat bly voortbestaan totdat die vennoot hul logs ouditeer. Vir elke toegelate verbinding, teken bestemmingsreekse, private DNS-domeine, gemagtigde interne bronne, die verifikasie-eienaar en wat moet gebeur wanneer die tonnel misluk, aan. Vra die vennoot om die gedeelde verbinding skriftelik te bevestig, insluitend die bronreekse wat hulle sal aanvaar. Mondelinge goedkeuring verander gewoonlik van betekenis in die week wat hul sekuriteitspan roteer.

Daardie rekord is die lewering. As jy dit nie vir een vennoot kan skryf nie, is daardie vennoot nie gereed om gesentraliseer te word nie.

Roeteer volgens konteks, nie net volgens bestemming nie

Twee vennote sal uiteindelik dieselfde private reeks gebruik, want elke organisasie kies uit dieselfde RFC 1918-ruimte. ’n Enkele gewone roeteringstabel kan nie die korrekte vennoot uit ’n bestemmingsadres alleen kies nie, so oorvleuelende reekse het aparte roeteringskontekste of ’n ander ooreengekome ontwerp nodig. Die aanstuurdomein-model in RFC 4364 beskryf waarom die skeiding saak maak, en ’n ontplooiing hoef nie MPLS te gebruik om dieselfde eienskap van sy gateway-platform te vereis nie.

Vra die platform ’n reguit vraag: kan twee vennote ’n bestemmingsvoorvoegsel deel en steeds onderskei word deur die werknemerkonteks waaruit die sessie gekom het? As die antwoord nee is, vorm daardie beperking die ontwerp meer as enige verskaffer-kenmerklys.

Waar die antwoord ja is, word die roeteringskonteks die ding wat jy dokumenteer en toets, want dit is onsigbaar in ’n traceroute.

Besluit wat die werknemer tik en wat die vennoot logs

Sommige vennootwerk pas by ’n toepassingsproxy of ’n afstandwerkspasie wat binne daardie vennoot se konteks oopgemaak word. Ander werk benodig geroteerde netwerktoegang vanaf ’n goedgekeurde werknemersegment, en die twee lewer verskillende bronadresse en verskillende ouditspore aan die ander kant. ’n Gedeelde vertaalde bronadres kan ’n toelatingslys bevredig terwyl dit wegsteek watter toestel wat gedoen het, so behou ’n betroubare werknemer-tot-sessie-rekord en hou toepassingsverifikasie in plek eerder as om ’n gateway-adres as ’n identiteit te behandel, wat gerieflik is tot die oomblik dat die vennoot vra wie dit gedoen het.

Stap dan een werklike taak van die werknemer se kant af: wat hulle klik, waarvoor hulle gevra word, en wat die vennoot sou sien as hulle ’n loginskrywing sou vra. As daardie deurloop nie herhaalbaar is nie, is die ontwerp nie klaar nie.

Weier vennoot-tot-vennoot-deurvoer eksplisiet

Gedeelde hardeware moet nooit gedeelde vertroue impliseer nie. Voeg die weiering by as ’n doelbewuste reël met ’n genoemde eienaar, nie as ’n ongeluk van ontbrekende konfigurasie nie, en toets dit uit beide rigtings met ’n versoek wat andersins sou slaag. Die toets maak saak omdat ’n toelating wat bloot afwesig is, herstel kan word deur die volgende ingenieur wat ’n roete byvoeg om ’n onverwante klagte op te los.

Skryf die weiering in die vennootrekord langs die toelatings, sodat die bedoeling personeelveranderinge oorleef.

Bedryf dit as ’n gedeelde diens, nie as ’n groter skootrekenaar nie

Tonnelvernuwing, geloofsbrief-rotasie, kapasiteit en gateway-vervanging word nou almal gedeelde-diens-veranderinge, wat beteken hulle het ’n skedule en ’n kommunikasiepad nodig wat individuele skootrekenaars nooit vereis het nie. ’n Vennoot-sertifikaat wat op ’n Saterdag verval is nie meer een gebruiker se onderbreking nie; dit is elke sessie vir daardie vennoot gelyktydig.

Aanvaar die vlak eers wanneer ’n geweierde kruis-vennoot-versoek presies misluk soos beoog en ’n toegelate werknemersversoek die regte bestemming met die regte bron bereik. Om skootrekenaarkonflik te verwyder terwyl elke vennoot se grens intak bly, is die hele punt; ’n ontwerp waar elke afstandvoorvoegsel van elke lessenaar bereikbaar is, het net die probleem verskuif.

Hou ’n klein tabel van vennoot, konteks, toegelate reekse en eienaar. Dit sal die eerste ding wees waarvoor iemand tydens ’n voorval vra.