Netgear OpenVPN: TUN e TAP escutam em portas diferentes

Um telemóvel liga-se à VPN do router sem queixas, e um portátil que usa um perfil da mesma página de transferência esgota o tempo. Nada nos certificados mudou entre essas duas tentativas, porque o portátil nunca chegou ao ponto em que os certificados importam. O router publica escutas separadas para TUN e TAP, e um perfil funcional tem de escolher a que pertence ao seu próprio tipo de dispositivo.

Decidir qual de três falhas candidatas perseguir é todo o trabalho aqui: a porta, o tipo de dispositivo ou a negociação da cifra do canal de dados.

Três coisas que têm de coincidir

O tipo de dispositivo, a linha de interface do perfil e a porta de escuta formam uma única escolha, não três. Um perfil que declara dev tun e aponta para a escuta TAP não consegue concluir a sessão, e o contrário falha de forma idêntica. Para o seu modelo e firmware, leia a porta na própria página VPN do router e não num guia, porque os números mudam entre versões. Anote o modelo e a versão de firmware junto a esse número para que a pessoa seguinte possa verificá-lo.

Relatos de campo mencionam um par como 12973 para TUN e 12974 para TAP num firmware, e um número diferente noutro. Leia-os como prova de que as versões diferem, não como constantes a copiar. O perfil precisa então do nome de anfitrião adequado à distância: o nome DNS dinâmico do router em vez de um endereço WAN que vai mudar.

Depois de corrigir a porta e a linha de interface, o perfil parece uma configuração de cliente normal com uma linha remote e uma linha dev. Se as duas não coincidirem, nenhuma quantidade de tentativas produz uma sessão.

Leia o registo na ordem em que é impresso

Um cliente OpenVPN relata os eventos na ordem em que acontecem, por isso a última linha antes do silêncio identifica a camada a inspecionar. Quando a execução termina em TLS Error: TLS key negotiation failed, ou simplesmente espera por uma primeira resposta e desiste, a comparação de certificados nunca aconteceu. Isso aponta para a acessibilidade, para a escuta ou para uma porta que não tem nada por trás. Nada disso se repara substituindo o ficheiro CA.

Uma execução que chega a VERIFY OK e depois falha está noutro sítio por completo, com as suas próprias causas. Separar esses dois desfechos antes de tocar em ficheiros evita o clássico desvio pelos pacotes de certificados que nunca foram consultados. Uma vez concluído o handshake mas sem o túnel a subir, olhe para a negociação da cifra em vez da acessibilidade.

Acrescente a lista de cifras que um cliente moderno espera

Os clientes OpenVPN recentes recusam os valores predefinidos antigos que o firmware doméstico ainda oferece, e o sintoma é uma falha de negociação imediatamente após um handshake bem-sucedido. A correção é uma linha de perfil que nomeia o que o cliente aceitará: defina data-ciphers para AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 e AES-128-CBC nessa ordem. Qualquer algoritmo que o router não implemente simplesmente nunca é selecionado, por isso uma lista mais longa não custa nada além de uma negociação um pouco mais longa.

Enumerar cifras não ensina ao router uma que ele não tem. Se a negociação continuar a falhar, verifique se a página do router tem a sua própria definição de cifra e se essa definição inclui pelo menos uma entrada que o cliente aceite. Duas listas sem membro comum produzem exatamente a mesma falha que uma porta errada, e é por isso que ambas as pontas merecem uma olhada.

Importe uma vez em vez de editar cópias à mão

Importar o ficheiro corrigido para o NetworkManager evita uma pasta cheia de perfis ligeiramente diferentes: nmcli connection import type openvpn file client.ovpn, e depois ative-o pelo nome. Guarde o perfil importado como a única cópia que edita, e elimine os duplicados que se acumulam com transferências repetidas.

Depois teste de fora da LAN. Ligar-se a partir da mesma rede prova muito pouco, porque o tráfego pode nunca atravessar o túnel. Confirme que um pedido sai realmente pelo router, não apenas que o cliente mostra um estado ligado.

Decida o que fazer com os avisos

O firmware doméstico costuma cunhar a sua própria autoridade de certificação, e os clientes queixam-se da verificação de formas que o firmware não consegue suprimir. Avalie se essa queixa importa para o que está a proteger em vez de tratar cada aviso como fatal, e não desative a verificação globalmente para silenciar uma única mensagem. Um aviso que avaliou é um risco documentado; uma definição de verificação que desativou não está documentada.

Quando o firmware não oferece nenhuma forma suportada de corrigir um aviso que realmente importa, essa lacuna defende alojar a VPN noutro sítio. Escolher entre reparar o perfil, aceitar o aviso e mudar o ponto final é uma decisão sobre quanto confia nesse certificado. Tome-a deliberadamente e anote qual opção escolheu, em vez de ir clicando em diálogos até o ícone ficar verde.