Conmutació per error de VPN: quan el camí de tornada es queda al túnel vell

El túnel de reserva s’aixeca, el primari cau i l’aplicació continua esgotant el temps d’espera. Als dos llocs l’estat del túnel sembla saludable, i això és el que confon. Una conmutació que mou les peticions a la reserva però deixa les respostes al camí vell no és una conmutació. La guia de sota prova el camí de tornada, no només l’establiment inicial.

Primer anoteu les rutes als dos extrems; una visió d’un sol lloc no pot mostrar un camí asimètric. També és el pas que més sovint s’omet sota pressió de temps.

Anoteu les rutes dels dos llocs abans de la prova

Per a cada prefix protegit, escriviu la ruta primària, la ruta de reserva i la preferència que tria entre elles. Incloeu la passarel·la LAN darrere de cada extrem de VPN, perquè l’extrem poques vegades és l’últim salt.

Les mètriques estàtiques, les rutes seguides i l’encaminament dinàmic expressen l’elegibilitat de maneres diferents. Sapigueu quin fa servir el vostre disseny i què cal perquè l’alternativa esdevingui activa. Escriviu la condició al costat de la ruta, per exemple una mètrica més baixa fins que la sonda falli.

Feu-ho als dos llocs. Una reserva preferida en un costat i ignorada a l’altre produeix exactament l’asimetria que intenteu evitar.

Observeu les peticions i les respostes a cada fase

Feu servir una aplicació permesa i inofensiva i observeu tres fases: normal, fallada del primari i restauració. A cada fase, anoteu quin túnel porta la petició i quin porta la resposta. Una adreça de parell accessible no demostra que el camí protegit de l’aplicació funcioni. Captureu-ho als dos llocs perquè es vegi un flux unidireccional.

Si les peticions es mouen i les respostes no, comproveu la ruta del lloc remot cap al prefix del client i la seva preferència per la reserva. Això és una decisió d’encaminament, no una fallada del túnel.

Restaureu la condició original després de la prova i confirmeu que el primari torna a ser preferit. Un primari restaurat que no és preferit és un disseny de conmutació que no s’ha acabat.

Gestioneu l’estat de la sessió quan canvia la passarel·la

Els tallafocs i el NAT poden mantenir l’estat de la connexió en una passarel·la, i un canvi de camí cap a una altra passarel·la no el transporta. Algunes aplicacions es reconnecten soles; d’altres fallen fins que es restableix la sessió. Si la reserva canvia la font pública o l’adreça privada traduïda, les regles d’accés remot també poden reaccionar. Documenteu qualsevol reinici de sessió esperat en lloc de prometre una conmutació sense interrupcions.

Manteniu un adreçament estable allà on l’aplicació ho requereixi. Un disseny de conmutació que canvia l’adreça d’origen a cada sessió és una decisió de disseny, i s’ha d’escriure. Aquesta decisió determina quanta interrupció noten realment els usuaris.

Proveu una aplicació que mantingui una sessió llarga, no només una petició nova.

Restaureu el primari i comproveu si oscil·la

Confirmeu que els anuncis de ruta o les preferències s’estabilitzen sense oscil·lar. Un primari que oscil·la pot ser més pertorbador que una caiguda clara, perquè cada transició reinicia l’estat.

Manteniu l’administració de la passarel·la accessible per un camí de recuperació perquè la prova no us deixi fora. Anoteu les fases, els camins observats i el temps de recuperació; aquest registre és el que fa previsible la propera conmutació. Les notes de strongSwan sobre reenviament són útils quan els extrems són amfitrions Linux.