NAS Synology com duas portas LAN: por que o handshake da VPN falha

O portátil relata uma falha de handshake TLS, que soa como problema de certificado e normalmente não é. Num NAS com duas portas Ethernet, a causa mais comum é um encaminhamento do router dirigido ao endereço onde o pacote não escuta, e a mensagem do cliente é idêntica nos dois casos. O pacote não responde na segunda porta só porque os dois cabos estão ligados. Antes de alguém reemitir um certificado, prove que um pacote chega ao NAS.

O que o cliente relata e o que realmente aconteceu

Uma falha de handshake de um cliente OpenVPN é um rótulo genérico. Abrange divergência de certificado, divergência de transporte, um ouvinte noutra porta e um encaminhamento que não entregou nada. Por isso a mensagem é inútil como ponto de partida e útil apenas como confirmação. Trate-a como a afirmação de que a sessão não foi estabelecida, e nada mais específico.

A porta e o endereço vinculado são os dois factos que decidem se um pacote chega alguma vez.

Anote ambos antes de mudar qualquer coisa, porque uma correção plausível aplicada na camada errada é a forma como um problema de quinze minutos se torna uma tarde inteira. Registe a interface, o endereço nela, a porta e o transporte. Esses quatro valores são todo o caminho de entrada, e a secção seguinte explica onde vive cada um.

Encontre o endereço onde o pacote escuta

O DSM numera as portas Ethernet e cada uma tem o seu próprio endereço. A página VPN Server indica a interface usada pelo serviço OpenVPN, e o painel de rede mostra o endereço configurado nessa interface. Leia-os nessa ordem, do serviço para fora, para descrever o que escuta em vez do que presume que deveria usar.

O serviço vincula um endereço. O facto de ambas as portas estarem ligadas e ativas não faz o serviço responder na segunda. Um endereço estático numa interface ao lado de um endereço DHCP na outra dá-lhe dois valores semelhantes fáceis de trocar num relance, sobretudo quando diferem apenas no último octeto. Copie o endereço do painel em vez de o escrever de memória. Depois confirme no NAS o que está realmente vinculado à porta.

sudo ss -lunp | grep 1194

Se essa saída indicar um endereço que não esperava, o encaminhamento aponta para a interface errada e tudo o resto aqui é contabilidade. Corrija a regra antes de ler mais, ou acabará a depurar um certificado por causa de um pacote que nunca saiu do router.

Corrija o encaminhamento e depois vigie o contador

Edite a regra de encaminhamento existente em vez de acrescentar uma segunda para a mesma porta externa. Duas regras podem coexistir na tabela de um router e só uma ganha sempre, o que transforma uma sessão de depuração numa discussão sobre qual é a verdadeira. Aponte o endereço interno para o valor que leu do NAS e deixe a porta interna a coincidir com o que o serviço escuta.

Se o DSM obtém esse endereço por DHCP, crie primeiro uma reserva. Uma mudança de concessão quebra silenciosamente um encaminhamento que funcionava ontem.

sudo tcpdump -i any -n udp port 1194

Comece a captura antes de o cliente tentar ligar-se, e leia o endereço de origem em tudo o que aparecer. Nada de nada significa que algo pelo caminho o descartou: o encaminhamento, a firewall do DSM ou a interface para onde apontava, e os certificados não podem ser a causa enquanto isso se mantiver. Algo que chega do endereço público do cliente sem resposta significa que o NAS recebeu o pedido e escolheu não responder. São constatações diferentes, e só a segunda o devolve às definições do próprio pacote.

Só então olhe para certificados e transporte

Assim que chegarem pacotes, volte a exportar o perfil após qualquer alteração de certificado, porque o ficheiro antigo ainda transporta a autoridade com que foi criado. Um perfil editado à mão para outro transporte deixa o cliente à espera de um ouvinte que não existe, e relata a mesma falha genérica que tudo o resto. Compare o transporte dentro do perfil com o transporte que o pacote está configurado para servir. Dois perfis para dois transportes é um desenho legítimo, e um perfil editado para ambos não é.

Teste de fora da sua própria rede como último passo, porque uma ligação de dentro da LAN pode ter êxito por um caminho que nunca toca o encaminhamento.

Guarde o perfil exportado, o endereço da interface e a regra de encaminhamento juntos numa nota. Quando um endereço muda, essa nota é a diferença entre uma correção e uma repetição. Nada neste caminho exigiu reinstalar um pacote, o que vale a pena recordar antes de culpar o próximo reinício.