Eén VPN-account op twee servers: drie toestandsregisters

Eén account dat op elk van twee VPN-nodes kan inloggen, werpt een ontwerpvraag op lang voordat het een softwarevraag wordt. De accountweergave, het netwerk dat elke node bezit en de sessie die een verbonden client vasthoudt, zijn drie verschillende soorten toestand, en ze falen op verschillende manieren wanneer u ze rondkopieert. Alle drie in één systeem kopiëren is een veelvoorkomende manier om er één kwijt te raken.

Werk de drie registers hieronder in volgorde door. Elk vraagt wat gezaghebbend is, wat lokaal is en wat er gebeurt als de andere node weg is, en de antwoorden volgen niet uit elkaar.

Wie mag verbinden: één autoriteit, veel nodes

Begin met het toelatingsregister: welke identiteitsbron gezaghebbend is, welke certificaatuitgevers vertrouwd worden, welke accounts in aanmerking komen, welke tweede factor geldt en wat elk account kan bereiken. Schrijf daarna op hoe elke node van wijzigingen leert, en hoe snel.

Een gedeelde database is één mogelijk onderdeel van dat antwoord. Het is geen bewijs dat elk relevant beleid daar woont, of dat elke node een wijziging op hetzelfde moment toepast. Een account dat op node A is uitgeschakeld maar op node B nog wordt geaccepteerd, betekent dat het offboardingproces niet is afgerond.

Bepaal wat een node doet wanneer de autoriteit onbereikbaar is. Gecachte inloggegevens tijdens een storing accepteren is een beleidskeuze met een beveiligingskostenpost, en ze weigeren is een beleidskeuze met een beschikbaarheidskostenpost. Beide zijn verdedigbaar; het ongedocumenteerd laten niet.

Houd de uitgeversautoriteit ook gescheiden van accountgegevens. Meerdere gateways kunnen hetzelfde CA vertrouwen zonder de ondertekeningssleutel te bezitten, en elke node heeft nog steeds zijn eigen servercertificaat en zijn eigen vertrouwensrelatie aan de clientzijde nodig.

Wat een node bezit: adressen en routes

Het tweede register is lokaal voor elke node: luisteradres, serveridentiteit, adrespool, routes naar privébronnen, resolverbeleid en hoe verkeer naar het internet vertrekt. Hetzelfde account kan door elk van beide nodes worden bediend terwijl deze objecten gescheiden blijven.

De retourweg is het deel dat wordt vergeten. Als beide nodes adressen uit dezelfde pool uitgeven, kan het privénetwerk niet zeggen welke node een bepaalde client bezit, en het antwoord kan op de verkeerde plek terechtkomen. Verschillende pools hebben ook routes en machtigingen nodig, dus een apart nummerbereik is geen volledig ontwerp.

Stuur clients bewust naar één node. DNS-keuze, lijsten met cliënteindpunten en een front-endservice zijn verschillende mechanismen met ander gedrag voor gezondheid en failover. Er één kiezen is prima; “load balancing” als het ontwerp behandelen laat de retourweg en het faalgedrag ongedefinieerd.

Een gedocumenteerd productvoorbeeld helpt hier. De replicatiedocumentatie van Pritunl behandelt het VPN-netwerk als een object per replica, en clients op verschillende replica’s hebben extra routes en connectiviteit nodig om elkaar te bereiken. Dat is een productspecifieke regeling, geen recept voor Community OpenVPN, maar het laat zien waarom het toevoegen van een replica het netwerk verandert en niet alleen het accountarchief.

Wat een sessie is: levende toestand, geen rij

Het derde register is de live sessie. Een verbonden client heeft protocolstatus en een netwerktoewijzing op de node die hem heeft geaccepteerd. Dat het account op de andere node bekend is, geeft die node de sessie, de sleutels of het vermogen om de pakketten voort te zetten niet.

Wees expliciet over wat er gebeurt als een node uitvalt. De ondersteunde uitkomst kan een herverbinding met de andere node zijn met verse authenticatie en een nieuw adres, waarna de applicatie op zijn eigen manier herstelt. Als ononderbroken overdracht vereist is, heeft die eis expliciete implementatieondersteuning nodig, geen gevolgtrekking uit databasereplicatie. Schrijf het antwoord op waar de dienstdoende ingenieur het kan vinden.

Capaciteitsregels hebben dezelfde behandeling nodig. Een limiet van twee gelijktijdige sessies per account kan alleen over nodes worden gehandhaafd als een of andere autoriteit een gecoördineerd beeld van bezette plaatsen heeft. Node-lokale lijsten en een historisch accountrecord tellen niet op tot dat beeld.

De drie registers beproeven

Oefen elk apart. Log in via node A, dan via node B, en bevestig dat beide slagen met de verwachte adresbereiken. Trek een identiteit in en controleer beide nodes, niet alleen degene die u toevallig testte. Stop daarna één node en observeer wat de client en de privéapplicatie werkelijk doen.

Neem de retourweg op in de acceptatietest. Een client die met B verbindt maar geen antwoorden kan ontvangen van een bron achter A, is geslaagd voor de toelatingscontrole en gezakt voor de netwerkcontrole, en dat onderscheid hoort in het rapport te staan.

Pas als alle drie de registers een expliciete eigenaar, een wijzigingspad en een faalgedrag hebben, is het accountontwerp voor meerdere nodes compleet. Een configuratiebestand over nodes kopiëren beantwoordt geen van die vragen.