IPsec ESP: que transporta e como demostrar que flúe
ESP envolve un paquete IP interno en modo túnel e identifica a súa asociación mediante o SPI. Lea o estado e despois observe como un só fluxo move os contadores.
ESP transporta o tráfico nunha VPN IPsec, e o seu runbook comeza cunha regra: lea a asociación de seguridade antes de cambiar unha política. A maior parte do comportamento inexplicado de ESP remóntase a un selector que non coincidía, un modo que se supuxo en lugar de lerse, ou un contador que ninguén comprobou mentres se enviaba un único fluxo. Os tres pasos seguintes establecen que transporta que, demostran que un fluxo o usa e deixan unha reversión que non depende da memoria. Cada paso produce unha observación que paga a pena anotar.
Coñeza os campos antes de lelos
ESP coloca unha cabeceira diante dos datos protexidos e un tráiler detrás. A cabeceira leva un índice de parámetros de seguridade que identifica que asociación debe usar o receptor, un número de secuencia para detectar repeticións e un recheo no tráiler que mantén a carga útil aliñada para o cifrado. O campo de cabeceira seguinte do tráiler di cal é o contido protexido, e así é como o receptor sabe que desencapsulou.
O modo cambia que hai dentro desa protección. En modo túnel o material protexido é un paquete IP interno completo, e unha cabeceira externa nova transpórtao entre os extremos. En modo transporte a protección envolve a carga útil da capa superior dun paquete existente, así que non hai unha segunda cabeceira IP que abrir. Que modo se usa é un feito de configuración, non unha cuestión de interpretación. Léao na entrada de estado en lugar de inferilo dun diagrama.
Ningún dos dous modos oculta o direccionamento externo que debe entregar o paquete. Iso é unha propiedade do deseño e non unha carencia, e por iso un observador intermedio aínda pode ver que dúas direccións falan mesmo cando a carga útil é opaca.
Paso un: lea o estado e despois a política
As entradas de estado gardan as claves e os contadores; as entradas de política gardan os selectores que deciden que pode usalas. En Linux ambas son visibles sen capturar paquetes, e lelas nesa orde mantén separadas as dúas preguntas.
ip xfrm state
ip xfrm policyNa saída de estado, comprobe a orixe e o destino da asociación, o modo e se a encapsulación mostra portos UDP. Eses portos significan que se usa a travesía de NAT, o que cambia que debe permitir un cortalumes intermedio, pero non que selectores ou claves se aplican nos extremos.
Despois lea os selectores da política. Un selector que nomea un prefixo máis estreito que o tráfico que proba é o motivo máis habitual de que un túnel que funciona pareza ignorar un fluxo, e un selector para o protocolo equivocado produce o mesmo silencio.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
As ferramentas dos fabricantes mostran a mesma información nunha forma máis cómoda. ipsec statusall en strongSwan lista as asociacións fillas, os seus selectores e os seus contadores de bytes, o que a miúdo é máis rápido que ler a saída xfrm en bruto cando xa sabe que filla mirar.
Paso dous: demostre que un fluxo move os contadores
Os contadores só teñen sentido se sabe que debería movelos, así que escolla unha orixe e un destino que o selector cubra con seguridade e envíe unha petición inofensiva. Despois volva ler a mesma entrada e compare.
ip -s xfrm state
tcpdump -ni any espDúas lecturas contan historias distintas. Os paquetes que aumentan no lado de saída pero nunca no de entrada apuntan a un problema de reenvío ou de camiño de volta, non a un problema de clave, porque o paquete encapsulouse e marchou. Que non se mova ningún contador significa que o tráfico nunca coincidiu coa política, e o selector é onde hai que mirar.
A captura do mesmo paso confirma a encapsulación no cable, incluído se os paquetes externos son ESP ou ESP encapsulado en UDP. Tamén lle mostra as direccións que realmente transportaron o fluxo, que ás veces difiren das da configuración que estaba lendo.
Paso tres: cambie unha cousa e conserve unha reversión
Anote a orixe, o destino, o modo, os selectores e os contadores da asociación antes de editar nada. Se un cambio empeora as cousas, ese rexistro é o que lle permite restaurar o estado anterior en lugar de reconstruír unha configuración que funciona a partir dunha conxectura. Ese rexistro custa un minuto de escribir e aforra unha hora máis tarde. Tamén é o único artefacto que sobrevive á persoa que fixo o cambio.
Cambie un selector ou un parámetro, volva cargalo e repita o paso dous sobre o mesmo fluxo. Borrar unha asociación derruba todos os fluxos que a usan, así que unha edición dirixida e unha recarga da filla case sempre son mellores que baleirar o estado para ver que pasa.
A reversión dunha edición de selector é restaurar a política anterior e volver cargala, coa advertencia de que o par pode necesitar un cambio correspondente se o selector se negocia en lugar de ser local. Anote esa dependencia mentres está fresca, porque un par medio restaurado é máis difícil de razoar que calquera dos dous estados finais.
Por último, manteña o alcance honesto. Unha asociación ESP que flúe demostra que as dúas pasarelas protexen e entregan o segmento, e non di nada sobre se a aplicación de arriba autentica os seus usuarios ou cifra o que almacena. Son controis separados con probas separadas, e o runbook só remata cando a seguinte persoa pode repetilo a partir das notas.