L2TP sem IPsec no Linux: xl2tpd, pppd e NAT

O L2TP puro é PPP dentro de um envelope, e nada mais. Transporta as suas tramas; não as cifra nem prova quem está do outro lado, e é por isso que quase todas as implantações metem IPsec por baixo. Ainda existem razões honestas para usar a versão nua: uma bancada de laboratório, um passo de migração ou um link que já está dentro de outro caminho protegido.

Se avançar, escreva esse aviso na nota de conceção e deixe-o lá. O que se segue é o caminho operacional que uso em anfitriões da família Debian e RHEL: que ficheiro trata do quê, a MTU que evita o bloqueio clássico e as regras de reencaminhamento que tornam o túnel útil.

Três ficheiros repartem o trabalho

O xl2tpd termina a ligação de controlo e entrega cada sessão a um daemon PPP, por isso a configuração reparte-se por dois programas que nunca leem os ficheiros um do outro. O ouvinte vive em /etc/xl2tpd/xl2tpd.conf, dentro de uma secção [lns default] que nomeia o conjunto de endereços com ip range, o lado do servidor com local ip e a entrega ao PPP com pppoptfile. Ative require authentication = yes, deixe length bit e flow bit ativos e escolha um conjunto que mais nada no anfitrião esteja já a usar.

A política PPP pertence ao ficheiro que essa opção nomear, normalmente /etc/ppp/options.xl2tpd: auth, recusas para pap, chap e mschap, require-mschap-v2, uma MTU e uma MRU de 1460 e um endereço DNS que o cliente consiga alcançar depois de a ligação subir. As credenciais estão outra vez num terceiro ficheiro, /etc/ppp/chap-secrets, onde o segundo campo tem de coincidir com o nome da secção LNS e o quarto pode fixar um endereço concreto do conjunto.

Porque o túnel liga e depois encrava

Uma trama Ethernet de 1500 bytes não cabe dentro de um caminho que já gasta bytes nos próprios cabeçalhos. O cabeçalho IPv4 exterior custa 20, o UDP custa 8 e o do L2TP cerca de 12, o que deixa 1460 para o PPP e a sua carga. Anunciar esse número mais pequeno no PPP é o que impede os pacotes grandes de serem fragmentados ou descartados em silêncio em algum ponto a meio.

O sintoma é um túnel que parece saudável até chegar tráfego real: os pings e as mensagens de controlo passam, uma cópia de ficheiro encrava e nada no registo o explica. Baixe a MTU e a MRU em conjunto nos dois extremos. Ajustar apenas o cliente costuma transformar um encravamento duro num intermitente, que é pior de diagnosticar.

Uma porta leva duas conversas

O UDP 1701 fica debaixo das duas metades do protocolo, e esse único facto quebra mais regras de firewall do que qualquer outra parte da instalação. Primeiro chegam um pedido de início de ligação de controlo e a sua resposta; o pedido de sessão e a confirmação que se seguem não estabelecem nada além do par de identificadores. Depois o PPP assume o controlo: controlo de ligação, depois autenticação e depois protocolo de controlo de IP para acordar os endereços. Cada etapa tem o seu vocabulário no registo, e nenhuma se anuncia como falha de L2TP.

Ler uma captura exatamente nessa ordem diz-lhe que etapa falhou, e uma falha de autenticação PPP não se repara editando o xl2tpd. A porta partilhada explica outra falha comum: uma regra que só permite os primeiros pacotes de um fluxo deixa a sessão estabelecer-se e depois bloqueia a transferência. Permita o 1701 para toda a conversa, nos dois sentidos.

Tornar o túnel útil: reencaminhamento e NAT

Uma sessão por si só só chega ao servidor. O acesso à internet dos clientes precisa de reencaminhamento, de uma regra NAT para o conjunto no link ascendente e de DNS que o cliente consiga mesmo consultar depois de a ligação subir. O conjunto também tem de ficar fora do intervalo da LAN, senão as respostas dirigidas aos clientes são entregues localmente em vez de empurradas de volta para o túnel.

No servidor, ative o reencaminhamento com sysctl -w net.ipv4.ip_forward=1, traduza o conjunto com iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE e depois aceite o tráfego de saída do túnel com uma regra FORWARD para -i ppp0 -o eth0 e o tráfego de regresso com a regra espelho mais -m state --state RELATED,ESTABLISHED. Torne essas regras persistentes entre reinícios, porque um servidor que volta sem elas parece exatamente uma configuração de L2TP avariada.

Chegar à própria LAN do servidor é outra tarefa: acrescente uma rota de regresso para o conjunto no router da LAN, ou proxy ARP no servidor. Esconder os clientes atrás de NAT quando algo dentro da LAN tem de lhes dirigir-se diretamente só agenda uma segunda sessão de depuração para mais tarde.

O que a pilha nua não faz e como verificar

Nenhuma parte desta pilha cifra as tramas PPP, e nada nela autentica o extremo remoto como o servidor que escolheu de facto. O MS-CHAPv2 protege sim a troca de credenciais de um ouvinte que apenas observa, mas um atacante colocado no caminho ainda pode interferir na sessão. O cliente nativo do Windows só oferece L2TP em conjunto com IPsec, por isso conte com Linux, firmware de routers e clientes de terceiros como pares. Trate a configuração nua como um degrau de diagnóstico, nunca como o lugar onde parar.

Verifique por uma ordem fixa: execute xl2tpd -D em primeiro plano, acompanhe o registo para a etapa PPP, leia o endereço atribuído a partir de ip addr nos dois extremos e depois capture o UDP 1701 para confirmar que os dados fluem após a sessão subir. Se os quatro coincidirem e o tráfego continuar a falhar, a culpa é do encaminhamento, do NAT ou da MTU, não do próprio L2TP.