Por que o cifrado por si só non detén un paquete reenviado

Os paquetes protexidos non caducan criptograficamente, así que un que era válido hai cinco minutos segue a ser válido agora, porque o cifrado e a protección de integridade non din nada sobre cando se produciron os bytes. Un atacante que pode capturar e reenviar tráfico non necesita romper o cifrado. Por iso cada protocolo de túnel serio leva estado de secuencia xunto ás súas claves.

O mecanismo é pequeno, e os seus modos de fallo confúndense facilmente coa perda de paquetes.

O texto cifrado válido non é texto cifrado fresco

A autenticación responde a unha pregunta: chegaron estes bytes sen modificar de alguén que posúe a clave. Non responde se é a primeira vez que o receptor os ve. Un paquete reenviado supera perfectamente a primeira proba, e por iso exactamente a comprobación de integridade soa non pode deter un reenvío e o protocolo necesita unha segunda regra sobre a aceptación. Un receptor que só autentica non ten defensa contra un atacante que ten unha gravación.

Esa regra é barata de implementar e barata de enunciar: acepta un paquete protexido dado unha vez, baixo unha clave dada. Todo o demais neste eido deriva de como a implementación segue esa única vez.

Ler un descarte por reenvío como un fallo de descifrado lévao ao subsistema completamente equivocado.

Un número de secuencia e unha xanela

IPsec ESP leva un número de secuencia e o receptor mantén unha xanela deslizante de valores aceptados recentemente, mentres a especificación de ESP describe o tamaño de xanela predeterminado e a opción de amplialo. WireGuard toma outra ruta cun contador por clave e unha comprobación explícita contra el. Ningún dos dous deseños supón que os paquetes cheguen en orde, porque as redes reais reordénanos. Ambos toleran a reordenación, e ningún tolera a repetición.

A xanela é o que fai posible esa tolerancia. Un paquete lixeiramente por detrás do valor máis alto visto aínda pode aceptarse se non se aceptou antes; un moi por detrás, ou un cuxa caixa xa está marcada, descártase. Aumenta a xanela e tolerarás máis reordenación a costa de máis estado por asociación.

Os contadores de diagnóstico móstranche en que caso estás. Os descartes por reenvío incrementan un contador específico en lugar dun erro xenérico, e ler ese contador é a primeira observación útil.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

O estado pertence á clave, non ao host

O estado do contador está ligado a unha asociación de seguridade ou a unha época de clave, así que unha renovación de clave crea un contexto novo e o seu propio espazo de secuencia. Borrar un contador sen substituír a clave, ou reutilizar unha asociación tras un reinicio manual, rompe a suposición da que depende a xanela do receptor. Por iso existe a renovación de claves impulsada polo protocolo en lugar dun botón de reinicio visible para o operador.

Cando un túnel se comporta mal tras unha intervención manual, pregunta se a intervención tocou o estado de secuencia. Unha configuración que parece idéntica pode comportarse distinto porque o estado que herdou non é o estado que espera.

Diagnostica a causa antes de desactivar nada

A perda, a reordenación, o tráfico duplicado e un defecto de implementación maniféstanse todos como retransmisións, e só un é un problema de reenvío. Desactivar a comprobación para silenciar o ruído elimina a propiedade na que confiabas e fai máis difícil atopar a causa orixinal, porque agora as retransmisións non teñen ningunha explicación.

Captura probas limitadas: identificadores de asociación, números de secuencia e contadores, sen as cargas útiles. Iso abonda para distinguir un duplicado dunha chegada reordenada, e non converte o teu ficheiro de diagnóstico nunha copia do tráfico do usuario.

Que non promete a comprobación

A protección contra reenvíos é unha propiedade do procesamento de paquetes dentro dun protocolo. Non significa que o operador non garde rexistros, que un sitio web non poida recoñecer unha conta ou que unha sesión sexa anónima. Son cuestións separadas sobre sistemas separados, e un deseño sólido contra reenvíos non responde a ningunha delas.

O software mantido con axustes compatibles é o control práctico do que dispón un usuario. O protocolo encárgase do paquete; todo o demais segue a ser unha decisión operativa.