Las respuestas DPD demuestran que el par IKE está vivo, no que sus datos fluyan
Las respuestas de vitalidad, una notificación de relleno y selectores estrechados describen tres cosas distintas. Léalas por separado antes de culpar a una de ellas de un estancamiento.
Los registros de IPsec pueden mostrar respuestas de vitalidad mientras la aplicación que tienen delante se atasca, y ambos hechos pueden ser ciertos a la vez. Una respuesta DPD establece que el procesamiento IKE del par respondió en ese momento; no dice nada sobre si la SA hija transporta el paquete que le importa. Tratar cada advertencia cerca de una avería como su causa es como un problema de selector acaba diagnosticado como un error de protocolo. Hay tres observaciones que se confunden con más frecuencia, y responden a tres preguntas distintas. Léalas por asociación y propósito antes de leerlas por marca de tiempo.
Qué demuestra cada observación
La tabla separa lo que establece cada observación de lo que solo acompaña.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Ninguna de las tres es un error por sí misma. Cada una se vuelve interesante solo junto al flujo que está depurando, y una fila que no puede ligarse a un flujo concreto es contexto, no evidencia.
La vitalidad no es la salud de los datos
DPD se ejecuta como un intercambio INFORMATIONAL, una conversación de plano de control entre demonios IKE. Una respuesta demuestra que el proceso IKE del par es accesible y está dispuesto a responder, y un tiempo de espera demuestra que no lo está. Ninguno de los dos resultados prueba la SA hija, los selectores, la ruta de reenvío ni la respuesta de la aplicación, así que un DPD sano junto a una transferencia atascada es una imagen coherente, no una contradicción.
Por eso las líneas de vitalidad son la parte menos útil de un ticket de plano de datos, por tranquilizadoras que parezcan en la parte superior del registro.
La notificación de relleno es una afirmación sobre el relleno
El relleno TFC es la línea más sobreleída de estos registros. Dice que el relleno de confidencialidad del flujo de tráfico no se aceptará para esa SA hija, lo cual es una afirmación sobre una función de relleno opcional y no un rechazo de la protección ESP. Encontrarla cerca de un fallo suele ser una coincidencia de verbosidad, y activar o desactivar el relleno no cambia nada en la cobertura de los selectores.
La especificación IKEv2 define tanto la notificación como la negociación de selectores, y la etiqueta de advertencia de una implementación no sustituye el significado del protocolo en ninguno de los dos casos.
El estrechamiento es más silencioso y más probable que importe
Un respondedor puede aceptar un subconjunto de los selectores ofrecidos, y el conjunto aceptado puede imprimirse en varias entradas, una cualificada por puerto y otra que cubre todos los puertos. Leer solo la primera línea cualificada por puerto subestima lo aceptado; leer solo la línea amplia lo sobreestima. Compare la propuesta impresa con la política instalada, porque la propuesta es lo que dijeron los pares y la política es lo que el núcleo hará coincidir. Cuando no coinciden, el túnel existe y el tráfico no, que es la clásica queja intermitente. Invierta la perspectiva local y remota al comparar pares, ya que lo local de cada lado es lo remoto del otro.
Las entradas específicas de host con restricción de puerto merecen una segunda lectura, porque son las que excluyen ICMP o un segundo puerto mientras dejan funcionando un ping a la puerta de enlace.
Construya un registro para el flujo que falla
Registre origen, destino, familia de direcciones, protocolo y puerto tal como se ven en la decisión de protección, incluida cualquier traducción deliberada. Esos son los valores que deben coincidir con un selector, y también son los valores que la gente vuelve a teclear de memoria cuando el ticket llega a un tercer par de manos.
Después, identifique la SA hija y sus contadores direccionales: swanctl --list-sas da el resumen de la asociación en un host strongSwan, y ip -s xfrm state da los contadores. Léalos tras una petición permitida reciente y no mientras el sistema está inactivo. Ningún aumento de salida apunta a la selección o a la ruta local; la salida sin una entrada correspondiente apunta al par, a su reenvío o a sus respuestas.
Un intercambio de aplicación completado supera a cualquiera de los contadores, por eso la prueba debe terminar en la aplicación y no en el indicador del túnel.
Elija la corrección después
Solo cuando ese registro existe hay una corrección que elegir: selectores aceptados, ruta, filtrado, implementación del par o un límite que ahora ha demostrado. Reiniciar el par cambia varios estados a la vez y a menudo restaura el tráfico sin explicar cuál estaba mal, así que la avería vuelve. Mantenga los volcados de estado del núcleo fuera de los tickets, porque pueden contener claves y el resumen estrecho basta para cualquiera que necesite ayudar.
Cuando el registro contradiga su primera teoría, crea al registro y reescriba la teoría; ese hábito vale más que cualquier línea de registro concreta de las aquí tratadas.