Distingir la fragmentació d’IKEv2 d’un problema de cadena de certificats

El túnel funcionava a la xarxa de l’oficina i s’encalla a casa, i el registre mostra que el primer bescanvi es completa abans que passi res més. Aquest patró apunta al bescanvi d’autenticació, no a les credencials: una cadena de certificats fa que aquest missatge sigui molt més gran que l’anterior, i un camí que no tolera datagrames grans el descartarà en silenci. Hi intervenen dos mecanismes de fragmentació diferents, i saber quin esteu mirant decideix la solució.

Dos mecanismes de fragmentació, un símptoma

IKEv2 té la seva pròpia extensió de fragmentació, definida a RFC 7383, que divideix els missatges IKE protegits en missatges IKE més petits. Els parells negocien aquesta capacitat, i el missatge el reassembla la implementació d’IKE, no la capa IP.

La fragmentació IP ordinària és un mecanisme diferent amb un mode de fallada diferent. Un encaminador entre els parells fragmenta un datagrama gran, o el descarta i retorna un missatge ICMP que potser no arribarà mai a l’emissor. Algunes xarxes descarten fragments en silenci, i alguns dispositius intermediaris gestionen el primer fragment però no la resta. Des del punt de vista de l’aplicació, els tres casos semblen idèntics.

La travessa de NAT afegeix una tercera variable, perquè llavors ESP s’embolcalla en UDP i el paquet exterior es fa més gran mentre sembla trànsit UDP ordinari al port 4500. Un camí que deixa passar bé l’UDP encara pot fallar amb un datagrama que ja no hi cap.

Llegiu el bescanvi que va fallar

Busqueu la transició, no l’error. Un registre que mostra el bescanvi inicial enviat i respost, seguit de res, us diu que el missatge següent no es va completar mai. Apugeu temporalment el nivell del registre i compareu les mides informades als dos parells.

El que voleu establir és si el responedor va veure la petició. Si l’iniciador va enviar alguna cosa i el responedor no en té cap registre, el problema és el lliurament. Si el responedor va analitzar una petició i la va rebutjar, el problema és el certificat mateix, i la fragmentació és una distracció. Aquesta distinció val més que una pàgina de missatges de temps d’espera.

Canvieu el camí, no el certificat

Proveu el mateix client, el mateix certificat i la mateixa configuració des d’una xarxa diferent. Un punt d’accés mòbil sol ser el segon camí més barat, i és genuïnament diferent de l’enllaç de l’oficina, no només nominalment.

Si l’intercanvi es completa pel segon camí, la cadena de certificats està bé i el primer camí és la variable. Si falla de manera idèntica als dos, deixeu de provar xarxes i mireu els missatges mateixos. Aquesta única comparació elimina aproximadament la meitat de les explicacions possibles.

Mesureu el bescanvi abans d’editar res

Obteniu la mida de la cadena i la mida del camí. Tots dos nombres limiten què pot enviar l’intercanvi, i tots dos són barats de mesurar:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

Els dos primers donen el nombre de certificats i la mida del fitxer, cosa que és un indicador raonable de com de gran serà el missatge d’autenticació. La prova de ping informa si un datagrama d’aquesta mida sobreviu al camí, i els comptadors de la interfície mostren si s’han descartat fragments al vostre extrem. A Windows, la prova equivalent és un ping amb el senyal do-not-fragment i una mida de càrrega útil explícita.

Repetiu la prova cap avall fins que tingui èxit. La mida més gran que passa és el pressupost de treball per a aquell camí, i és més útil que qualsevol valor predeterminat publicat.

Repareu la capa que realment està trencada

Si el camí descarta datagrames grans, activeu la fragmentació IKE als dos parells i confirmeu que l’extensió s’ha negociat, no només ofert. Si el camí gestiona malament els fragments a nivell IP, la correcció pertany allà o a l’MTU de la interfície exterior, no a l’emmagatzematge de certificats.

Si la cadena és innecessàriament llarga, retalleu-la fins als certificats intermedis que un parell realment necessita. Treure una arrel en què el client ja confia és un manteniment raonable; treure un intermediari no ho és, i desactivar la verificació per reduir un missatge canvia un problema de lliurament per un de seguretat.

Anoteu quin mecanisme heu canviat i com era l’intercanvi després. La propera ocurrència sol ser en una xarxa diferent amb el mateix símptoma, i la nota és el que converteix dues hores en deu minuts.