Ett VPN-konto över två servrar: tre tillståndsregister

Ett konto som kan logga in på vilken som helst av två VPN-noder väcker en designfråga långt innan den väcker en mjukvarufråga. Kontovyn, nätverket som varje nod äger och sessionen som en ansluten klient håller är tre olika slags tillstånd, och de misslyckas på olika sätt när du kopierar dem runt. Att kopiera alla tre in i ett system är ett vanligt sätt att tappa en av dem.

Arbeta igenom de tre registren nedan i ordning. Var och en frågar vad som är auktoritativt, vad som är lokalt och vad som händer när den andra noden är borta, och svaren följer inte av varandra.

Vem får ansluta: en auktoritet, många noder

Börja med åtkomstregistret: vilken identitetskälla som är auktoritativ, vilka certifikatutfärdare som är betrodda, vilka konton som är behöriga, vilken andra faktor som gäller och vad varje konto kan nå. Skriv sedan ned hur varje nod får veta om ändringar, och hur snabbt.

En delad databas är en möjlig komponent i det svaret. Det är inte bevis för att varje relevant policy bor där, eller att varje nod tillämpar en ändring i samma ögonblick. Ett konto som inaktiverats på nod A men fortfarande accepteras på nod B betyder att avslutningsprocessen inte är klar.

Bestäm vad en nod gör när auktoriteten inte går att nå. Att acceptera cachade inloggningsuppgifter under ett avbrott är ett policyval med en säkerhetskostnad, och att avvisa dem är ett policyval med en tillgänglighetskostnad. Båda är försvarbara; att lämna det odokumenterat är det inte.

Håll utfärdarens auktoritet åtskild från kontodata. Flera gateways kan lita på samma CA utan att inneha dess signeringsnyckel, och varje nod behöver fortfarande sitt eget servercertifikat och sin egen tillitsrelation på klientsidan.

Vad en nod äger: adresser och rutter

Det andra registret är lokalt för varje nod: lyssnaradress, serveridentitet, adresspool, rutter till privata resurser, resolverpolicy och hur trafiken lämnar mot internet. Samma konto kan betjänas av vilken som helst av de två noderna medan dessa objekt förblir åtskilda.

Returvägen är den del som glöms bort. Om båda noderna delar ut adresser från samma pool kan det privata nätverket inte avgöra vilken nod en viss klient tillhör, och svaret kan skickas till fel ställe. Olika pooler behöver också rutter och behörigheter, så ett eget nummerområde är inte en fullständig design.

Skicka klienter till en nod med avsikt. DNS-val, listor över klientändpunkter och en frontend-tjänst är olika mekanismer med olika beteende för hälsa och redundans. Att välja en är okej; att behandla ”lastbalansering” som designen lämnar returvägen och felbeteendet odefinierade.

Ett dokumenterat produktexempel hjälper här. Pritunls replikeringsdokumentation behandlar VPN-nätverket som ett objekt per replika, och klienter på olika repliker behöver extra rutter och anslutning för att nå varandra. Det är en produktspecifik ordning, inte ett recept för Community OpenVPN, men den visar varför ett tillägg av en replika ändrar nätverket och inte bara kontolagret.

Vad en session är: levande tillstånd, inte en rad

Det tredje registret är den levande sessionen. En ansluten klient har protokolltillstånd och en nätverkstilldelning på noden som accepterade den. Att kontot är känt på den andra noden ger inte den noden sessionen, nycklarna eller förmågan att fortsätta paketen.

Var tydlig med vad som händer när en nod fallerar. Det stödda utfallet kan vara en återanslutning till den andra noden med färsk autentisering och en ny adress, varefter applikationen återhämtar sig på sitt eget sätt. Om oavbruten överlämning krävs behöver det kravet uttryckligt implementeringsstöd, inte en slutsats från databasreplikering. Skriv ned svaret där jourhavande ingenjör kan hitta det.

Kapacitetsregler behöver samma behandling. En gräns på två samtidiga sessioner per konto kan bara upprätthållas mellan noder om någon auktoritet har en samordnad bild av upptagna platser. Nodlokala listor och en historisk kontopost summerar inte till den bilden.

Pröva de tre registren

Öva var och en separat. Logga in via nod A, sedan via nod B, och bekräfta att båda lyckas med de förväntade adressområdena. Dra tillbaka en identitet och kontrollera båda noderna, inte bara den du råkade testa. Stoppa sedan en nod och observera vad klienten och den privata applikationen faktiskt gör.

Ta med returvägen i acceptanstestet. En klient som ansluter till B men inte kan ta emot svar från en resurs bakom A har klarat åtkomstkontrollen och misslyckats med nätverkskontrollen, och den skillnaden bör framgå av rapporten.

Fler-nod-kontodesignen är först komplett när alla tre registren har en uttrycklig ägare, en ändringsväg och ett felbeteende. Att kopiera en konfigurationsfil mellan noder besvarar ingen av dessa frågor.