L’ESP de sortida sense resposta no vol dir que la VPN sigui morta
L’ESP protegeix una direcció per associació i no reconeix res. Alineeu la conversa interna i la SA d’entrada abans de qualificar el servidor d’insensible.
Vau capturar trànsit a l’amfitrió IPsec, vau veure sortir paquets ESP, no vau veure tornar res i vau concloure que el costat llunyà està espatllat. La captura no sosté aquesta conclusió. L’ESP protegeix una direcció d’una conversa i no reconeix res a la capa IP, així que l’absència d’ESP de retorn pot significar que l’aplicació no tenia res a dir amb la mateixa facilitat que pot significar que el túnel és mort. Llegiu l’intercanvi intern i l’estat del costat receptor abans de culpar qualsevol dels dos extrems.
El mite: cada paquet protegit es guanya una resposta
L’ESP no és un protocol de petició-resposta. Xifra i autentica allò que la política selecciona, i el receptor valida, desxifra i lliura aquest paquet intern sense generar cap paquet propi. Una consulta UDP que la destinació ignora, o un eco ICMP que la política d’entrada descarta, produeixen silenci en ambdues direccions com a resultat correcte. Tractar aquest silenci com una fallada de transport us envia a caçar una fallada de xarxa que mai no hi era.
El que una captura unidireccional demostra realment és que la pila del remitent va xifrar alguna cosa en aquell punt d’observació. Res sobre l’arribada, i res sobre la intenció de respondre. La pregunta útil no és "per què no hi ha resposta" sinó "què hauria d’haver produït la conversa interna".
Dues SA, dos SPI, una conversa
Les associacions de seguretat IPsec són unidireccionals, així que un intercanvi protegit normal té una associació d’entrada i una de sortida amb identificadors separats i estat independent. Buscar el trànsit de retorn per l’SPI del paquet de sortida és, per tant, un error de categoria, perquè qualsevol resposta viatja sota la SA de sortida pròpia del parell amb el seu propi SPI. Emparelleu el conjunt per selectors de trànsit i adreces del parell.
La regeneració de claus complica el quadre durant uns segons cada cop, ja que l’estat antic i el de substitució es poden solapar. Si el símptoma va començar al voltant d’una regeneració de claus, recolliu els identificadors d’associació i les marques de temps junts en lloc de només el nom de la connexió.
Què ha de fer el receptor abans que res respongui
| 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 manera independent i cada fallada té un propietari diferent, i per això una sola captura no les pot distingir. El comptador d’entrada és l’única evidència directa d’arribada, perquè un paquet que falla l’autenticació o la comprovació de repetició es descarta sense cap resposta. Un parell el comptador d’entrada del qual no s’ha mogut, doncs, no us envia cap informació sobre la seva política.
El lliurament és un pas separat del desxifratge. L’estat pot ser vàlid i el paquet encara descartat després per una política d’entrada o una ruta que no inclou la destinació interna, així que comproveu si l’amfitrió objectiu va veure text pla en lloc de suposar que un comptador net vol dir que el paquet va anar on volíeu.
L’ESP natiu no és UDP
L’ESP natiu és el protocol IP 50, que no és ni TCP ni UDP i no té cap port. Una regla de tallafoc que permet IKE a UDP 500 no diu res, per tant, sobre el camí de dades, i un filtre escrit al voltant de ports pot deixar que un túnel negociï i després descartar tot el que porta a dins. Proveu el camí de dades pel seu compte, en el mode que vau observar realment.
Darrere d’un NAT la forma canvia: la càrrega protegida viatja dins d’UDP, normalment al port 4500, tal com defineix RFC 3948. Enregistreu el mode actiu abans d’escriure cap regla, perquè un dispositiu al camí pot tractar l’ESP natiu i l’ESP encapsulat en UDP de manera completament diferent, i alguns middlebox permeten un i descarten l’altre.
Llegiu comptadors que pertanyin a aquest incident
En un amfitrió strongSwan, swanctl --list-sas informa de comptadors de paquets i bytes per associació en ambdues direccions, cosa suficient per separar "mai no va arribar" de "va arribar i no es va respondre". A Linux, /proc/net/xfrm_stat compta fallades agregades com ara estat absent, política absent i errors de protocol. Aquests totals s’acumulen des de l’arrencada i pertanyen a un sol espai de noms de xarxa, així que un nombre gran no és una atribució.
Preneu dues lectures al voltant de la finestra de l’incident a l’espai de noms correcte i compareu les diferències, o bé clavareu els errors de la setmana passada al tiquet d’aquesta tarda. Poseu l’espai de noms i ambdues marques de temps al tiquet perquè el següent lector pugui reproduir la comparació en lloc de confiar en un total.
Anomeneu l’etapa, no el sospitós
Una conclusió útil diu on es va aturar el paquet: mai no rebut, rebut i descartat, lliurat però sense resposta, o respost i perdut de tornada. Cadascun d’aquests punts assenyala un propietari diferent i una comanda següent diferent. "Cap resposta del servidor VPN" col·lapsa quatre fallades diferents en una frase que la captura mai no va justificar.
Manteniu les captures estretes i manteniu l’estat cru del nucli fora dels tiquets, perquè pot portar material de claus que no té res a fer fora de l’amfitrió. Les diferències dels comptadors i les marques de temps són les parts que val la pena lliurar a la persona següent.