O ESP de saída sen resposta non significa que a VPN estea morta
ESP protexe unha dirección por asociación e non recoñece nada. Aliñe a conversa interna e a SA de entrada antes de cualificar o servidor de insensible.
Capturou tráfico no host IPsec, viu saír paquetes ESP, non viu volver nada e concluíu que o lado remoto está roto. A captura non sostén esa conclusión. ESP protexe unha dirección dunha conversa e non recoñece nada na capa IP, así que a ausencia de ESP de retorno pode significar que a aplicación non tiña nada que dicir coa mesma facilidade con que pode significar que o túnel está morto. Lea o intercambio interno e o estado do lado receptor antes de culpar calquera dos dous extremos.
O mito: cada paquete protexido gaña unha resposta
ESP non é un protocolo de petición e resposta. Cifra e autentica o que a política selecciona, e o receptor valida, descifra e entrega ese paquete interno sen xerar un paquete propio. Unha consulta UDP que o destino ignora, ou un eco ICMP que a política de entrada descarta, producen silencio en ambas as direccións como resultado correcto. Tratar ese silencio como un fallo de transporte envíao a buscar unha avaría de rede que nunca existiu.
O que unha captura unidireccional demostra en realidade é que a pila do emisor cifrou algo nese punto de observación. Nada sobre a chegada, e nada sobre a intención de responder. A pregunta útil non é "por que non hai resposta" senón "que debería ter producido a conversa interna".
Dúas SA, dous SPI, unha conversa
As asociacións de seguridade IPsec son unidireccionais, así que un intercambio protexido normal ten unha asociación de entrada e unha de saída con identificadores separados e estado independente. Buscar o tráfico de retorno polo SPI do paquete de saída é, por tanto, un erro de categoría, porque calquera resposta viaxa baixo a SA de saída propia do par co seu propio SPI. Emparexe o conxunto por selectores de tráfico e enderezos do par.
A renovación de chaves complica o cadro durante uns segundos cada vez, xa que o estado antigo e o de substitución poden solaparse. Se o síntoma comezou ao redor dunha renovación de chaves, recolla os identificadores de asociación e as marcas de tempo xuntos en lugar de só o nome da conexión.
Que debe facer o receptor antes de que algo responda
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Cada fila falla de forma independente e cada fallo ten un propietario distinto, por iso unha soa captura non pode distinguilas. O contador de entrada é a única proba directa de chegada, porque un paquete que falla a súa autenticación ou a comprobación de repetición descártase sen ningunha resposta. Un par cuxo contador de entrada non se moveu, por tanto, non lle envía ningunha información sobre a súa política.
A entrega é un paso separado do descifrado. O estado pode ser válido e o paquete aínda así descartarse despois por unha política de entrada ou unha ruta que non inclúe o destino interno, así que comprobe se o host obxectivo viu texto plano en lugar de supor que un contador limpo significa que o paquete foi onde vostede quería.
O ESP nativo non é UDP
O ESP nativo é o protocolo IP 50, que non é nin TCP nin UDP e non ten ningún porto. Unha regra de firewall que permite IKE en UDP 500 non di nada, por tanto, sobre a ruta de datos, e un filtro escrito arredor de portos pode deixar que un túnel negocie e despois descartar todo o que leva dentro. Probe a ruta de datos por separado, no modo que observou realmente.
Detrás dun NAT a forma cambia: a carga protexida viaxa dentro de UDP, normalmente no porto 4500, como define RFC 3948. Rexistre o modo activo antes de escribir calquera regra, porque un dispositivo na ruta pode tratar o ESP nativo e o ESP encapsulado en UDP de forma completamente distinta, e algúns middleboxes permiten un e descartan o outro.
Lea contadores que pertenzan a este incidente
Nun host strongSwan, swanctl --list-sas informa contadores de paquetes e bytes por asociación en ambas as direccións, o que abonda para separar "nunca chegou" de "chegou e non se respondeu". En Linux, /proc/net/xfrm_stat conta fallos agregados como estado ausente, política ausente e erros de protocolo. Esas cifras acumúlanse desde o arranque e pertencen a un só espazo de nomes de rede, así que un número grande non é unha atribución.
Tome dúas lecturas arredor da xanela do incidente no espazo de nomes correcto e compare as diferenzas, ou ben cravará os erros da semana pasada no ticket desta tarde. Poña o espazo de nomes e ambas as marcas de tempo no ticket para que o seguinte lector poida reproducir a comparación en lugar de confiar nun total.
Nomee a etapa, non o sospeitoso
Unha conclusión útil di onde se detivo o paquete: nunca recibido, recibido e descartado, entregado pero sen resposta, ou respondido e perdido de volta. Cada un deses puntos sinala un propietario distinto e un comando seguinte distinto. "Sen resposta do servidor VPN" colapsa catro fallos distintos nunha frase que a captura nunca xustificou.
Manteña as capturas estreitas e manteña o estado cru do núcleo fóra dos tickets, porque pode levar material de chaves que non ten nada que facer fóra do host. As diferenzas dos contadores e as marcas de tempo son as partes que paga a pena entregar á seguinte persoa.