Uma porta OpenVPN, três serviços: por que as portas internas importam
Um túnel, três serviços, uma porta pública. Separe o ouvinte VPN externo das portas internas das aplicações e depois teste cada permissão interna isoladamente.
Uma sessão SSH, um aplicativo web e uma consulta de nome podem compartilhar uma única conexão VPN sem disputar portas. O cliente monta um fluxo criptografado até o gateway, e cada conversa de aplicação viaja dentro dele. Do lado de fora, apenas o transporte e a porta do próprio túnel ficam visíveis. Dentro, cada serviço mantém a sua própria porta e ainda precisa da sua própria permissão.
O que o fluxo externo carrega e o que ele esconde
O cliente envolve cada pacote no transporte do túnel antes que ele saia da máquina. Esse fluxo externo tem uma porta de destino, fixada quando a VPN foi configurada. Dentro do invólucro, cada pacote original mantém o endereço e a porta do serviço que procura. O gateway remove o invólucro e encaminha pelo cabeçalho interno, então o destino vê um cliente comum chegando da rede.
Uma captura na interface WAN mostra, portanto, uma conversa, não três. As portas internas só aparecem após a desencapsulação. Por isso uma única abertura de firewall pode carregar SSH, HTTPS e DNS ao mesmo tempo.
# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0
A documentação TUN/TAP cobre a passagem em que um dispositivo TUN roteado entrega pacotes IP entre o kernel e um processo do espaço do usuário. Essa passagem é o que torna o cabeçalho interno visível para o código de roteamento e de firewall do gateway. Também explica por que a porta externa não diz nada sobre quais serviços são permitidos.
O encaminhamento NAT pertence ao ouvinte, não às aplicações
Um gateway auto-hospedado atrás de NAT IPv4 precisa de uma tradução de entrada: o endereço e a porta públicos mapeados para o ouvinte VPN. Nenhuma regra é necessária para SSH, HTTPS ou DNS só porque usuários do túnel os alcançam. Publicar essas portas exporia serviços que o túnel já protege. A regra de encaminhamento descreve a alcançabilidade do ouvinte, não uma permissão para algo lá dentro.
O contrário também vale. Abrir a porta do túnel não expõe mais nada, então um serviço alcançável apenas pelo túnel mantém a sua superfície pública fechada. Essa separação costuma ser o motivo de manter o serviço privado.
A política interna é onde o acesso é realmente decidido
A criptografia protege o caminho; ela não autoriza um destino. As rotas do cliente escolhem quais prefixos entram no túnel, a política de encaminhamento do gateway decide se os pacotes podem sair dele, e o firewall mais o login do destino decidem se o serviço responde. DNS é o caso mais claro: carregar consultas não faz um resolver aceitá-las do seu pool de clientes. Cada camada pode dizer não de forma independente.
Teste cada serviço isoladamente pelo túnel. Uma consulta bem-sucedida não diz nada sobre a porta web, e uma requisição web bem-sucedida não diz nada sobre SSH.
dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]
Quando o túnel está ativo e tudo falha, leia primeiro a tabela de rotas do cliente. Quando um serviço falha enquanto os outros funcionam, a falha está naquele destino. Essas duas observações apontam para donos diferentes, e misturá-las desperdiça tempo.
O WireGuard traça a mesma linha
O WireGuard nomeia o seu ouvinte externo com ListenPort, e uma aplicação interna continua usando a porta de serviço de que precisa. AllowedIPs é um conjunto de prefixos roteados, não uma lista de portas de serviço permitidas. Lê-lo como uma lista de permissão de portas produz regras que não correspondem ao que o túnel faz. A nomenclatura é diferente; o empilhamento não é.
Permita o serviço na política de entrada local quando ele roda no próprio endpoint, ou na política de encaminhamento quando fica atrás desse endpoint. A distinção decide qual conjunto de regras vê o pacote.
A forma geral é um transporte externo com muitas conversas internas. Produtos que precisam de várias trocas externas, ou de outro protocolo IP, lembram que o padrão de porta pública única descreve este projeto e não toda VPN.