As respostas DPD provam que o par IKE está vivo, não que os seus dados fluem
Respostas de vivacidade, uma notificação de preenchimento e seletores estreitados descrevem três coisas diferentes. Leia-as separadamente antes de culpar uma delas por uma paralisação.
Os registos de IPsec podem mostrar respostas de vivacidade enquanto a aplicação à frente deles está parada, e ambos os factos podem ser verdadeiros ao mesmo tempo. Uma resposta DPD estabelece que o processamento IKE do par respondeu naquele momento; não diz nada sobre se a SA filha transporta o pacote que lhe importa. Tratar cada aviso perto de uma falha como a sua causa é como um problema de seletor acaba diagnosticado como um erro de protocolo. Há três observações que se confundem com mais frequência, e respondem a três perguntas diferentes. Leia-as por associação e propósito antes de as ler por marca temporal.
O que cada observação prova
A tabela separa o que cada observação estabelece do que apenas acompanha.
| 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 |
Nenhuma das três é um erro por si só. Cada uma torna-se interessante apenas junto ao fluxo que está a depurar, e uma linha que não pode ser ligada a um fluxo concreto é contexto, não evidência.
A vivacidade não é a saúde dos dados
O DPD é executado como uma troca INFORMATIONAL, uma conversa de plano de controlo entre daemons IKE. Uma resposta prova que o processo IKE do par é acessível e está disposto a responder, e um tempo limite prova que não está. Nenhum dos resultados testa a SA filha, os seletores, o caminho de encaminhamento ou a resposta da aplicação, pelo que um DPD saudável junto a uma transferência parada é uma imagem coerente, não uma contradição.
Por isso as linhas de vivacidade são a parte menos útil de um ticket de plano de dados, por mais tranquilizadoras que pareçam no topo do registo.
A notificação de preenchimento é uma afirmação sobre o preenchimento
O preenchimento TFC é a linha mais sobrelida destes registos. Diz que o preenchimento de confidencialidade do fluxo de tráfego não será aceite para essa SA filha, o que é uma afirmação sobre uma funcionalidade de preenchimento opcional e não uma rejeição da proteção ESP. Encontrá-lo perto de uma falha é habitualmente uma coincidência de verbosidade, e ativar ou desativar o preenchimento não muda nada na cobertura dos seletores.
A especificação IKEv2 define tanto a notificação como a negociação de seletores, e a etiqueta de aviso de uma implementação não substitui o significado do protocolo em nenhum dos dois casos.
O estreitamento é mais silencioso e mais provável de importar
Um respondedor pode aceitar um subconjunto dos seletores oferecidos, e o conjunto aceite pode ser impresso em várias entradas, uma qualificada por porta e outra que cobre todas as portas. Ler apenas a primeira linha qualificada por porta subestima o que foi aceite; ler apenas a linha ampla sobrestima-o. Compare a proposta impressa com a política instalada, porque a proposta é o que os pares disseram e a política é o que o núcleo vai corresponder. Quando não coincidem, o túnel existe e o tráfego não, o que é a clássica queixa intermitente. Inverta a perspetiva local e remota ao comparar pares, uma vez que o local de cada lado é o remoto do outro.
As entradas específicas do anfitrião com restrição de porta merecem uma dupla leitura, porque são as que excluem ICMP ou uma segunda porta enquanto deixam um ping ao gateway a funcionar.
Construa um registo para o fluxo que falha
Registe origem, destino, família de endereços, protocolo e porta tal como são vistos na decisão de proteção, incluindo qualquer tradução deliberada. Esses são os valores que têm de corresponder a um seletor, e também são os valores que as pessoas voltam a escrever de memória quando o ticket chega a um terceiro par de mãos.
Depois, identifique a SA filha e os seus contadores direcionais: swanctl --list-sas dá o resumo da associação num anfitrião strongSwan, e ip -s xfrm state dá os contadores. Leia-os após um pedido permitido recente e não enquanto o sistema está inativo. Nenhum aumento de saída aponta para a seleção ou para o caminho local; a saída sem uma entrada correspondente aponta para o par, o seu encaminhamento ou as suas respostas.
Uma troca de aplicação concluída supera qualquer dos contadores, por isso o teste deve terminar na aplicação e não no indicador do túnel.
Escolha a correção depois
Só quando esse registo existe há uma correção a escolher: seletores aceites, rota, filtragem, implementação do par ou um limite que agora demonstrou. Reiniciar o par altera vários estados de uma vez e muitas vezes restaura o tráfego sem explicar qual estava errado, pelo que a falha regressa. Mantenha os despejos de estado do núcleo fora dos tickets, porque podem conter chaves e o resumo estreito basta para quem precise de ajudar.
Quando o registo contradiz a sua primeira teoria, acredite no registo e reescreva a teoria; esse hábito vale mais do que qualquer linha de registo concreta aqui discutida.