Escurçar el temporitzador DPD no farà més ràpid el basculament de VPN

Els túnels cauen, la recuperació triga noranta segons i el temporitzador de parell mort està fixat en deu, així que es culpa el temporitzador. Aquest raonament salta tres etapes que passen després de la detecció i que normalment consumeixen la major part del temps. La detecció de vivacitat nota el silenci; després la selecció de parell, l’autenticació, la instal·lació de rutes i la reconnexió de l’aplicació prenen el seu torn. Escurçar la primera etapa no pot escurçar les altres, i pot afegir agitació a un sistema que ja anava malament.

Quatre etapes, una de les quals podeu cronometrar

Escriviu la recuperació com quatre esdeveniments amb marques de temps. La fallada es fa observable: l’últim trànsit protegit útil i la primera petició fallida. El mecanisme responsable reacciona: detecció de vivacitat, un monitor de ruta o un altre desencadenant documentat. L’alternativa es fa utilitzable: selecció de parell, autenticació, una associació nova i una ruta que realment porta el trànsit previst. L’aplicació es recupera: una operació nova té èxit i el que estava en curs té un resultat definit.

Les regles de vivacitat d’IKEv2 descriuen proves sobre el parell i els seus intercanvis, i no diuen res sobre una base de dades o un servei de fitxers darrere d’aquest parell. Llegir un temps d’espera de vivacitat com una comprovació de salut de tot el camí és l’error que comença la caça del temporitzador.

Per què el temporitzador és el número menys interessant

Els valors configurats no són unitats intercanviables. Alguns són intervals de reintent, alguns són límits superiors d’un intent i alguns s’executen alhora que altres. Sumar-los produeix un número que sembla una predicció i es comporta com un rumor. Llegiu la documentació del camp que esteu a punt de tocar i fixeu-vos en quin dels tres tipus és.

Altres etapes no són temporitzadors en absolut. Un retrocés de reconnexió, una sol·licitud d’autenticació interactiva o un client que només reavalua la seva configuració en reiniciar-se poden dominar cadascun la interrupció mentre tots els temporitzadors del protocol estan còmodament baixos.

Mesureu l’etapa que és realment lenta

Captureu la fallada una vegada, amb marques de temps als dos costats, i després compareu els quatre esdeveniments en lloc dels comptadors propis del protocol. Una finestra d’observació ben feta val més que un mes d’ajustaments.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Si el punt final alternatiu no respon mai, cap canvi de temporitzador ajuda, perquè la inabastabilitat no és un problema de detecció. Si l’estat de seguretat nou es forma ràpidament però la ruta encara apunta al camí mort, el problema és la instal·lació de la ruta i un altre retoc de vivacitat només afegeix agitació.

L’alternativa ha d’estar ja utilitzable

Una còpia de seguretat definida en una configuració no és una còpia de seguretat que funcioni. Ha de ser abastable des de la xarxa actual del client, capaç d’autenticar la mateixa identitat i autoritzada a portar el mateix trànsit sota la mateixa política. Descobriu qualsevol d’aquestes tres mancances durant una interrupció i la discussió del temporitzador es torna irrellevant. Prova l’alternativa mentre la primària està sana, perquè és l’únic moment en què pots llegir els dos registres costat a costat.

Preprovisiona l’alternativa, prova-la deliberadament mentre la primària està sana i registra quina de les quatre etapes consumeix el temps. Aquest registre és el que fa que el canvi següent sigui un mesurament en lloc d’una conjectura.

Agitació de retorn i el camí de gestió

Restaurar la primària és una decisió separada. Un retorn agressiu pot interrompre feina que ja s’havia recuperat a la còpia de seguretat, i un camí inestable pot semblar un túnel inestable quan la fallada real és una ruta que oscil·la entre dues opcions iguals.

Dos camins d’igual cost sense preferència són la font habitual de l’oscil·lació visible, perquè cada monitor reacciona a l’elecció de l’altre. Decidiu quin camí és preferent en condicions normals i feu aquesta preferència explícita a la configuració en lloc de deixar-la a l’ordre de les rutes. Definiu el comportament de retorn desitjat i qui en és responsable, per endavant. Manteniu la configuració anterior i un camí de gestió independent, perquè un canvi que us treu el vostre propi accés durant una interrupció converteix un incident de xarxa en una visita al lloc.

Després repetiu la mateixa càrrega de treball i compareu les mateixes quatre marques de temps. Una recuperació més curta que encara deixa l’aplicació esperant la mateixa ruta o inici de sessió que falta no és progrés, és un número diferent al mateix gràfic.