Een VPN-rekening oor twee bedieners: drie toestandgrootboeke

Een rekening wat by enigeen van twee VPN-nodusse kan aanmeld, laat ’n ontwerpvraag ontstaan lank voordat dit ’n sagtewarevraag laat ontstaan. Die rekeningaansig, die netwerk wat elke nodus besit, en die sessie wat ’n gekoppelde kliënt hou, is drie verskillende soorte toestand, en hulle faal op verskillende maniere wanneer jy hulle rondkopieer. Om al drie in een stelsel te kopieer, is ’n algemene manier om een van hulle te verloor.

Werk die drie grootboeke hieronder in volgorde deur. Elkeen vra wat gesaghebbend is, wat plaaslik is, en wat gebeur wanneer die ander nodus weg is, en die antwoorde volg nie uit mekaar nie.

Wie mag koppel: een gesag, baie nodusse

Begin met die toelatingsgrootboek: watter identiteitsbron gesaghebbend is, watter sertifikaatuitreikers vertrou word, watter rekeninge in aanmerking kom, watter tweede faktor geld, en wat elke rekening kan bereik. Skryf dan neer hoe elke nodus van veranderinge leer, en hoe vinnig.

’n Gedeelde databasis is een moontlike komponent van daardie antwoord. Dit is nie ’n bewys dat elke relevante beleid daar woon nie, of dat elke nodus ’n verandering op dieselfde oomblik toepas nie. ’n Rekening wat by nodus A gedeaktiveer is maar steeds by nodus B aanvaar word, beteken die afskeidingsproses is nie voltooi nie.

Besluit wat ’n nodus doen wanneer die gesag onbereikbaar is. Om gekasde geloofsbriewe tydens ’n onderbreking te aanvaar, is ’n beleidskeuse met ’n sekuriteitskoste, en om hulle te verwerp is ’n beleidskeuse met ’n beskikbaarheidskoste. Enigeen is verdedigbaar; om dit ongedokumenteer te laat, is nie.

Hou ook uitreikergesag apart van rekeningdata. Verskeie poorte kan dieselfde CA vertrou sonder om sy ondertekeningsleutel te hou, en elke nodus het steeds sy eie bediener-sertifikaat en sy eie kliëntkant-vertrouensverhouding nodig.

Wat ’n nodus besit: adresse en roetes

Die tweede grootboek is plaaslik aan elke nodus: luisteradres, bedieneridentiteit, adrespoel, roetes na private hulpbronne, oplosserbeleid, en hoe verkeer na die internet uitgaan. Dieselfde rekening kan deur enigeen van die nodusse bedien word terwyl hierdie objekte afsonderlik bly.

Die terugpad is die deel wat vergeet word. As beide nodusse adresse uit dieselfde poel uitdeel, kan die private netwerk nie sê watter nodus ’n gegewe kliënt besit nie, en die antwoord kan na die verkeerde plek gestuur word. Verskillende poele het ook roetes en toestemmings nodig, so ’n afsonderlike nommerreeks is nie ’n volledige ontwerp nie.

Rig kliënte doelbewus na ’n nodus. DNS-keuse, kliënt-eindpuntlyste en ’n front-end-diens is verskillende meganismes met verskillende gesondheids- en oorskakelgedrag. Om een te kies is goed; om “lasbalansering” as die ontwerp te behandel, laat die terugpad en die foutgedrag ongedefinieer.

’n Gedokumenteerde produkvoorbeeld help hier. Pritunl se replikasiedokumentasie behandel die VPN-netwerk as ’n objek per replika, en kliënte op verskillende replika’s het ekstra roetes en konnektiwiteit nodig om mekaar te bereik. Dit is ’n produk-spesifieke reëling, nie ’n resep vir Community OpenVPN nie, maar dit wys waarom die byvoeg van ’n replika die netwerk verander en nie net die rekeningstoor nie.

Wat ’n sessie is: lewende toestand, nie ’n ry nie

Die derde grootboek is die lewende sessie. ’n Gekoppelde kliënt het protokoltoestand en ’n netwerktoewysing op die nodus wat hom aanvaar het. Die feit dat die rekening by die ander nodus bekend is, gee nie daardie nodus die sessie, die sleutels of die vermoë om die pakkette voort te sit nie.

Wees duidelik oor wat gebeur wanneer ’n nodus faal. Die ondersteunde uitkoms mag ’n herverbinding aan die ander nodus wees met vars verifikasie en ’n nuwe adres, waarna die toepassing op sy eie manier herstel. As ononderbroke oordrag vereis word, het daardie vereiste eksplisiete implementeringsondersteuning nodig, nie ’n afleiding uit databasisreplikasie nie. Skryf die antwoord neer waar die diensingenieur dit kan vind.

Kapasiteitsreëls het dieselfde behandeling nodig. ’n Limiet van twee gelyktydige sessies per rekening kan slegs oor nodusse afgedwing word as een of ander gesag ’n gekoördineerde siening van besette plekke het. Nodus-plaaslike lyste en ’n historiese rekeningrekord tel nie op tot daardie siening nie.

Om die drie grootboeke te toets

Oefen elkeen afsonderlik. Meld aan deur nodus A, dan deur nodus B, en bevestig dat albei slaag met die verwagte adresreekse. Trek ’n identiteit terug en kontroleer beide nodusse, nie net die een wat jy toevallig getoets het nie. Stop dan een nodus en waarneem wat die kliënt en die private toepassing werklik doen.

Sluit die terugpad by die aanvaardingstoets in. ’n Kliënt wat aan B koppel maar nie antwoorde van ’n hulpbron agter A kan ontvang nie, het die toelatingstoets geslaag en die netwerketoets gedruip, en daardie onderskeid moet in die verslag verskyn.

Slegs wanneer al drie grootboeke ’n eksplisiete eienaar, ’n veranderingspad en ’n foutgedrag het, is die multi-nodus-rekeningontwerp volledig. Om ’n konfigurasielêer oor nodusse te kopieer, beantwoord nie een van daardie vrae nie.