Dúas pasarelas IPsec sen IP compartida: que fai realmente o failover

Mata a pasarela A durante unha reunión e observa como o túnel volve por B un minuto despois; a conexión funciona, a videollamada quizais non. Esa é a forma honesta da conmutación en frío entre dúas pasarelas IPsec con enderezos independentes. O cliente volve elixir un extremo e constrúe unha relación nova, o que restaura a alcanzabilidade sen transferir o estado criptográfico da sesión antiga. Percorrer a secuencia deixa claro que promesas pode cumprir o deseño.

Preparemos a escena: dous enderezos, ningunha IP flotante

A pasarela A responde nun enderezo accesible e a pasarela B noutro. O cliente ten unha forma aprobada de elixir B cando A desaparece, e non hai ningún enderezo exterior compartido que ambas as pasarelas reclamen. Neste deseño, unha IP virtual significa ese punto de entrada compartido, non o enderezo interno asignado a un cliente de acceso remoto.

Esa definición importa porque as dúas ideas mestúranse nos tickets, e a solución dunha non é a solución da outra. Un informe de que a entrada compartida non seguiu a pasarela describe un deseño. Un informe de que o portátil perdeu o seu enderezo interno describe o arrendamento do cliente. Distintos propietarios, distintos rexistros, distintas reparacións.

Percorramos o fallo: detectar e despois volver elixir

Primeiro algo decátase de que A deixou de responder. Pode ser a detección de par morto na capa de túnel, un protocolo de encamiñamento que retira unha ruta, ou un tempo de espera de aplicación que por fin forza unha reconexión. Cada un ten unha escala temporal distinta, e o máis lento adoita determinar canto esperan os usuarios.

Despois o cliente selecciona B mediante o mecanismo que admita o despregamento: un segundo remoto configurado, un nome DNS resolto a un enderezo san, ou encamiñamento que agora prefire outra ruta. A selección é un paso de política, e debe existir antes do fallo ou sucederá por accidente.

Que pode herdar B e que non

B pode compartir con A un modelo de configuración, unha autoridade de certificación e unha política de autenticación. Non pode herdar as asociacións de seguridade vivas. As claves de sesión, os índices de parámetros de seguridade e o estado de secuencia pertencen á relación que estableceron A e o cliente, e B non ten ningún.

Mover ese estado entre pasarelas é un problema real de enxeñería, por iso a documentación de alta dispoñibilidade de strongSwan o trata como un deseño de clúster e non como un indicador de configuración. Unha receita concreta de clúster non é unha resposta xenérica para unha rede na nube, e copiala sen a infraestrutura de apoio compra complexidade en lugar de continuidade.

Establecer unha relación nova

Con B elixida, o cliente realiza un intercambio IKE novo: novos nonces, novos valores Diffie-Hellman, novos identificadores para as asociacións resultantes. A autenticación ocorre de novo en B. Se o deseño se apoia en credenciais de máquina, a reconexión pode ser desatendida; se esixe un factor humano, alguén ten que estar presente para que a conmutación se complete.

Defina esa experiencia de usuario antes da interrupción, non durante ela. Diga con claridade que fará o cliente, canto intentará e que mostrará cando se renda, porque a diferenza entre un minuto de reconexión e unha chamada ao soporte adoita ser documentación e un perfil probado.

Conservar o mesmo enderezo interno axuda ás aplicacións que esperan unha identidade local estable, e non conserva as súas sesións. As vinculacións NAT caducan, as conexións TCP reinícianse e calquera cousa co seu propio tempo de espera decide pola súa conta se reintentar.

Dous túneles en paralelo son un deseño distinto

Executar ambos os túneles á vez é un patrón válido cando o admiten as dúas pasarelas e o deseño de encamiñamento. Entón a selección de ruta elixe o camiño activo, e o camiño de volta debe coincidir, ou o tráfico sae por unha pasarela e volve pola outra sen estado que o emparelle.

As políticas de túnel solapadas non crean por si soas unha conmutación ordenada. Crean dous candidatos, e algo debe decidir entre eles de forma determinista, sexa unha métrica de encamiñamento, unha prioridade de política ou unha preferencia explícita no cliente.

Elixa a forma que elixa, escriba o contrato: como se detecta o fallo, como se selecciona o alternativo, que autenticación esixe e canto se prevé que tarde a reconexión. Unha IP compartida pode simplificar o descubrimento, pero non é sinónimo de estado continuo, e a dispoñibilidade é un deseño en calquera caso.