vpnc contra Check Point ou Nortel: por que ele trava
o vpnc só fala IKEv1 com XAuth. Um gateway Check Point SNX ou Nortel Aventail nunca chega à fase das credenciais, então identifique primeiro o produto.
O sintoma é fácil de interpretar mal: o vpnc inicia, pede a palavra-passe do grupo e depois fica parado num passo de negociação até relatar que não há resposta do destino. Nada na saída menciona o produto do gateway, e a conta funciona a partir do navegador, portanto a conclusão óbvia é uma palavra-passe errada ou uma porta bloqueada. Na maioria destes casos o gateway não é sequer um par IPsec, pelo que a troca nunca chega a testar as credenciais. Vale a pena testar esse padrão antes de alterar qualquer outra coisa no perfil.
Identifique o produto antes de editar outro campo do perfil.
A falha parece credenciais erradas
O vpnc começa por enviar IKE para UDP 500 e, se for oferecida travessia NAT, para UDP 4500. Um gateway que termina SSL em vez de IPsec não responde a nenhum dos dois, pelo que o cliente tenta novamente e acaba por desistir com um erro genérico. Se a mesma conta funcionar através de um portal de navegador que carrega uma pequena aplicação auxiliar, é um forte indício de que o túnel se baseia em SSL e de que o cliente está a fazer a pergunta errada.
Uma tentativa falhada aqui não diz nada sobre a conta de utilizador, porque nunca foram apresentadas credenciais ao gateway.
Verifique que protocolo o gateway oferece
Dois minutos de sondagem separam um par IPsec de um portal SSL. Execute-os a partir da mesma rede que o cliente vai usar e leia que portas respondem, em vez de quais aparecem num documento. Guarde o resultado, porque são essas mesmas portas que decidem que cliente o proprietário do gateway deve suportar. Sonde a partir da rede do cliente e não de um anfitrião ao lado do gateway.
nc -zvu gw.example.com 500 nc -zvu gw.example.com 4500 nc -zvt gw.example.com 443 curl -sI https://gw.example.com/ | head -5 openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20
Uma 443 aberta com um redirecionamento para uma página de início de sessão e silêncio em 500 e 4500 aponta para uma SSL VPN. As 500 e 4500 abertas com um certificado servido em 443 sugerem um gateway IPsec que também executa uma interface web, e é esse o caso para o qual o vpnc foi construído.
O SSL Network Extender da Check Point e o cliente Aventail da Nortel pertencem ambos à segunda categoria, e nenhum deles aceita um segredo de grupo IKEv1.
O que o perfil do vpnc pode e não pode exprimir
Debaixo do capô, o vpnc executa IKEv1 contra uma chave pré-partilhada de grupo e depois envia as credenciais do utilizador individual através do XAuth. Tudo no seu ficheiro de configuração pertence a essa troca: gateway, nome do grupo, segredo do grupo, nome de utilizador e palavra-passe de utilizador. Esses campos descrevem um único protocolo, e nenhuma combinação deles pode fazer o cliente falar outro.
É por isso que alargar a lista de cifras ou desativar as verificações de certificados nunca corrige este tipo de falha. Essas alterações enfraquecem uma negociação que o gateway não está a escutar.
Escolher o cliente que corresponde ao gateway
Para um gateway Check Point, use o pacote SNX compilado para essa versão do gateway, que o fornecedor publica juntamente com a documentação de acesso remoto. As compilações SNX mais antigas falham frequentemente nas distribuições atuais porque esperam bibliotecas de 32-bit que já não estão instaladas, e remendar um pacote abandonado costuma ser pior do que executar o cliente suportado numa plataforma suportada.
Os clientes Aventail perderam o suporte há muito tempo. Onde um gateway desses ainda está em serviço, as escolhas realistas são o portal de navegador se a organização o ativar, ou o cliente suportado do fornecedor num sistema operativo suportado.
Pergunte ao proprietário do gateway pelo produto e pela versão, pelo cliente que suporta em Linux e se existe sequer um perfil IPsec. Se existir, peça o identificador de grupo e o segredo de grupo como itens separados, porque não são a palavra-passe do utilizador e um par trocado é a outra causa comum de um túnel falhado. Quando uma ligação finalmente funcionar, registe que protocolo foi negociado, para que a pessoa seguinte parta de um facto em vez de repetir a mesma suposição.