Conmutación por fallo de VPN: cando o camiño de volta queda no túnel vello

O túnel de reserva sobe, o primario cae e a aplicación segue esgotando o tempo de espera. Nos dous sitios o estado do túnel parece saudable, e iso é o que confunde. Unha conmutación que move as peticións á reserva pero deixa as respostas no camiño vello non é unha conmutación. A guía de abaixo proba o camiño de volta, non só o saúdo inicial.

Rexistre primeiro as rutas nos dous extremos; unha vista dun só sitio non pode mostrar un camiño asimétrico. Tamén é o paso que máis se omite baixo presión de tempo.

Rexistre as rutas dos dous sitios antes da proba

Para cada prefixo protexido, escriba a ruta primaria, a ruta de reserva e a preferencia que escolle entre elas. Inclúa a pasarela LAN detrás de cada extremo de VPN, porque o extremo raramente é o último salto.

As métricas estáticas, as rutas seguidas e o encamiñamento dinámico expresan a elixibilidade de formas distintas. Saiba cal usa o seu deseño e que fai falta para que a alternativa se volva activa. Escriba a condición xunto á ruta, por exemplo unha métrica máis baixa ata que falle a sonda.

Fágao nos dous sitios. Unha reserva preferida nun lado e ignorada no outro produce exactamente a asimetría que intenta evitar.

Observe as peticións e as respostas en cada fase

Use unha aplicación permitida e inofensiva e observe tres fases: normal, fallo do primario e restauración. En cada fase, rexistre que túnel leva a petición e cal leva a resposta. Un enderezo de par accesible non demostra que o camiño protexido da aplicación funcione. Capture nos dous sitios para que se vexa un fluxo unidireccional.

Se as peticións se moven e as respostas non, comprobe a ruta do sitio remoto cara ao prefixo do cliente e a súa preferencia pola reserva. Iso é unha decisión de encamiñamento, non un fallo do túnel.

Restaure a condición orixinal despois da proba e confirme que o primario volve ser preferido. Un primario restaurado que non é preferido é un deseño de conmutación que non rematou.

Xestione o estado da sesión cando cambia a pasarela

Os devasas e o NAT poden manter o estado da conexión nunha pasarela, e un cambio de camiño a outra pasarela non o transporta. Algunhas aplicacións reconéctanse soas; outras fallan ata que se restablece a sesión. Se a reserva cambia a fonte pública ou o enderezo privado traducido, as regras de acceso remoto tamén poden reaccionar. Documente calquera reinicio de sesión esperado en lugar de prometer unha conmutación sen interrupcións.

Manteña un enderezo estable onde a aplicación o esixa. Un deseño de conmutación que cambia o enderezo de orixe en cada sesión é unha decisión de deseño, e debería escribirse. Esa decisión determina canta parte da interrupción notan realmente os usuarios.

Probe unha aplicación que manteña unha sesión longa, non só unha petición nova.

Restaure o primario e comprobe se oscila

Confirme que os anuncios de ruta ou as preferencias se estabilizan sen oscilar. Un primario que oscila pode ser máis perturbador que unha caída clara, porque cada transición reinicia o estado.

Manteña a administración da pasarela accesible mediante un camiño de recuperación para que a propia proba non o deixe fóra. Rexistre as fases, os camiños observados e o tempo de recuperación; ese rexistro é o que fai previsible a seguinte conmutación. As notas de strongSwan sobre o reenvío son útiles cando os extremos son hosts Linux.