Én VPN-konto på tvers av to servere: tre tilstandsregistre

Én konto som kan logge på hvilken som helst av to VPN-noder reiser et designspørsmål lenge før det reiser et programvarespørsmål. Konto-visningen, nettverket hver node eier, og sesjonen en tilkoblet klient holder, er tre forskjellige typer tilstand, og de feiler på ulike måter når du kopierer dem rundt. Å kopiere alle tre inn i ett system er en vanlig måte å miste én av dem på.

Gå gjennom de tre registrene nedenfor i rekkefølge. Hvert av dem spør hva som er autoritativt, hva som er lokalt, og hva som skjer når den andre noden er borte, og svarene følger ikke av hverandre.

Hvem får koble til: én autoritet, mange noder

Start med adgangsregisteret: hvilken identitetskilde som er autoritativ, hvilke sertifikatutstedere som er betrodd, hvilke kontoer som er kvalifiserte, hvilken annen faktor som gjelder, og hva hver konto kan nå. Skriv deretter ned hvordan hver node får vite om endringer, og hvor raskt.

En delt database er én mulig komponent i det svaret. Det er ikke bevis for at hver relevant policy bor der, eller at hver node anvender en endring i samme øyeblikk. En konto som er deaktivert på node A men fortsatt akseptert på node B betyr at avslutningsprosessen ikke er ferdig.

Bestem hva en node gjør når autoriteten ikke er tilgjengelig. Å godta hurtiglagrede påloggingsdata under en avbrudd er et policyvalg med en sikkerhetskostnad, og å avvise dem er et policyvalg med en tilgjengelighetskostnad. Begge er forsvarlige; å la det være udokumentert er det ikke.

Hold utstederautoriteten atskilt fra kontodata. Flere gatewayer kan stole på samme CA uten å holde signeringsnøkkelen, og hver node trenger fortsatt sitt eget server-sertifikat og sitt eget klient-side tillitsforhold.

Hva en node eier: adresser og ruter

Det andre registeret er lokalt for hver node: lyttadresse, serveridentitet, adressepool, ruter til private ressurser, resolverpolicy, og hvordan trafikken går ut mot internett. Den samme kontoen kan betjenes av hvilken som helst av de to nodene mens disse objektene forblir atskilte.

Returveien er den delen som blir glemt. Hvis begge nodene deler ut adresser fra samme pool, kan det private nettverket ikke si hvilken node en gitt klient tilhører, og svaret kan bli sendt til feil sted. Ulike pooler trenger også ruter og tillatelser, så et eget nummerområde er ikke et fullstendig design.

Send klienter til en node med vilje. DNS-valg, lister over klientendepunkter og en front-end-tjeneste er forskjellige mekanismer med ulik oppførsel for helse og failover. Å velge én er greit; å behandle «lastbalansering» som designet lar returveien og feiloppførselen stå udefinert.

Et dokumentert produkteksempel hjelper her. Replikasjonsdokumentasjonen til Pritunl behandler VPN-nettverket som et objekt per replika, og klienter på ulike replikaer trenger ekstra ruter og tilkobling for å nå hverandre. Det er en produktspesifikk ordning, ikke en oppskrift for Community OpenVPN, men den viser hvorfor det å legge til en replika endrer nettverket og ikke bare kontolageret.

Hva en sesjon er: levende tilstand, ikke en rad

Det tredje registeret er den levende sesjonen. En tilkoblet klient har protokolltilstand og en nettverkstildeling på noden som godtok den. At kontoen er kjent på den andre noden, gir ikke den noden sesjonen, nøklene eller evnen til å fortsette pakkene.

Vær tydelig på hva som skjer når en node feiler. Det støttede utfallet kan være en gjentilkobling til den andre noden med fersk autentisering og en ny adresse, hvoretter applikasjonen kommer seg på sin egen måte. Hvis sømløs overlevering kreves, trenger det kravet eksplisitt implementeringsstøtte, ikke en slutning fra databasereplikering. Skriv svaret ned der vaktingeniøren kan finne det.

Kapasitetsregler trenger samme behandling. En grense på to samtidige sesjoner per konto kan bare håndheves på tvers av noder hvis en eller annen autoritet har et koordinert bilde av opptatte plasser. Node-lokale lister og en historisk kontooppføring summerer seg ikke til det bildet.

Prøve de tre registrene

Øv på hver av dem separat. Logg på via node A, deretter via node B, og bekreft at begge lykkes med de forventede adresseområdene. Trekk tilbake en identitet og kontroller begge nodene, ikke bare den du tilfeldigvis testet. Stopp deretter én node og observer hva klienten og den private applikasjonen faktisk gjør.

Ta med returveien i akseptansetesten. En klient som kobler til B men ikke kan motta svar fra en ressurs bak A, har bestått adgangskontrollen og strøket på nettverkskontrollen, og den forskjellen bør fremgå av rapporten.

Fler-node-kontodesignet er først komplett når alle tre registrene har en uttrykkelig eier, en endringsvei og en feiloppførsel. Å kopiere en konfigurasjonsfil på tvers av noder svarer ikke på noen av disse spørsmålene.