L2TP, GRE o IPsec: ¿qué capa debe transportar la sesión?

Dos preguntas se enredan siempre que L2TP, GRE e IPsec acaban en la misma nota de diseño: ¿qué sesión estoy transportando y qué capa la protege? Si se falla la primera, todo lo que está aguas abajo sigue siendo coherente por dentro mientras se resuelve el problema equivocado: una superposición enrutada construida donde los usuarios necesitaban marcar, o un concentrador de acceso telefónico que hace las veces de puerta de enlace entre sedes. La hoja de trabajo de abajo obliga a hacer esa distinción antes de que nadie entre en un dispositivo. Rellénela en orden y cada línea se convierte en algo que puede probar por sí solo.

Empiece por la sesión, no por la lista de protocolos

Un usuario remoto con una sesión PPP y una superposición enrutada entre dos puertas de enlace son relaciones de red distintas, incluso cuando ambas acaban envueltas en IPsec. La primera termina un enlace por usuario y necesita asignación de direcciones, autenticación de una persona o un dispositivo y una política que nombre qué redes internas puede alcanzar ese usuario. La segunda reenvía paquetes entre sedes a las que nadie marca.

Escriba una frase que nombre cuál de las dos está construyendo y léala después como si fuera la persona que tiene que operarla. Si la frase necesita la palabra 'y', está construyendo ambas y la hoja necesita dos columnas en lugar de una columna de compromiso que sirva a medias a cada una. Si nombra a un usuario pero no un conjunto de direcciones, o un prefijo pero no una política de reenvío, la frase sigue incompleta. La redacción suena burocrática, pero es el lugar más barato para detectar un diseño que de otro modo descubrirá un ticket de soporte.

Asigne a cada capa exactamente una tarea

L2TPv2 transporta sesiones PPP entre sus dos extremos. PPP ejecuta la negociación del enlace y, cuando se negocia, la autenticación del usuario; L2TP no añade criptografía, así que un demonio L2TP básico no implementa ninguna parte de la relación de seguridad IPsec y solo pertenece dentro de un enlace en el que ya confía.

GRE es una encapsulación entre dos direcciones. Transporta paquetes de capa de red por una superposición lógica y, por sí solo, no ofrece ni confidencialidad ni identidad de par autenticada. No es un defecto: la cabecera se diseñó simple para que siga siendo barata de procesar en hardware de reenvío. La consecuencia es que GRE responde a 'cómo muevo este paquete entre dos direcciones' y nada más, que es exactamente la pregunta que debería hacerle.

Eso deja a IPsec como la capa que selecciona el tráfico, autentica a los pares y cifra lo que se le dijo que protegiera. Qué tráfico protege es una decisión de configuración que debe coincidir con la encapsulación que generan de verdad los extremos, porque una política escrita para la dirección externa de GRE se comporta distinto de una escrita para los prefijos internos. La especificación GRE mantiene visiblemente separados la carga útil, la cabecera GRE y el protocolo de entrega externo, y su política necesita la misma separación.

Escriba la ruta del paquete antes de la configuración

Tome un paquete y enumere cada cabecera que se añade, en el orden en que se añade, nombrando el dispositivo que la añade. Para un usuario de acceso telefónico suele ser PPP dentro de L2TP dentro de IPsec; para una superposición de sedes, el paquete IP interno dentro de GRE dentro de IPsec. Si dos dispositivos añaden la misma cabecera, tiene un bucle o un túnel duplicado, y ninguna edición de política lo arreglará.

La misma lista fija la MTU, porque el tamaño interno utilizable es la MTU de ruta medida menos las cabeceras que acaba de enumerar y nada más. No copie un número de un mensaje de foro: sume la sobrecarga de IP externo, UDP y ESP, después GRE o L2TP, después PPP donde corresponda, y réstelo de la MTU de ruta que midió de verdad. Los síntomas que solo aparecen en transferencias grandes, o las sesiones que se establecen y luego mueren en la primera respuesta grande, suelen remontarse a que esa suma se hizo a ojo.

Compruebe cada capa por separado, de fuera hacia dentro

Ejecute las comprobaciones en orden y deténgase en la primera que falle. Cada línea responde a una pregunta distinta, así que un fallo apunta a una columna de la hoja en lugar de decir que el túnel está roto.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

En un equipo Cisco el equivalente depende del rol, y la sintaxis exacta varía según la plataforma y la versión: show crypto session para los pares IPsec, contadores de interfaz para la interfaz GRE o de túnel, y la verificación VPDN o PPP para el rol de acceso telefónico. Un conjunto de comandos que termina PPP no demuestra nada sobre el soporte de GRE, y una interfaz GRE que funciona no demuestra nada sobre el servicio PPP, así que verifique el rol que configuró de verdad en lugar del del diagrama.

Anote cada salida junto a la línea de la hoja a la que pertenece. Las notas tomadas mientras el fallo está activo valen más que una topología redibujada después de memoria.

Ordene el desmontaje y vuelva a verificar

El desmontaje se ejecuta al revés por una razón: saque el tráfico protegido de la política IPsec antes de quitar la encapsulación para la que se escribió, o la política seguirá apuntando a una interfaz que ya no existe y la siguiente carga de configuración fallará en un sitio que parece no tener relación. En Linux eso significa borrar las entradas de estado y de política antes de la interfaz de túnel; en un router, quitar la entrada de crypto map o de perfil antes del túnel.

Tras la reconstrucción, repita las cuatro observaciones de aceptación una a una: accesibilidad externa, una asociación IPsec establecida, una sesión PPP establecida donde el diseño incluya una, y reenvío interno hacia una dirección de destino real. Una luz verde no es prueba de las otras tres, y ese hueco es el fallo que sobrevive más tiempo en producción: un túnel que está activo, cifrado y no reenvía nada porque nunca se añadió la ruta interna.

Guarde la hoja rellenada junto a la configuración del dispositivo. Cualquier columna que no pueda rellenar es una capa sin tarea asignada, y una capa sin tarea asignada suele ser una capa que no debería estar en la pila.