L2TP, GRE ou IPsec: que capa debe levar a sesión?

Dúas preguntas entrelázanse sempre que L2TP, GRE e IPsec coinciden na mesma nota de deseño: que sesión estou a levar e que capa a protexe? Se erras a primeira, todo o demais segue sendo coherente por dentro mentres resolve o problema equivocado — unha superposición encamiñada construída onde os usuarios necesitaban marcar, ou un concentrador de marcación no canto dunha pasarela sitio a sitio. A folla de traballo de abaixo obriga a facer esa distinción antes de que ninguén entre nun dispositivo. Enchéaa en orde e cada liña convértese en algo que podes probar por si mesmo.

Comeza pola sesión, non pola lista de protocolos

Un usuario remoto que mantén unha sesión PPP e unha superposición encamiñada entre dúas pasarelas son relacións de rede distintas, aínda que ambas acaben envoltas en IPsec. A primeira remata unha ligazón por usuario e necesita asignación de enderezos, autenticación dunha persoa ou dispositivo e unha política que nomee que redes internas pode acadar ese usuario. A segunda reenvía paquetes entre sitios nos que ninguén marca.

Escribe unha frase que nomee cal das dúas estás a construír e despois lédea coma se foses a persoa que ten que operala. Se a frase necesita a palabra «e», estás a construír as dúas, e a folla de traballo necesita dúas columnas en vez dunha columna de compromiso que serve a medias a cada unha. Se nomea un usuario pero non un conxunto de enderezos, ou un prefixo pero non unha política de reenvío, a frase aínda está incompleta. A redacción soa burocrática, pero é o lugar máis barato para detectar un deseño que, doutro xeito, descubriría unha incidencia do servizo de asistencia.

Dálle a cada capa exactamente un traballo

L2TPv2 leva sesións PPP entre os seus dous extremos. PPP executa a negociación da ligazón e, cando se negocia, a autenticación do usuario; L2TP non engade criptografía, polo que un daemon L2TP espido non implementa ningunha parte da relación de seguridade IPsec e pertence só dentro dunha ligazón na que xa confías.

GRE é unha encapsulación entre dous enderezos. Leva paquetes da capa de rede a través dunha superposición lóxica e, por si só, non ofrece nin confidencialidade nin unha identidade de par autenticada. Iso non é un defecto: a cabeceira deseñouse simple para que siga sendo barata de procesar no hardware de reenvío. A consecuencia é que GRE responde a «como movo este paquete entre dous enderezos» e a nada máis, que é exactamente a pregunta que deberías facerlle.

Iso deixa IPsec como a capa que selecciona o tráfico, autentica os pares e cifra o que se lle dixo que protexese. Que tráfico protexe é unha decisión de configuración que ten que coincidir coa encapsulación que os extremos xeran realmente, porque unha política escrita para o enderezo exterior de GRE compórtase de xeito distinto dunha escrita para os prefixos internos. A especificación GRE mantén a carga útil, a cabeceira GRE e o protocolo de entrega exterior visiblemente separados, e a túa política necesita a mesma separación.

Escribe o camiño do paquete antes da configuración

Colle un paquete e enumera cada cabeceira que se engade, na orde en que se engade, nomeando o dispositivo que a engade. Para un usuario que marca, adoita ser PPP dentro de L2TP dentro de IPsec; para unha superposición de sitio é o paquete IP interno dentro de GRE dentro de IPsec. Se dous dispositivos engaden a mesma cabeceira, tes un bucle ou un túnel duplicado, e ningunha cantidade de edición de políticas o vai arranxar.

A mesma lista resolve o MTU, porque o tamaño interno utilizable é o MTU de camiño medido menos as cabeceiras que acabas de enumerar e nada máis. Non copies un número dunha publicación dun foro: suma a sobrecarga exterior de IP, UDP e ESP, despois GRE ou L2TP, despois PPP onde corresponda, e resta do MTU de camiño que medistes realmente. Os síntomas que só aparecen en transferencias grandes, ou as sesións que se establecen e despois morren na primeira resposta grande, adoitan remontarse a esa suma feita por suposición.

Comproba cada capa por separado, de fóra a dentro

Executa as comprobacións en orde e detente na primeira que falle. Cada liña responde a unha pregunta distinta, así que un fallo apunta a unha columna da folla de traballo en vez de dicirche que o 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?

Nunha caixa Cisco o equivalente depende do rol, e a sintaxe exacta depende da plataforma e da versión: show crypto session para os pares IPsec, contadores de interface para o GRE ou a interface de túnel, e a verificación VPDN ou PPP para o rol de marcación. Un conxunto de comandos que remata PPP non demostra nada sobre o soporte de GRE, e unha interface GRE que funciona non demostra nada sobre o servizo PPP, así que verifica o rol que configurastes realmente e non o do diagrama.

Rexistra cada saída xunto á liña da folla de traballo á que pertence. As notas tomadas mentres a avaría está activa valen máis ca unha topoloxía redesañada despois de memoria.

Ordena o desmontaxe e despois volve verificar

O desmontaxe vai ao revés por unha razón: saca o tráfico protexido da política IPsec antes de retirar a encapsulación contra a que se escribiu, ou a política seguirá apuntando a unha interface que xa non existe e a seguinte carga de configuración fallará nalgún lugar que parece non relacionado. En Linux iso significa borrar as entradas de estado e de política antes da interface de túnel; nun router, retirar a entrada de crypto map ou de perfil antes do túnel.

Despois da reconstrución, repite as catro observacións de aceptación unha a unha: accesibilidade exterior, unha asociación IPsec establecida, unha sesión PPP establecida cando o deseño inclúe unha, e reenvío interno a un enderezo de destino real. Unha luz verde non é evidencia para as outras tres, e esa fenda é o fallo que sobrevive máis tempo en produción — un túnel que está activo, cifrado e non reenvía nada porque nunca se engadiu a ruta interna.

Mantén a folla de traballo enchida xunto á configuración do dispositivo. Calquera columna que non poidas encher é unha capa sen traballo asignado, e unha capa sen traballo asignado adoita ser unha capa que non debería estar na pila.