Un compte VPN en dos servidors: tres llibres de registre d’estat

Un compte que pot iniciar sessió a qualsevol de dos nodes VPN planteja una pregunta de disseny molt abans de plantejar una pregunta de programari. La visió del compte, la xarxa que posseeix cada node i la sessió que manté un client connectat són tres tipus diferents d’estat, i fallen de maneres diferents quan els copieu d’un lloc a l’altre. Copiar els tres en un sol sistema és una manera habitual de perdre’n un.

Recorregueu els tres llibres de registre següents en ordre. Cadascun pregunta què és autoritatiu, què és local i què passa quan l’altre node no hi és, i les respostes no es dedueixen les unes de les altres.

Qui es pot connectar: una autoritat, molts nodes

Comenceu pel llibre d’admissió: quina font d’identitat és autoritativa, quins emissors de certificats són de confiança, quins comptes són elegibles, quin segon factor s’aplica i a què pot arribar cada compte. Després anoteu com cada node s’assabenta dels canvis i amb quina rapidesa.

Una base de dades compartida és un component possible d’aquesta resposta. No és una prova que tota la política rellevant visqui allà ni que cada node apliqui un canvi en el mateix moment. Un compte desactivat al node A però encara acceptat al node B significa que el procés de baixa no ha acabat.

Decidiu què fa un node quan l’autoritat no és accessible. Acceptar credencials en memòria cau durant una caiguda és una decisió de política amb un cost de seguretat, i rebutjar-les és una decisió de política amb un cost de disponibilitat. Totes dues són defensables; deixar-ho sense documentar no ho és.

Manteniu l’autoritat de l’emissor separada de les dades del compte. Diverses passarel·les poden confiar en la mateixa CA sense tenir-ne la clau de signatura, i cada node encara necessita el seu propi certificat de servidor i la seva pròpia relació de confiança al costat del client.

Què posseeix un node: adreces i rutes

El segon llibre de registre és local de cada node: adreça d’escolta, identitat del servidor, pool d’adreces, rutes cap a recursos privats, política del resolutor i com surt el trànsit cap a internet. El mateix compte pot ser atès per qualsevol dels dos nodes mentre aquests objectes segueixen sent diferents.

El camí de tornada és la part que s’oblida. Si els dos nodes reparteixen adreces del mateix pool, la xarxa privada no pot saber a quin node pertany un client determinat i la resposta pot anar al lloc equivocat. Els pools diferents també necessiten rutes i permisos, així que un rang de números diferent no és un disseny complet.

Adreceu els clients a un node deliberadament. La selecció de DNS, les llistes de punts finals del client i un servei de frontal són mecanismes diferents amb comportaments diferents de salut i de commutació per fallada. Triar-ne un està bé; tractar el «balanceig de càrrega» com el disseny deixa el camí de tornada i el comportament de fallada indefinits.

Un exemple de producte documentat ajuda aquí. La documentació de replicació de Pritunl tracta la xarxa VPN com un objecte per rèplica, i els clients de rèpliques diferents necessiten rutes i connectivitat addicionals per arribar els uns als altres. És un arranjament específic del producte, no una recepta per a Community OpenVPN, però mostra per què afegir una rèplica canvia la xarxa i no només el magatzem de comptes.

Què és una sessió: estat viu, no una fila

El tercer llibre de registre és la sessió viva. Un client connectat té estat de protocol i una assignació de xarxa al node que l’ha acceptat. El fet que el compte sigui conegut a l’altre node no dóna a aquest node la sessió, les claus ni la capacitat de continuar els paquets.

Sigueu explícits sobre què passa quan falla un node. El resultat suportat pot ser una reconnexió a l’altre node amb autenticació nova i una adreça nova, després de la qual l’aplicació es recupera a la seva manera. Si cal un traspàs ininterromput, aquest requisit necessita suport explícit a la implementació, no una inferència de la replicació de la base de dades. Escriviu la resposta allà on l’enginyer de guàrdia la pugui trobar.

Les regles de capacitat necessiten el mateix tracte. Un límit de dues sessions simultànies per compte només es pot fer complir entre nodes si alguna autoritat té una visió coordinada de les places ocupades. Les llistes locals de cada node i un registre històric del compte no sumen aquesta visió.

Provar els tres llibres de registre

Exerciteu cadascun per separat. Inicieu sessió pel node A, després pel node B, i confirmeu que tots dos ho aconsegueixen amb els rangs d’adreces esperats. Retireu una identitat i comproveu els dos nodes, no només el que heu provat per casualitat. Després atureu un node i observeu què fan realment el client i l’aplicació privada.

Incloeu el camí de tornada a la prova d’acceptació. Un client que es connecta a B però no pot rebre respostes d’un recurs darrere d’A ha superat la comprovació d’admissió i ha fallat la de xarxa, i aquesta distinció hauria d’aparèixer a l’informe.

El disseny de compte multinode només és complet quan els tres llibres de registre tenen un propietari explícit, un camí de canvi i un comportament de fallada. Copiar un fitxer de configuració entre nodes no respon cap d’aquestes preguntes.