Éin VPN-konto på tvers av to serverar: tre tilstandsregister

Éin konto som kan logge på kvar som helst av to VPN-nodar reiser eit designspørsmål lenge før det reiser eit programvarespørsmål. Konto-visninga, nettverket kvar node eig, og sesjonen ein tilkopla klient held, er tre ulike slag tilstand, og dei feilar på ulike måtar når du kopierer dei rundt. Å kopiere alle tre inn i eitt system er ein vanleg måte å miste éin av dei på.

Gå gjennom dei tre registra nedanfor i rekkjefølgje. Kvart av dei spør kva som er autoritativt, kva som er lokalt, og kva som skjer når den andre noden er borte, og svara følgjer ikkje av kvarandre.

Kven får kople til: éin autoritet, mange nodar

Start med tilgangsregisteret: kva identitetskjelde som er autoritativ, kva sertifikatutgivarar som er betrudde, kva kontoar som er kvalifiserte, kva annan faktor som gjeld, og kva kvar konto kan nå. Skriv deretter ned korleis kvar node får vite om endringar, og kor raskt.

Ein delt database er éin mogleg komponent i det svaret. Det er ikkje prov for at kvar relevant policy bur der, eller at kvar node brukar ei endring i same augneblink. Ein konto som er deaktivert på node A men framleis godteken på node B, tyder at avslutningsprosessen ikkje er ferdig.

Avgjer kva ein node gjer når autoriteten ikkje er tilgjengeleg. Å godta hurtiglagra påloggingsdata under eit avbrot er eit policyval med ein tryggingskostnad, og å avvise dei er eit policyval med ein tilgjengekostnad. Begge er forsvarlege; å la det vere udokumentert er det ikkje.

Hald utgivarautoriteten skild frå kontodata. Fleire gatewayar kan stole på same CA utan å halde signeringsnøkkelen, og kvar node treng framleis sitt eige serversertifikat og sitt eige klient-side tillitsforhold.

Kva ein node eig: adresser og ruter

Det andre registeret er lokalt for kvar node: lyttadresse, serveridentitet, adressepool, ruter til private ressursar, resolverpolicy, og korleis trafikken går ut mot internett. Den same kontoen kan tenast av kven som helst av dei to nodane medan desse objekta blir skilde.

Returvegen er den delen som blir gløymd. Viss begge nodane deler ut adresser frå same pool, kan det private nettverket ikkje seie kva node ein gitt klient høyrer til, og svaret kan bli sendt til feil stad. Ulike poolar treng også ruter og løyve, så eit eige nummerområde er ikkje eit fullstendig design.

Send klientar til ein node med vilje. DNS-val, lister over klientendepunkt og ein front-end-teneste er ulike mekanismar med ulik åtferd for helse og failover. Å velje éin er greitt; å handsame «lastbalansering» som designet lèt returvegen og feilåtferda stå udefinert.

Eit dokumentert produkteksempel hjelper her. Replikasjonsdokumentasjonen til Pritunl handsamar VPN-nettverket som eit objekt per replika, og klientar på ulike replikaer treng ekstra ruter og tilkopling for å nå kvarandre. Det er ei produktspesifikk ordning, ikkje ei oppskrift for Community OpenVPN, men ho viser kvifor det å leggje til ein replika endrar nettverket og ikkje berre kontolageret.

Kva ein sesjon er: levande tilstand, ikkje ei rad

Det tredje registeret er den levande sesjonen. Ein tilkopla klient har protokolltilstand og ei nettverkstildeling på noden som godtok han. At kontoen er kjend på den andre noden, gir ikkje den noden sesjonen, nøklane eller evna til å halde fram pakkane.

Ver tydeleg på kva som skjer når ein node feilar. Det støtta utfallet kan vere ein gjentilkopling til den andre noden med fersk autentisering og ei ny adresse, kva etterpå applikasjonen kjem seg på sin eigen måte. Viss sømlaus overlevering er kravd, treng det kravet eksplisitt implementeringsstøtte, ikkje ei slutning frå databasereplikering. Skriv svaret ned der vaktingeniøren kan finne det.

Kapasitetsreglar treng same handsaming. Ei grense på to samtidige sesjonar per konto kan berre handhevast på tvers av nodar viss ein eller annan autoritet har eit koordinert bilete av opptekne plassar. Node-lokale lister og eit historisk kontoinnslag summerer seg ikkje til det biletet.

Prøve dei tre registra

Øv på kvar av dei separat. Logg på via node A, deretter via node B, og stadfest at begge lukkast med dei forventa adresseområda. Trekk tilbake ein identitet og kontroller begge nodane, ikkje berre den du tilfeldigvis testa. Stopp deretter éin node og observer kva klienten og den private applikasjonen faktisk gjer.

Ta med returvegen i akseptansetesten. Ein klient som koplar til B men ikkje kan ta imot svar frå ein ressurs bak A, har bestått tilgangskontrollen og stroke på nettverkskontrollen, og den skilnaden bør kome fram i rapporten.

Fleirnode-kontodesignet er først komplett når alle tre registra har ein uttrykkeleg eigar, ein endringsveg og ei feilåtferd. Å kopiere ei konfigurasjonsfil på tvers av nodar svarar ikkje på noko av desse spørsmåla.