Desconexiones de VPN
En la oficina usamos una VPN para conectarnos con ordenadores ubicados en otra ciudad. Suelo acceder a ellos a través del escritorio remoto de Windows.
Desde que llevo en el trabajo siempre había estado dando problemas. Funcionaba bien hasta que repentinamente perdía la conexión, a pesar de que el cliente VPN (de Shrew Soft) seguía mostrando «tunnel enabled». Esto me forzaba a reconectar, numerosas veces al día. La solución de otros compañeros era emplear TeamViewer para saltar a una máquina «intermedia», desde la que finalmente llegar al destino deseado. No está mal como remedio temporal, pero es un peñazo.
El último día, sin embargo, me sorprendí al comprobar que la VPN no había fallado ni una vez. Pensando qué podría haber cambiado, me di cuenta de que uno de mis compañeros tenía el día libre. Preguntando a otros colegas, me dijeron que también utilizaba la VPN (junto con el cliente VNC). Fue entonces cuando comprendí que todo este tiempo nos habíamos estado «robando» la conexión el uno al otro.
Investigando un poco, vi que los servidores VPN pueden o no admitir varias sesiones por usuario. El nuestro sólo parecía estar configurado para permitir una. Por ello, supuse que la persona que lo montó originalmente crearía varias cuentas, para que varias personas se pudiesen conectar simultáneamente.
Nuestro servidor VPN es el router Juniper SRX-240. Accedí a él para examinar la configuración:
admin@ActivaMultimedia_1# show security ike
Allí encontré varios usuarios. Cada uno tenía una sección «policy» y otra «gateway». A su vez, las «policy» de todos los usuarios hacían referencia a un único «proposal», que especifica los algoritmos de autenticación y encriptación. En «policy» aparecía la «pre-shared key», la clave del usuario. Estaban codificadas como cadenas que empezaban con «$9$», pero se pueden decodificar mediante la página http://password-decrypt.com/.
Intenté conectarme con las credenciales de uno de los usuarios. Se levantaba el túnel, pero ningún equipo respondía al ping. Estudié en detalle las conexiones VPN establecidas:
admin@ActivaMultimedia_1> show security ipsec security-associations
node0:
--------------------------------------------------------------------------
Total active tunnels: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131077 88.23.140.60 4500 ESP:3des/sha1 122341ec 3556/ unlim - 0
>131077 88.23.140.60 4500 ESP:3des/sha1 7b23b981 3556/ unlim - 0
<131097 62.97.117.164 500 ESP:aes-256/sha1 ea72953d 2741/ unlim - 0
>131097 62.97.117.164 500 ESP:aes-256/sha1 44077d9f 2741/ unlim - 0
{primary:node0}
Las dos primeras filas, con ID 131077, son mi conexión. El ID 62.97.117.164 corresponde a ATLAS, una compañía que nos brinda soporte técnico. Inspeccioné en detalle mi conexión:
admin@ActivaMultimedia_1> show security ipsec statistics index 131077
node0:
--------------------------------------------------------------------------
ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 5321
Encrypted packets: 0
Decrypted packets: 85
...
No hay ningún paquete cifrando y sí unos cuantos descifrados. Esto quiere decir que los paquetes van pero no vuelven. Lo primero que quería comprobar era si la IP destino llegaba a recibirlos o no. Para ello, utilicé el Wireshark, filtrando ICMP, e hice un ping:
Efectivamente, los paquetes ICMP llegaban y el equipo respondía. Pensé entonces que habría alguna regla en el firewall que bloqueaba el retorno de esos paquetes. Para ello:
admin@ActivaMultimedia_1# show security policies
...
policy vpn-dmarti {
match {
source-address VPN_dmarti;
destination-address [ Servidors XarxaInterna Ofimatica_ASI CPD_CCMA XarxaImagina ];
application any;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
policy vpn_meteoplay {
match {
source-address VPN_meteoplay;
destination-address any;
application any;
}
then {
permit;
}
}
El usuario que utilizábamos habitualmente para la VPN era «meteoplay». En todas las reglas, sólo aparece otra cuenta más de VPN: «dmarti». Entonces me di cuenta de mi primer fallo: yo estaba utilizando otra cuenta distinta a dmarti, una de las que encontré al ejecutar «show security ike». No funcionaba porque sólo meteoplay y dmarti tenían acceso.
Mi segundo fallo era suponer que todos los usuarios tenían asignada la misma IP. Arriba se puede ver que no: una es VPN_dmarti y la otra VPN_meteoplay. En la agenda podemos ver qué direcciones corresponden con esos nombres:
admin@ActivaMultimedia_1# show security zones
...
security-zone untrust {
address-book {
...
address VPN_dmarti 172.27.96.28/32;
...
address VPN_meteoplay 172.27.96.52/32;
Con las credenciales y la IP de la cuenta dmarti, por fin todo funcionaba correctamente. Los cambios realizados en el cliente se pueden ver a continuación:
El ping funciona y la IP origen es 172.27.96.28:
