O handshake do OpenVPN falha no Synology? Verifique o encaminhamento de LAN

O portátil informa que o handshake TLS falhou, por isso a tentação é reconstruir os certificados. Antes disso, faça uma pergunta mais aborrecida: em que porta Ethernet o Synology está realmente a escutar? Um NAS com duas portas LAN tem dois endereços, e o pacote VPN Server do DSM liga o seu ouvinte OpenVPN a um deles. Quando o router encaminha 1194 para o outro endereço, nenhum pacote chega alguma vez ao serviço, e o cliente não tem nada com que negociar.

O texto do erro engana porque descreve a última coisa que o cliente tentou, não a primeira que correu mal. Dois minutos a comparar a página do pacote com a regra do router resolvem a questão.

Encontre o endereço a que o ouvinte está ligado

O DSM rotula as suas portas como LAN 1 e LAN 2, e cada uma tem um endereço e uma sub-rede separados. Abra o VPN Server, leia a interface indicada no separador OpenVPN, depois abra o Painel de controlo e anote o endereço IPv4 que o DSM tem nessa mesma interface. São esses dois valores, não o nome de anfitrião do NAS, que o encaminhamento tem de nomear.

Um segundo cabo ligado não cria um segundo ouvinte. As duas ligações podem aparecer conectadas enquanto só um endereço aceita o tráfego, e quando as duas interfaces estão na mesma sub-rede os dois endereços diferem num dígito que ninguém relê antes de guardar uma regra.

Olhe para o próprio socket via SSH, porque é o único sítio que mostra a que o daemon se ligou realmente, em vez do que a página de definições pretende.

sudo netstat -anp | grep 1194

Edite o encaminhamento existente em vez de acrescentar outro

Duas regras para uma só porta externa deixam o router livre de escolher, e a que escolher pode mudar após uma atualização de firmware ou um reinício. Abra a regra que já existe, altere o endereço interno, guarde, depois volte a abri-la e leia o valor. Dar à regra o nome do serviço ajuda, porque uma lista de cinco encaminhamentos idênticos é a forma como o errado sobrevive.

external 1194/udp  ->  192.0.2.20:1194/udp

Mantenha a porta interna igual à porta de escuta, e mantenha o protocolo coerente. O UDP 1194 é o ouvinte predefinido, enquanto um perfil TCP precisa do seu próprio ouvinte do lado do pacote e de um encaminhamento correspondente no router. Encaminhar TCP para um serviço que só escuta UDP produz silêncio, não um erro.

Se o endereço do NAS vem do DHCP, reserve-o antes de a regra ser guardada. O fim da concessão reatribui o endereço, o encaminhamento continua a apontar para o valor antigo, e o handshake começa a falhar num dia em que ninguém tocou no NAS. Uma configuração estática do lado do NAS resolve o mesmo problema, desde que o endereço fique fora do intervalo DHCP do router.

Prove se os pacotes chegam

Inicie primeiro uma captura no NAS, depois ligue-se a partir do cliente, e leia o endereço de origem na saída. Uma captura iniciada depois da falha não mostra nada e não prova nada.

sudo tcpdump -i any -n udp port 1194

O silêncio significa que o tráfego morreu antes do serviço: um endereço interno errado, uma porta fechada na firewall do DSM, ou uma interface administrativamente desligada. Pacotes na saída significam que o encaminhamento funciona, e a falha restante vive acima da camada de rede, o que é uma área de pesquisa muito mais pequena.

A captura também nomeia a interface por onde o pacote chegou, e esse único detalhe separa uma regra dirigida à porta errada de uma regra dirigida a uma porta que não está ativa. Observe o próprio contador do router durante a mesma tentativa se ele o mostrar. Um contador que não mexe enquanto a captura fica vazia aponta para o router, enquanto um contador que mexe com uma captura vazia aponta para o caminho entre os dois dispositivos.

Quando os pacotes chegam, deixe de culpar o encaminhamento

O perfil é o suspeito seguinte, e a razão habitual é a idade. Um ficheiro .ovpn exportado contém a autoridade e o material do momento da exportação, por isso um pacote cujo certificado foi substituído mais tarde rejeitará um cliente que ainda transporta a cópia antiga.

O transporte é a outra discrepância que vale a pena verificar explicitamente, porque o perfil e o pacote são editados em locais diferentes. Mudar um perfil de UDP para TCP sem trocar o pacote deixa o cliente à espera de um ouvinte que não existe, e o cliente relata o mesmo texto genérico de handshake que relata para tudo o resto. Leia a linha proto no ficheiro, depois olhe para o protocolo selecionado na página do servidor, e só então conclua que coincidem. Ler as regras da firewall do DSM é a terceira verificação: uma regra que permite a porta a partir da sub-rede local mas não da internet é fácil de deixar para trás depois dos testes, e produz uma ligação que funciona a partir da cozinha e falha em todos os outros locais.

Teste o caminho que um utilizador remoto percorre de facto

Um cliente dentro da mesma LAN pode chegar ao NAS sem tocar nunca no encaminhamento, por isso não prova nada sobre o acesso remoto. Use um telefone com o Wi-Fi desligado, ou pergunte a alguém fora da rede, e observe o contador do router durante essa tentativa. Se a tentativa remota falhar enquanto a local funciona, o encaminhamento ou a firewall continuam em jogo.

Anote o estado que funciona enquanto funciona: porta externa, endereço interno, protocolo, interface do pacote, e o nome do perfil e a data de exportação. Quando o handshake falhar de novo, a diferença entre essa nota e a configuração atual é a falha, e ninguém tem de redescobrir qual das duas portas o serviço usa.