Que portas VPN abrir numa firewall: protocolo por protocolo

Duas regras separadas decidem se um túnel VPN sobrevive a uma firewall: a porta que o cliente marca e o protocolo que transporta a carga. Abra só a primeira e o túnel autentica-se, mas depois não move dados. O mínimo é uma porta TCP mais GRE para PPTP, duas portas UDP mais ESP para L2TP/IPsec e IKEv2, e uma única porta para SSTP, OpenVPN e WireGuard. A direção, o acompanhamento de estado e o NAT decidem o resto.

Comece pela porta que o cliente marca

Cada família tem um ponto de entrada que o cliente contacta primeiro, e é esse ponto de entrada que a sua regra de permissão tem de nomear. Os clientes PPTP ligam-se a TCP 1723. O L2TP/IPsec inicia IKE em UDP 500 e passa a UDP 4500 quando se usa a travessia de NAT, com a própria trama L2TP em UDP 1701 dentro do túnel. O SSTP envolve a sessão em TLS sobre TCP 443, o IKEv2 negocia em UDP 500 e 4500, o OpenVPN usa UDP 1194 por omissão mas é muitas vezes movido para TCP 443, e o WireGuard escuta em UDP 51820.

Trate esses números como valores por omissão e não como propriedades fixas. Uma interface WireGuard usa a porta de escuta que a sua configuração declarar, e um servidor OpenVPN pode ficar em qualquer porta que o administrador tenha escolhido. Leia a configuração do servidor antes de escrever a regra, porque uma firewall aberta para 1194 não serve de nada a um servidor que foi movido para 443.

A terceira coluna é onde a maioria dos pedidos de alteração corre mal. A regra existe, mas aponta para o destino errado, para a direção errada ou para o transporte errado.

GRE e ESP são números de protocolo, não portas

O GRE e o ESP não têm porta nenhuma, por isso um formulário de firewall que só aceita números de porta não os consegue exprimir. O GRE é o protocolo IP 47 e o ESP é o protocolo IP 50, ambos emparelhados pelo campo de protocolo do cabeçalho IP. Uma regra escrita como porta TCP 47 não corresponde a nada, e é assim que uma política PPTP parece correta e ainda assim descarta todos os pacotes após o aperto de mão.

Os routers domésticos escondem isto atrás de uma caixa de passagem que instala a regra de protocolo e, no caso do GRE, o auxiliar de NAT necessário para mapear o fluxo. Numa firewall a sério, é você que acrescenta o protocolo: permita o protocolo IP 47 para o servidor PPTP, permita o protocolo IP 50 para a porta de ligação IPsec. Onde a plataforma não oferece campo de protocolo, a encapsulação é a saída, e é por isso que o IKEv2 pode recuar para UDP 4500 e que o OpenVPN e o WireGuard nunca encontram o problema.

Verifique a que a regra corresponde realmente antes de culpar o cliente. Um contador de pacotes que fica a zero na porta de ligação diz que a regra nunca disparou, e nenhuma reinstalação do lado do cliente muda isso.

A direção, o estado e o NAT mudam a resposta

Um cliente que marca para fora e uma porta de ligação que escuta para dentro são requisitos diferentes, e a mesma lista de portas pode estar certa numa direção e errada na outra. Uma firewall com estado segue o fluxo UDP em 500 e 4500 e deixa as respostas voltar sem uma segunda regra. O ESP e o GRE não transportam portas, por isso um dispositivo NAT não tem onde pegar e precisa de um auxiliar ou de uma encapsulação para seguir a sessão.

A travessia de NAT é a parte que fica esquecida. O IKEv2 começa em UDP 500, deteta um dispositivo NAT e continua em UDP 4500, pelo que uma política que só permite 500 dá um túnel que se estabelece e depois cala. O L2TP/IPsec faz o mesmo movimento. Se a sua captura mostra a primeira troca mas não tráfego contínuo, procure uma regra que pare em 500.

Registe a direção com cada regra. «Permitir UDP 4500» não significa nada até dizer de onde para onde, e uma regra correta para um cliente itinerante costuma estar errada para um par local-a-local.

Verifique cada caminho com uma captura

Execute a captura na porta de ligação, não no cliente: um cliente só registra o que chegou. Estes filtros cobrem as famílias acima e mostram que etapa falta:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Leia a saída como uma sequência. Quando a negociação aparece mas o protocolo de carga não, o descarte acontece algures entre o cliente e a porta de ligação. Quando ambos aparecem e a página continua a falhar, a firewall já não é a suspeita; olhe para o encaminhamento, o DNS ou o conjunto de endereços entregue ao cliente.

Numa máquina sem tcpdump, as mesmas provas vêm dos contadores de interface e de regras. Bytes que entram mas não saem na interface do túnel apontam para o caminho de volta e não para a regra de permissão inicial.

Deixe um conjunto de regras que consiga defender

O SSTP em TCP 443 é indistinguível de um HTTPS comum para qualquer filtro baseado em portas, e é exatamente esse o objetivo quando uma rede só permite tráfego web. É também por isso que a regra do 443 deve nomear a porta de ligação como destino em vez de toda a internet. Apague as regras temporárias de qualquer-para-qualquer assim que o túnel funcionar. Anote que regra correspondeu, o número de protocolo onde houver e a direção, para que a pessoa seguinte comece com provas.

As portas de ligação de nuvem ponto-a-local tornam a escolha visível: o perfil descarregado usa ou SSTP em 443 ou IKEv2 em 500 e 4500, e só deve abrir o que o perfil escolhe de facto. O PPTP não vale a exceção de GRE numa rede moderna, já que as operadoras móveis descartam muitas vezes o protocolo 47 independentemente da sua firewall. Antes de fechar o pedido, confirme que a regra corresponde à porta na configuração do servidor, que o campo de protocolo está definido onde a família precisa e que o destino é a porta de ligação e não um endereço qualquer.