Én VPN-konto på tværs af to servere: tre tilstandsbøger

Én konto, der kan logge ind på enhver af to VPN-noder, rejser et designspørgsmål længe før et softwarespørgsmål. Konto-visningen, det netværk hver node ejer, og den session en tilsluttet klient holder, er tre forskellige slags tilstand, og de fejler på forskellige måder, når du kopierer dem rundt. At kopiere alle tre ind i ét system er en almindelig måde at miste en af dem på.

Gå gennem de tre bøger nedenfor i rækkefølge. Hver af dem spørger, hvad der er autoritativt, hvad der er lokalt, og hvad der sker, når den anden node er væk, og svarene følger ikke af hinanden.

Hvem må forbinde: én autoritet, mange noder

Start med adgangsbogen: hvilken identitetskilde der er autoritativ, hvilke certifikatudstedere der er betroet, hvilke konti der er kvalificerede, hvilken anden faktor der gælder, og hvad hver konto kan nå. Skriv derefter ned, hvordan hver node får besked om ændringer, og hvor hurtigt.

En delt database er én mulig komponent i det svar. Det er ikke bevis for, at hver relevant politik bor der, eller at hver node anvender en ændring i samme øjeblik. En konto, der er deaktiveret på node A, men stadig accepteret på node B, betyder, at offboarding-processen ikke er afsluttet.

Beslut, hvad en node gør, når autoriteten ikke kan nås. At acceptere cachede legitimationsoplysninger under et udfald er et politikvalg med en sikkerhedsomkostning, og at afvise dem er et politikvalg med en tilgængelighedsomkostning. Begge er forsvarlige; at lade det være udokumenteret er ikke.

Hold udstederautoritet adskilt fra kontodata. Flere gateways kan stole på samme CA uden at have dens signeringsnøgle, og hver node har stadig brug for sit eget servercertifikat og sit eget klient-side-tillidsforhold.

Hvad en node ejer: adresser og ruter

Den anden bog er lokal for hver node: lytteadresse, serveridentitet, adressepulje, ruter til private ressourcer, resolverpolitik, og hvordan trafikken forlader mod internettet. Den samme konto kan betjenes af begge noder, mens disse objekter forbliver adskilte.

Returvejen er den del, der bliver glemt. Hvis begge noder uddeler adresser fra samme pulje, kan det private netværk ikke se, hvilken node en given klient tilhører, og svaret kan blive sendt det forkerte sted hen. Forskellige puljer har også brug for ruter og tilladelser, så et særskilt nummerområde er ikke et komplet design.

Send klienter til en node med vilje. DNS-valg, lister over klientendepunkter og en front-end-tjeneste er forskellige mekanismer med forskellig adfærd for sundhed og failover. At vælge én er fint; at behandle “load balancing” som designet efterlader returvejen og fejladfærden udefineret.

Et dokumenteret produkteksempel hjælper her. Pritunls replikeringsdokumentation behandler VPN-netværket som et objekt per replika, og klienter på forskellige replikaer har brug for ekstra ruter og forbindelse for at nå hinanden. Det er en produktspecifik ordning, ikke en opskrift til Community OpenVPN, men den viser, hvorfor tilføjelsen af en replika ændrer netværket og ikke kun kontolageret.

Hvad en session er: levende tilstand, ikke en række

Den tredje bog er den live session. En tilsluttet klient har protokottilstand og en netværkstildeling på den node, der accepterede den. At kontoen er kendt på den anden node, giver ikke den node sessionen, nøglerne eller evnen til at fortsætte pakkerne.

Vær udtrykkelig om, hvad der sker, når en node fejler. Det understøttede resultat kan være en genopkobling til den anden node med frisk autentificering og en ny adresse, hvorefter applikationen kommer sig på sin egen måde. Hvis uafbrudt overdragelse kræves, kræver det krav eksplicit implementeringsstøtte, ikke en slutning fra databasereplikering. Skriv svaret ned, hvor den vagthavende ingeniør kan finde det.

Kapacitetsregler har brug for samme behandling. En grænse på to samtidige sessioner per konto kan kun håndhæves på tværs af noder, hvis en eller anden autoritet har et koordineret billede af besatte pladser. Node-lokale lister og en historisk kontopost summer ikke til det billede.

Afprøvning af de tre bøger

Prøv hver af dem separat. Log ind via node A, derefter via node B, og bekræft, at begge lykkes med de forventede adresseområder. Træk en identitet tilbage, og kontroller begge noder, ikke kun den, du tilfældigvis testede. Stop derefter en node, og observer, hvad klienten og den private applikation faktisk gør.

Medtag returvejen i accepttesten. En klient, der forbinder til B, men ikke kan modtage svar fra en ressource bag A, har bestået adgangskontrollen og dumpet den netværksmæssige, og den forskel bør fremgå af rapporten.

Først når alle tre bøger har en udtrykkelig ejer, en ændringsvej og en fejladfærd, er fler-node-kontodesignet komplet. At kopiere en konfigurationsfil på tværs af noder besvarer ingen af de spørgsmål.