Keskitä kumppanien VPN-pääsy yhdistämättä kumppaneita

Ehdotus on järkevä: viisi kumppanitunnelia tusinan kannettavan yli, viisi asiakasversiosarjaa, viisi tukipalvelun komentosarjaa ja yksi insinööri, joka tietää, miten ne sopivat yhteen. Niiden siirtäminen hallittuun pääsytasoon korjaa päätelaitteiden hajautumisen. Se luo myös arkkitehtuuriin uuden objektin, jaetun pääsypalvelun, joka tarvitsee nyt oman valtuutusmallinsa, ja kaikkien aliarvioima vika on keskitetty laite, jossa kaikki tunnelit on kytketty päälle ja joka muuttuu hiljaa kauttakulkoverkoksi organisaatioiden välillä, jotka eivät koskaan suostuneet olemaan naapureita. Tämä riski on suunnitteluvalinta, ei jotain, mitä laitteisto tekee itsestään. Alla oleva työ kertoo, miten pidän mukavuuden hyväksymättä tahatonta sivuvaikutusta.

Aloita sopimuksesta, jonka jokainen kumppani on jo allekirjoittanut

Vahvista ennen mitään konfiguraatiota, että kumppani ylipäätään sallii jaetun yhdyskäytävän tai sivustoyhteyden. Henkilökohtainen etäkäyttötili, laitteen tilavaatimus tai interaktiivinen MFA-virta ei välttämättä ole siirrettävissä valvomattomaan jaettuun tunneliin, ja työntekijöiden kokoaminen yhden kopioidun asiakasidentiteetin taakse on sellainen oikotie, joka kestää, kunnes kumppani auditoi lokinsa. Kirjaa jokaisesta sallitusta yhteydestä kohdealueet, yksityiset DNS-verkkotunnukset, valtuutetut sisäiset lähteet, todentamisen omistaja ja se, mitä pitää tapahtua, kun tunneli epäonnistuu. Pyydä kumppania vahvistamaan jaettu yhteys kirjallisesti, mukaan lukien lähdealueet, jotka se hyväksyy. Suullinen hyväksyntä vaihtaa yleensä merkitystään viikolla, jolloin heidän turvatiiminsä vaihtuu.

Tuo kirjaus on lopputulos. Jos et pysty kirjoittamaan sitä yhdelle kumppanille, se kumppani ei ole valmis keskitettäväksi.

Reititä kontekstin mukaan, ei vain kohteen mukaan

Kaksi kumppania käyttää lopulta samaa yksityistä aluetta, koska jokainen organisaatio valitsee samasta RFC 1918 -avaruudesta. Yksi tavallinen reititystaulu ei voi valita oikeaa kumppania pelkän kohdeosoitteen perusteella, joten päällekkäiset alueet tarvitsevat erilliset reitityskontekstit tai muun sovitun suunnittelun. Edelleenohjausverkkotunnuksen malli kohdassa RFC 4364 selittää, miksi erottelu on tärkeää, eikä käyttöönoton tarvitse ajaa MPLS:ää vaatiakseen saman ominaisuuden yhdyskäytäväalustaltaan.

Kysy alustalta suoraan: voivatko kaksi kumppania jakaa saman kohdeprefiksin ja silti erottua sen mukaan, mistä työntekijäkontekstista istunto tuli? Jos vastaus on ei, tämä rajoitus muotoilee suunnittelua enemmän kuin mikään toimittajan ominaisuusluettelo.

Kun vastaus on kyllä, reitityskontekstista tulee se, mitä dokumentoit ja testaat, koska se on näkymätön traceroutessa.

Päätä, mitä työntekijä kirjoittaa ja mitä kumppani kirjaa

Osa kumppanityöstä sopii sovellusvälityspalvelimeen tai etätyötilaan, joka avataan kyseisen kumppanin kontekstissa. Muu työ vaatii reititetyn verkkoyhteyden hyväksytystä työntekijäsegmentistä, ja molemmat tuottavat eri lähdeosoitteet ja eri auditointijäljet toisessa päässä. Jaettu käännetty lähdeosoite voi täyttää sallittujen luettelon ja samalla piilottaa, mikä laite teki mitä, joten pidä luotettava kirjaus työntekijästä istuntoon ja pidä sovelluksen todentaminen paikallaan sen sijaan, että kohtelisit yhdyskäytävän osoitetta identiteettinä, mikä on kätevää juuri siihen hetkeen asti, kun kumppani kysyy, kuka sen teki.

Käy sitten läpi yksi todellinen tehtävä työntekijän puolelta: mitä he klikkaavat, mitä heiltä kysytään ja mitä kumppani näkisi, jos pyytäisi lokimerkintää. Jos tämä kulku ei ole toistettavissa, suunnittelu ei ole valmis.

Kiellä kumppanien välinen kauttakulku nimenomaisesti

Jaetun laitteiston ei pitäisi koskaan merkitä jaettua luottamusta. Lisää kielto tietoisena sääntönä, jolla on nimetty omistaja, ei puuttuvan konfiguraation vahinkona, ja testaa se molemmista suunnista pyynnöllä, joka muuten onnistuisi. Testi on tärkeä, koska pelkästään puuttuvan luvan voi palauttaa seuraava insinööri, joka lisää reitin ratkaistakseen asiaankuulumattoman valituksen.

Kirjoita kielto kumppanikirjaukseen lupien viereen, jotta aikomus säilyy henkilöstövaihdosten yli.

Aja sitä jaettuna palveluna, ei isompana kannettavana

Tunnelien uusiminen, tunnistetietojen kierrätys, kapasiteetti ja yhdyskäytävän vaihto ovat nyt kaikki jaetun palvelun muutoksia, mikä tarkoittaa, että ne tarvitsevat aikataulun ja viestintäpolun, jota yksittäiset kannettavat eivät koskaan vaatineet. Lauantaina vanhentuva kumppanivarmenne ei ole enää yhden käyttäjän katko; se on kaikki kyseisen kumppanin istunnot kerralla.

Hyväksy taso vasta, kun hylätty kumppanien välinen pyyntö epäonnistuu täsmälleen tarkoitetulla tavalla ja sallittu työntekijäpyyntö saavuttaa oikean kohteen oikealla lähteellä. Kannettavien ristiriidan poistaminen jokaisen kumppanin raja koskemattomana pitäen on koko pointti; suunnittelu, jossa jokainen etäprefiksi on tavoitettavissa jokaiselta työpöydältä, on vain siirtänyt ongelman.

Pidä pientä taulukkoa kumppanista, kontekstista, sallituista alueista ja omistajasta. Se on ensimmäinen asia, jota joku kysyy tapahtuman aikana.