Dues passarel·les IPsec, cap IP compartida: què fa realment la commutació per error

Atureu la passarel·la A durant una reunió i observeu com el túnel torna per B un minut després; la connexió funciona, la videotrucada potser no. Aquesta és la forma honesta de la commutació en fred entre dues passarel·les IPsec amb adreces independents. El client torna a triar un punt final i construeix una relació nova, cosa que restaura l’abast sense transferir l’estat criptogràfic de la sessió antiga. Recórrer la seqüència fa evident quines promeses pot complir el disseny.

Preparem l’escena: dues adreces, cap IP flotant

La passarel·la A respon en una adreça accessible i la passarel·la B en una altra. El client té una manera aprovada de triar B quan A desapareix, i no hi ha cap adreça exterior compartida que ambdues passarel·les reivindiquin. En aquest disseny, una IP virtual significa aquest punt d’entrada compartit, no l’adreça interna assignada a un client d’accés remot.

Aquesta definició importa perquè les dues idees es barregen als tiquets, i la solució d’una no és la solució de l’altra. Un informe que diu que l’entrada compartida no va seguir la passarel·la descriu un disseny. Un informe que diu que l’ordinador portàtil va perdre l’adreça interna descriu el lloguer del client. Propietaris diferents, registres diferents, reparacions diferents.

Recorrem la fallada: detectar i després tornar a triar

Primer alguna cosa nota que A ha deixat de respondre. Pot ser la detecció de parell mort a la capa de túnel, un protocol d’encaminament que retira un camí, o un temps d’espera d’aplicació que finalment força una reconnexió. Cadascun té una escala temporal diferent, i el més lent sol determinar quant esperen els usuaris.

Després el client tria B mitjançant el mecanisme que admeti el desplegament: un segon remot configurat, un nom DNS resolt a una adreça saludable, o encaminament que ara prefereix un camí diferent. La selecció és un pas de política, i ha d’existir abans de la fallada o passarà per accident.

Què pot heretar B i què no

B pot compartir amb A una plantilla de configuració, una autoritat de certificació i una política d’autenticació. No pot heretar les associacions de seguretat vives. Les claus de sessió, els índexs de paràmetres de seguretat i l’estat de seqüència pertanyen a la relació que A i el client van establir, i B no en té cap.

Moure aquest estat entre passarel·les és un problema real d’enginyeria, i per això la documentació d’alta disponibilitat de strongSwan ho tracta com un disseny de clúster i no com un indicador de configuració. Una recepta concreta de clúster no és una resposta genèrica per a una xarxa de núvol, i copiar-la sense la infraestructura de suport compra complexitat en lloc de continuïtat.

Establir una relació nova

Amb B triada, el client fa un intercanvi IKE nou: valors nonce nous, valors Diffie-Hellman nous, identificadors nous per a les associacions resultants. L’autenticació torna a passar a B. Si el disseny es basa en credencials de màquina, la reconnexió pot ser sense supervisió; si requereix un factor humà, algú ha de ser present perquè la commutació es completi.

Definiu aquesta experiència d’usuari abans de la interrupció, no durant. Digueu clarament què farà el client, quant de temps ho intentarà i què mostrarà quan es rendeixi, perquè la diferència entre un minut de reconnexió i una trucada a suport sol ser documentació i un perfil provat.

Conservar la mateixa adreça interna ajuda les aplicacions que esperen una identitat local estable, però no conserva les seves sessions. Les vinculacions NAT caduquen, les connexions TCP es reinicien i qualsevol cosa amb el seu propi temps d’espera decideix independentment si reintentar.

Dos túnels en paral·lel són un disseny diferent

Executar tots dos túnels alhora és un patró vàlid quan ambdues passarel·les i el disseny d’encaminament ho admeten. Llavors la selecció de ruta tria el camí actiu, i el camí de tornada ha de coincidir, o el trànsit surt per una passarel·la i torna per l’altra sense estat que el casi.

Les polítiques de túnel superposades no creen per si soles una commutació ordenada. Creen dos candidats, i alguna cosa ha de decidir entre ells de manera determinista, sigui una mètrica d’encaminament, una prioritat de política o una preferència explícita al client.

Sigui quina sigui la forma que trieu, escriviu el contracte: com es detecta la fallada, com es tria l’alternativa, quina autenticació exigeix i quant es preveu que trigui la reconnexió. Una IP compartida pot simplificar el descobriment, però no és sinònim d’estat continu, i la disponibilitat és un disseny en qualsevol cas.