As respostas DPD demostran que o par IKE está vivo, non que os seus datos flúan
As respostas de vitalidade, unha notificación de recheo e selectores estreitados describen tres cousas distintas. Lémolas por separado antes de culpar unha delas dun estancamento.
Os rexistros de IPsec poden amosar respostas de vitalidade mentres a aplicación que teñen diante se atasca, e ambos os feitos poden ser certos ao mesmo tempo. Unha resposta DPD establece que o procesamento IKE do par respondeu nese momento; non di nada sobre se a SA filla transporta o paquete que lle importa. Tratar cada advertencia preto dunha avaría como a súa causa é como un problema de selector acaba diagnosticado como un erro de protocolo. Hai tres observacións que se confunden con máis frecuencia, e responden a tres preguntas distintas. Lémolas por asociación e propósito antes de lelas por marca de tempo.
Que demostra cada observación
A táboa separa o que establece cada observación do que só 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 |
Ningunha das tres é un erro por si mesma. Cada unha vólvese interesante só xunto ao fluxo que está depurando, e unha fila que non pode ligarse a un fluxo concreto é contexto, non evidencia.
A vitalidade non é a saúde dos datos
DPD execútase como un intercambio INFORMATIONAL, unha conversación de plano de control entre demos IKE. Unha resposta demostra que o proceso IKE do par é accesible e está disposto a responder, e un tempo de espera demostra que non o está. Ningún dos dous resultados proba a SA filla, os selectores, a ruta de reenvío nin a resposta da aplicación, así que un DPD san xunto a unha transferencia atascada é unha imaxe coherente, non unha contradición.
Por iso as liñas de vitalidade son a parte menos útil dun ticket de plano de datos, por tranquilizadoras que parezan na parte superior do rexistro.
A notificación de recheo é unha afirmación sobre o recheo
O recheo TFC é a liña máis sobrelida destes rexistros. Di que o recheo de confidencialidade do fluxo de tráfico non se aceptará para esa SA filla, o que é unha afirmación sobre unha función de recheo opcional e non un rexeitamento da protección ESP. Atopala preto dun fallo adoita ser unha coincidencia de verbosidade, e activar ou desactivar o recheo non cambia nada na cobertura dos selectores.
A especificación IKEv2 define tanto a notificación como a negociación de selectores, e a etiqueta de advertencia dunha implementación non substitúe o significado do protocolo en ningún dos dous casos.
O estreitamento é máis silencioso e máis probable que importe
Un respondedor pode aceptar un subconxunto dos selectores ofrecidos, e o conxunto aceptado pode imprimirse en varias entradas, unha cualificada por porto e outra que cobre todos os portos. Ler só a primeira liña cualificada por porto subestima o aceptado; ler só a liña ampla sobreestímao. Compare a proposta impresa coa política instalada, porque a proposta é o que dixeron os pares e a política é o que o núcleo fará coincidir. Cando non coinciden, o túnel existe e o tráfico non, que é a clásica queixa intermitente. Inverta a perspectiva local e remota ao comparar pares, xa que o local de cada lado é o remoto do outro.
As entradas específicas de host con restrición de porto merecen unha segunda lectura, porque son as que exclúen ICMP ou un segundo porto mentres deixan funcionando un ping á pasarela.
Constrúa un rexistro para o fluxo que falla
Rexistre orixe, destino, familia de enderezos, protocolo e porto tal como se ven na decisión de protección, incluída calquera tradución deliberada. Eses son os valores que deben coincidir cun selector, e tamén son os valores que a xente volve teclear de memoria cando o ticket chega a un terceiro par de mans.
Despois, identifique a SA filla e os seus contadores direccionais: swanctl --list-sas dá o resumo da asociación nun host strongSwan, e ip -s xfrm state dá os contadores. Léaos tras unha petición permitida recente e non mentres o sistema está inactivo. Ningún aumento de saída apunta á selección ou á ruta local; a saída sen unha entrada correspondente apunta ao par, ao seu reenvío ou ás súas respostas.
Un intercambio de aplicación completado supera a calquera dos contadores, por iso a proba debe rematar na aplicación e non no indicador do túnel.
Escolla a corrección despois
Só cando ese rexistro existe hai unha corrección que escoller: selectores aceptados, ruta, filtrado, implementación do par ou un límite que agora demostrou. Reiniciar o par cambia varios estados á vez e a miúdo restaura o tráfico sen explicar cal estaba mal, así que a avaría volve. Manteña os volcados de estado do núcleo fóra dos tickets, porque poden conter claves e o resumo estreito abonda para calquera que necesite axudar.
Cando o rexistro contradiga a súa primeira teoría, crea o rexistro e reescriba a teoría; ese hábito vale máis que calquera liña de rexistro concreta das aquí tratadas.