VPN no roteador ou encaminhamento de porta: qual vence?

O roteador encerra a VPN por conta própria, e uma regra de encaminhamento antiga ainda envia a mesma porta UDP para uma máquina na LAN. Apenas uma delas pode ser o ponto final real, e o kernel não arbitra entre elas. A tradução de destino reescreve o pacote antes de consultar o serviço local, então o processo VPN espera por tráfego que já foi enviado para outro lugar. A tarefa é decidir quem é o dono da porta e depois fazer as regras concordarem.

Uma porta, dois donos reivindicados

Um servidor VPN que roda dentro do roteador precisa de uma permissão de entrada que leve ao seu próprio socket. Uma entrada de NAT de destino para a mesma porta leva a um lugar completamente diferente: um endereço da LAN e uma decisão de encaminhamento. São pontos finais diferentes, com logs diferentes e modos de falha diferentes. A pista habitual é que uma família de endereços funciona e a outra não, porque a entrada restante foi escrita para uma única família e nunca foi revista.

Anote a reivindicação antes de editar: família, endereço externo, transporte, porta e o alvo traduzido.

A tradução ocorre antes da verificação local

O NAT de destino muda o alvo do pacote no estágio de pré-roteamento, antes de o kernel escolher entre entrega local e encaminhamento. Quando o alvo é um host da LAN, o pacote segue o caminho de encaminhamento. As regras de entrada para o socket do próprio roteador nunca são consultadas, por isso o log da VPN fica vazio enquanto o cliente espera.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Essa ordem é todo o mecanismo, e as interfaces dos equipamentos a escondem atrás de caixas de seleção sem alterá-la. O dono do destino continua decidindo qual caminho um pacote toma.

Se o host da LAN é o ponto final pretendido, o encaminhamento está correto e o roteador não deveria também escutar nessa porta.

Mantenha um mapeamento e remova o outro

Liste as entradas NAT para essa porta e família e escolha o sobrevivente:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Uma entrada TCP com o mesmo número é irrelevante para uma falha de UDP, e tratá-las como um único objeto leva a apagar a regra errada. Quando o socket local deve vencer, o dono do mapeamento conflitante remove ou reescreve essa única entrada, e a permissão de entrada para a porta do próprio roteador permanece no lugar. Encaminhamentos não relacionados, o caminho de gerenciamento e uma cópia do conjunto de regras devem todos sobreviver à mudança.

Se a VPN vive em um host separado, o encaminhamento é o objeto correto. Um serviço em contêiner ou máquina virtual pode precisar de uma porta publicada mesmo quando a caixa se chama roteador, então siga o socket e seu namespace, não o rótulo na carcaça.

Confirme o dono de fora

Teste cada família separadamente, porque uma conexão IPv6 que termina no roteador não diz nada sobre uma conexão IPv4 que uma regra obsoleta redireciona. Leia o log do serviço receptor para ver qual ponto final respondeu, e trate a mensagem de sucesso do cliente como prova fraca. É preciso um novo fluxo para um teste significativo. Envie uma sonda de um host externo com nc -zvu 203.0.113.7 1194 e leia o log do vencedor com journalctl -u openvpn@server -n 20. O ouvinte do roteador registra a conexão sozinho, enquanto um host da LAN a registra no próprio serviço.

O rastreamento de conexões mantém os fluxos existentes no mapeamento original, então uma sessão estabelecida pode sobreviver à regra que você acabou de corrigir.

Quando o ponto final pretendido responder com suas verificações de identidade normais, teste um recurso privado atrás do túnel. Alcançar o ouvinte externo é apenas o primeiro salto; o roteamento interno e a autorização da aplicação são resultados separados.