O síntoma létase facilmente mal: vpnc arrinca, pide o contrasinal do grupo e logo queda nun paso de negociación ata que informa de que non hai resposta do destino. Nada na saída menciona o produto da pasarela, e a conta funciona desde o navegador, así que a conclusión obvia é un contrasinal incorrecto ou un porto bloqueado. Na maioría destes casos a pasarela non é en absoluto un par de IPsec, así que o intercambio nunca chega a probar as credenciais. Paga a pena probar ese patrón antes de cambiar calquera outra cousa no perfil.

Identifique o produto antes de editar outro campo do perfil.

O fallo parece credenciais incorrectas

vpnc comeza enviando IKE a UDP 500 e, se se ofrece atravesar NAT, a UDP 4500. Unha pasarela que remata SSL en lugar de IPsec non responde a ningunha das dúas, así que o cliente reintenta e acaba rendéndose cun erro xenérico. Se a mesma conta funciona a través dun portal de navegador que carga unha pequena aplicación auxiliar, é un sinal forte de que o túnel se basea en SSL e de que o cliente fai a pregunta equivocada.

Un intento fallido aquí non di nada sobre a conta de usuario, porque nunca se presentou ningunha credencial á pasarela.

Comprobe que protocolo ofrece a pasarela

Dous minutos de sondaxe separan un par de IPsec dun portal SSL. Execúteos desde a mesma rede que usará o cliente e lea que portos responden, non cales aparecen nun documento. Garde o resultado, porque eses mesmos portos deciden que cliente debería soportar o propietario da pasarela. Sondee desde a rede do cliente e non desde un equipo xunto á pasarela.

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

Un 443 aberto cunha redirección a unha páxina de inicio de sesión e silencio en 500 e 4500 apunta a unha SSL VPN. Os 500 e 4500 abertos cun certificado servido en 443 suxiren unha pasarela IPsec que tamén executa un frontend web, que é o caso para o que se construíu vpnc.

O SSL Network Extender de Check Point e o cliente Aventail de Nortel están ambos na segunda categoría, e ningún acepta un segredo de grupo de IKEv1.

Que pode e que non pode expresar o perfil de vpnc

Baixo o capó, vpnc executa IKEv1 contra unha clave precompartida de grupo e logo envía as credenciais do usuario individual por XAuth. Todo no seu ficheiro de configuración pertence a ese intercambio: pasarela, nome do grupo, segredo do grupo, nome de usuario e contrasinal de usuario. Eses campos describen un só protocolo, e ningunha combinación deles pode facer que o cliente fale outro.

Por iso ampliar a lista de cifrados ou desactivar as comprobacións de certificados nunca corrixe esta clase de fallo. Eses cambios debilitan unha negociación á que a pasarela non está escoitando.

Escoller o cliente que encaixa coa pasarela

Para unha pasarela Check Point, use o paquete SNX compilado para esa versión da pasarela, que o provedor publica xunto coa súa documentación de acceso remoto. As compilacións SNX antigas fallan a miúdo nas distribucións actuais porque esperan bibliotecas de 32-bit que xa non están instaladas, e parchear un paquete abandonado adoita ser peor que executar o cliente compatible nunha plataforma compatible.

Os clientes Aventail perderon o soporte hai moito tempo. Onde unha pasarela así segue en servizo, as opcións realistas son o portal de navegador se a organización o habilita, ou o cliente compatible do provedor nun sistema operativo compatible.

Pregunte ao propietario da pasarela polo produto e a versión, polo cliente que soportan en Linux e por se existe algún perfil IPsec. Se o hai, solicite o identificador de grupo e o segredo de grupo como elementos separados, porque non son o contrasinal do usuario e un par intercambiado é a outra causa habitual dun túnel fallido. Cando unha conexión por fin funciona, anote que protocolo se negociou para que a seguinte persoa parta dun feito en lugar de repetir a mesma suposición.

Artigos relacionados