Ajuste o cliente VPN do Linux ao protocolo do aparelho antigo

Quatro famílias de protocolos cobrem quase todos os aparelhos que ainda estão num rack, e cada uma falha de forma diferente no Linux. As portas publicadas e as propostas configuradas do extremo remoto decidem o pacote, não a distribuição que você executa por acaso. Instalar o que um post de fórum menciona e depois editar até algo conectar é como uma tarde desaparece. Leia o aparelho, instale em segundo, verifique em terceiro.

Anote o que o extremo remoto publica

Anote o protocolo, as portas e a autenticação que o aparelho espera antes de abrir um gerenciador de pacotes. Quatro famílias cobrem a maior parte do equipamento antigo, e a tabela abaixo é toda a decisão numa tela.

O manual e as regras de firewall do próprio aparelho são mais confiáveis que o nome do protocolo na página de login. Um aparelho que anuncia IPsec pode falar apenas IKEv1, e uma versão de firmware que ninguém aplicou pode ser a que finalmente acrescenta IKEv2. Confirme o caminho de dados e também a porta de configuração, porque é aí que equipamento antigo e redes modernas divergem. Errar neste passo significa depurar o cliente contra um recurso que o outro extremo nunca teve.

PPTP: prove o GRE antes de editar o pppd

PPTP no Linux não é um daemon que se inicia, mas uma chamada ao pppd, e os parâmetros de conexão vivem num arquivo peer nomeado que o pppd lê quando é chamado. As distribuições ainda o empacotam, embora as fraquezas conhecidas do protocolo o tornem inadequado para qualquer coisa sensível, então mantenha-o estritamente para um aparelho que não ofereça nada mais. Observe o GRE enquanto o cliente negocia, com uma captura curta em vez de um palpite. A falha que mais consome tempo não é a autenticação, mas o caminho de dados ausente.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Se a configuração termina e o link nunca transporta tráfego, suspeite do caminho GRE antes de tocar nas credenciais. Grupos de segurança de nuvem precisam de uma regra explícita para o protocolo 47, e algumas redes o bloqueiam por completo sem erro visível. Teste a partir da rede que você realmente vai usar, não de um laboratório que permite tudo.

L2TP/IPsec: uma proposta certa vence dez tentativas

Leia o log do daemon em vez da caixa de diálogo do desktop, porque a caixa funde várias falhas distintas numa só mensagem. Um erro NO_PROPOSAL_CHOSEN pertence à primeira fase: o cliente ofereceu uma criptografia, um hash ou um grupo Diffie-Hellman que o servidor não aceitará. Enumere o que o aparelho suporta e escreva uma proposta que combine, porque combinações aleatórias costumam produzir o mesmo erro mais devagar. Num desktop, o cliente prático é o plugin L2TP do NetworkManager com strongSwan ou Libreswan por baixo.

Uma string de proposta que para um plugin de desktop significa uma coisa pode significar outra para o daemon a quem entrega o trabalho, então mantenha a sintaxe adequada à camada que você edita. Se o aparelho também exigir um segredo de túnel, essa é uma etapa separada da chave IPsec. Confirme qual das duas a interface pede antes de digitar qualquer coisa nela.

IKEv1 agressivo com XAuth, e o caso do portal

Um extremo no estilo FortiGate geralmente quer modo agressivo com XAuth e um endereço em modo configurado, algo que um plugin gráfico pode não expor de forma alguma. O daemon nativo dá conta disso, e o bloco abaixo é a forma dessa configuração, não um arquivo completo. Consulte a documentação atual do fornecedor para os valores da proposta.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

As versões antigas do strongSwan usavam xauth=client onde a versão 5 usa leftauth2=xauth, então um trecho copiado pode falhar só pela sintaxe. Para um portal TLS, o openconnect, que fala o protocolo AnyConnect, trata do Cisco e da maioria das marcas renomeadas, e precisa de um dispositivo TUN e dos privilégios para configurá-lo. Passe o endereço do portal exatamente como o navegador mostra, incluindo qualquer caminho que o aparelho espere, e depois confira o endereço atribuído antes de testar qualquer coisa atrás dele. Criar a interface de antemão elimina uma classe de surpresas durante a configuração.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Conecte, depois verifique numa ordem fixa

Execute exatamente um gerenciador de VPN por vez, porque um perfil do NetworkManager e um daemon iniciado à mão brigarão por rotas e DNS. Derrube o perfil antes de testar uma conexão manual, e confirme que nenhuma interface de túnel antiga sobreviveu. Depois verifique nesta ordem: endereço do túnel, rota até o único host interno de que você precisa, resolução de nomes e, por fim, uma requisição real. Um ícone verde prova a autenticação e nada mais.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Se um passo falhar, pare ali em vez de testar o próximo, porque uma falha de DNS a jusante de uma rota quebrada não ensina nada. Salve uma cópia do perfil que funciona antes de experimentar, porque um arquivo de conexão apagado se perde fácil e é penoso de reconstruir. Mantenha os valores da proposta na mesma nota do modelo do aparelho e da versão de firmware, porque essa nota é a diferença entre uma migração e um projeto de arqueologia quando a caixa é substituída.