Servidor PPTP atrás de um router doméstico: corrija primeiro o 1723 e o GRE
Execute PPTP atrás de um router doméstico: TCP 1723, protocolo IP 47, a caixa de passagem e a aritmética do MTU, além de quando L2TP ou OpenVPN é a melhor troca.
PPTP atrás de um router doméstico falha de duas maneiras não relacionadas, e confundi-las custa uma noite inteira. Uma falha é um buraco no encaminhamento: o router deixa passar TCP 1723 e descarta o protocolo IP 47, por isso o cliente fica preso no erro 619. A outra é um problema de tamanho: o túnel sobe, autentica-se e depois congela quando um pacote de tamanho completo tem de atravessar. Descobrir qual das duas tem é o primeiro passo real; o resto compara o que o seu router consegue exprimir, não qual é a melhor marca.
Dois transportes, e só um tem porta
O PPTP divide-se em dois transportes: uma ligação de controlo em TCP 1723 e tramas PPP envolvidas em GRE melhorado, que é o protocolo IP 47. O GRE não tem número de porta, por isso uma regra escrita como encaminhamento da porta 1723 não a consegue cobrir, seja qual for o nome que a interface web dê ao campo. Um router doméstico oferece normalmente uma caixa chamada passagem PPTP em vez de uma regra de protocolo, e essa caixa faz dois trabalhos: permite o protocolo 47 através da firewall e ensina o NAT a seguir o fluxo GRE. Num router Linux esses trabalhos são módulos separados e regras separadas, e é por isso que uma passagem meio configurada ainda produz um canal de controlo a funcionar. Descubra qual metade está presente antes de mudar o que quer que seja.
A firewall do próprio servidor também tem de permitir o protocolo 47 a partir do endereço do router. Uma firewall do host que só aceita 1723/tcp reproduz o erro 619 a partir do interior da LAN, o que faz um encaminhamento quebrado e uma regra de host quebrada parecerem iguais.
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'
Se os módulos faltarem, carregue-os com sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre e torne o carregamento permanente, porque um reinício que esquece o auxiliar transforma um túnel a funcionar de novo no erro 619. A regra de encaminhamento só precisa de aceitar o protocolo 47 para o endereço do servidor, não para toda a LAN. A definição em RFC 2637 separa o caminho de controlo e o de dados, e é por isso que nenhum ecrã de encaminhamento de portas descreve o PPTP por completo.
Caixa de passagem ou regra de protocolo explícita
Uma caixa de passagem que só abre a firewall está mais próxima do correto do que um ALG que reescreve identificadores de chamada. A metade da firewall é previsível, porque o protocolo 47 ou é aceite ou é descartado, e os contadores dizem qual. A metade da reescrita é onde os fabricantes diferem, porque os identificadores de chamada do PPTP são por túnel e um NAT que os edita tem de seguir cada chamada que toca. Quando um cliente liga e dois não, o ALG é o primeiro suspeito.
Uma regra de NAT de destino para o 1723 também tem um problema de propriedade. Se uma regra antiga ainda envia o 1723 para um host que deixou de executar o servidor, os pacotes caem numa porta fechada e o próprio serviço PPTP do router deixa de responder, o que se lê como uma falha da firewall mas na realidade é um destino obsoleto. Leia a regra e o destino antes de acrescentar uma segunda. Nos routers que terminam PPTP eles próprios, a regra WAN compete com o serviço integrado, por isso escolha um único proprietário para o 1723 e o protocolo 47.
Dois clientes atrás do mesmo NAT são o caso que separa um encaminhamento simples de um engenhoso. Encaminhar o protocolo 47 sem reescrever os identificadores de chamada costuma comportar-se melhor do que um auxiliar que tenta corrigi-los.
Meça o túnel antes de culpar o router
O PPTP reduz a carga útil, e essa redução é aritmética, não mistério. Cada pacote do túnel transporta um cabeçalho IP exterior, um cabeçalho GRE melhorado, um cabeçalho PPP e, com cifra, um cabeçalho MPPE. Quando o caminho não consegue transportar a trama resultante, os pacotes pequenos passam, o início de sessão conclui-se e a sessão para a primeira vez que uma transferência de ficheiro ou um handshake TLS envia um pacote de tamanho completo.
Calcule o número em vez de o adivinhar. O GRE melhorado custa 8 bytes, o PPP custa 4, o MPPE custa 4 e o cabeçalho IP exterior custa 20, por isso o túnel come 36 bytes antes de qualquer carga. Numa WAN PPPoE que termina em 1492, o maior PPP MTU que cabe é 1492 menos 36, ou seja 1456. Defina mtu e mru nesse valor nas opções PPP e teste de novo com um ping sem fragmentação.
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd
O ping mede o caminho, não o túnel: 1464 bytes de carga mais 28 bytes de cabeçalhos IP e ICMP preenchem exatamente uma trama de 1492 bytes. Se esse ping falhar, baixe o número até passar e subtraia 36 ao resultado. Um MTU do túnel definido acima do limite do caminho produz o congelamento sem uma única linha de registo que mencione o tamanho.
PPTP, L2TP/IPsec ou OpenVPN no mesmo router
O mesmo router pode transportar qualquer dos três túneis habituais, e a diferença está no que tem de exprimir. O PPTP precisa de duas regras em duas camadas diferentes. L2TP sobre IPsec precisa de UDP 500 e 4500 para a troca de chaves e, a menos que o NAT-T o transporte, do protocolo 50 para a carga. O OpenVPN precisa de uma só porta UDP e de nenhum auxiliar.
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
A coluna do L2TP não é automaticamente mais amigável do que a do GRE. O ESP é o protocolo IP 50 e também não tem porta, por isso um router que tem dificuldades com o protocolo 47 pode tê-las com o protocolo 50 pelo mesmo motivo. O NAT-T existe para envolver o ESP dentro de UDP 4500, e quando ambos os extremos o suportam a regra do protocolo 50 torna-se desnecessária. Isso é uma propriedade dos extremos, não da caixa PPTP do router. Confirme que encapsulamento o cliente negociou realmente antes de escrever regras para os dois.
O OpenVPN é a opção com menos peças móveis do lado do router. Uma porta UDP, um encaminhamento, nenhum auxiliar de seguimento de ligações e nenhuma reescrita de identificadores de chamada. A troca é um cliente que tem de ser instalado em vez de um marcador integrado, e é muitas vezes a única razão pela qual o PPTP permanece na conversa.
O que reparar e o que substituir
Corrigir o encaminhamento e o MTU dá-lhe um túnel que funciona, não um que deva manter. A autenticação MSCHAPv2 do PPTP é atacável há anos, e um túnel a funcionar move credenciais que podem ser recuperadas offline. Se o dispositivo remoto consegue executar L2TP/IPsec ou OpenVPN, trate a reparação como uma medida temporária com data.
A decisão resume-se ao que o extremo remoto suporta e a quanto tempo o arranjo tem de durar. Um aparelho antigo que só fala PPTP recebe a reparação; tudo o que consiga instalar um cliente é migrado.
Antes de fechar o ticket, confirme que o cliente sobrevive a uma transferência grande e não só a um início de sessão, e que o router mantém a sua regra do protocolo 47 depois de um reinício. Um túnel que passa uma cópia de ficheiro e morre após a atualização de firmware seguinte nunca esteve terminado.