L2TP, GRE ou IPsec: qual camada deve transportar a sessão?

Duas perguntas se emaranham sempre que L2TP, GRE e IPsec caem na mesma nota de projeto: que sessão estou transportando, e qual camada a protege? Errar a primeira deixa tudo a jusante internamente coerente enquanto se resolve o problema errado — uma sobreposição encaminhada construída onde os usuários precisavam discar, ou um concentrador de acesso discado no lugar de um gateway site a site. A planilha abaixo força essa distinção antes de alguém entrar num equipamento. Preencha-a em ordem e cada linha vira algo que você pode testar sozinho.

Comece pela sessão, não pela lista de protocolos

Um usuário remoto com uma sessão PPP e uma sobreposição encaminhada entre dois gateways são relações de rede diferentes, mesmo quando ambas acabam envolvidas em IPsec. A primeira termina um link por usuário e precisa de atribuição de endereços, autenticação de uma pessoa ou dispositivo e uma política que nomeie quais redes internas esse usuário pode alcançar. A segunda encaminha pacotes entre sites para os quais ninguém disca.

Escreva uma frase que nomeie qual das duas você está construindo e leia-a de volta como se você fosse a pessoa que precisa operá-la. Se a frase precisar da palavra 'e', você está construindo as duas, e a planilha precisa de duas colunas em vez de uma coluna de compromisso que serve pela metade a cada uma. Se ela nomeia um usuário mas nenhum pool de endereços, ou um prefixo mas nenhuma política de encaminhamento, a frase ainda está incompleta. A redação soa burocrática, mas é o lugar mais barato para pegar um projeto que, de outro modo, seria descoberto por um chamado ao suporte.

Atribua a cada camada exatamente uma tarefa

O L2TPv2 transporta sessões PPP entre seus dois pontos extremos. O PPP executa a negociação do link e, quando ela é negociada, a autenticação do usuário; o L2TP não acrescenta criptografia, então um daemon L2TP puro não implementa nenhuma parte da relação de segurança IPsec e só pertence dentro de um link em que você já confia.

O GRE é um encapsulamento entre dois endereços. Ele transporta pacotes da camada de rede por uma sobreposição lógica e, sozinho, não oferece confidencialidade nem identidade de par autenticada. Isso não é um defeito: o cabeçalho foi projetado simples para continuar barato de processar em hardware de encaminhamento. A consequência é que o GRE responde a 'como movo este pacote entre dois endereços' e a mais nada, que é exatamente a pergunta que você deve fazer a ele.

Isso deixa o IPsec como a camada que seleciona o tráfego, autentica os pares e cifra o que lhe foi dito para proteger. Qual tráfego ele protege é uma decisão de configuração que precisa corresponder ao encapsulamento que os pontos extremos realmente geram, porque uma política escrita para o endereço externo do GRE se comporta de modo diferente de uma escrita para os prefixos internos. A especificação do GRE mantém visivelmente separados a carga útil, o cabeçalho GRE e o protocolo de entrega externo, e sua política precisa da mesma separação.

Escreva o caminho do pacote antes da configuração

Pegue um pacote e liste cada cabeçalho acrescentado, na ordem em que é acrescentado, nomeando o dispositivo que o acrescenta. Para um usuário de acesso discado costuma ser PPP dentro de L2TP dentro de IPsec; para uma sobreposição de sites, o pacote IP interno dentro de GRE dentro de IPsec. Se dois dispositivos acrescentam o mesmo cabeçalho, você tem um laço ou um túnel duplicado, e nenhuma edição de política resolve isso.

A mesma lista resolve a MTU, porque o tamanho interno utilizável é a MTU de caminho medida menos os cabeçalhos que você acabou de enumerar e nada mais. Não copie um número de uma postagem de fórum: some a sobrecarga de IP externo, UDP e ESP, depois GRE ou L2TP, depois PPP onde se aplica, e subtraia da MTU de caminho que você realmente mediu. Sintomas que só aparecem em transferências grandes, ou sessões que se estabelecem e morrem na primeira resposta grande, costumam remontar a essa soma feita por estimativa.

Verifique cada camada separadamente, de fora para dentro

Execute as verificações em ordem e pare na primeira que falhar. Cada linha responde a uma pergunta diferente, então uma falha aponta para uma coluna da planilha em vez de dizer que o túnel está quebrado.

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?

Num equipamento Cisco o equivalente depende da função, e a sintaxe exata varia conforme a plataforma e a versão: show crypto session para os pares IPsec, contadores de interface para a interface GRE ou de túnel, e a verificação VPDN ou PPP para a função de acesso discado. Um conjunto de comandos que encerra PPP não prova nada sobre suporte a GRE, e uma interface GRE funcionando não prova nada sobre o serviço PPP, então verifique a função que você realmente configurou em vez da que está no diagrama.

Anote cada saída ao lado da linha da planilha a que pertence. Notas feitas enquanto a falha está ativa valem mais do que uma topologia redesenhada depois de memória.

Ordene a desmontagem e verifique de novo

A desmontagem corre ao contrário por um motivo: retire o tráfego protegido da política IPsec antes de remover o encapsulamento para o qual ela foi escrita, ou a política continua apontando para uma interface que não existe mais e o próximo carregamento de configuração falha num ponto que parece sem relação. No Linux isso significa excluir as entradas de estado e de política antes da interface de túnel; num roteador, remover a entrada de crypto map ou de perfil antes do túnel.

Depois da reconstrução, repita as quatro observações de aceitação uma de cada vez: alcançabilidade externa, uma associação IPsec estabelecida, uma sessão PPP estabelecida onde o projeto inclua uma, e encaminhamento interno para um endereço de destino real. Uma luz verde não é prova das outras três, e essa lacuna é a falha que sobrevive mais tempo em produção — um túnel que está ativo, cifrado e não encaminha nada porque a rota interna nunca foi adicionada.

Mantenha a planilha preenchida junto da configuração do equipamento. Qualquer coluna que você não consiga preencher é uma camada sem tarefa atribuída, e uma camada sem tarefa atribuída costuma ser uma camada que não deveria estar na pilha.