Tengo un servidor OpenVPN ejecutándose en Ubuntu en AWS y uso Tunnelblick en macOS para conectarme a él. No tengo problemas para conectarme a otros servidores VPN, pero este parece agotar el tiempo de espera o reiniciarse cada 2 minutos.
Mi perfil de OVPN:
client
dev tun
proto udp
remote ............... 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
verb 3
cipher AES-128-CBC
auth SHA256
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
Al conectarse, el servidor envía las siguientes configuraciones:
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.0.0 255.255.240.0,route 172.16.16.0 255.255.240.0,route 172.16.128.0 255.255.240.0,route 172.16.144.0 255.255.240.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 1,cipher AES-256-GCM'
(nota específicamente ping 10,ping-restart 120)
Al aumentar el nivel de registro en el cliente, parece que la conexión está enviando paquetes de datos:
2021-09-03 11:31:21.848620 UDP WRITE [62] to [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225
Sin embargo, la conexión siempre se corta después de unos 2 minutos. Estados de registro del cliente:
2021-09-03 11:40:26.121900 [cc-vpn] Inactivity timeout (--ping-restart), restarting
2021-09-03 11:40:26.122379 SIGUSR1[soft,ping-restart] received, process restarting
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 MANAGEMENT: CMD 'hold release'
Realmente no hay nada en el registro del servidor más que un reinicio de la conexión.
El tiempo de espera de 2 minutos tiene sentido dada la ping-restart 120configuración enviada al cliente, pero no tengo claro por qué cree que ha estado inactivo. ¿Qué me estoy perdiendo? ¿Existe alguna configuración en el cliente que impida que el ping se envíe correctamente al servidor?
Específicamente, agregar ping/ping-restart a la configuración del cliente no parece ayudar (supongo que el servidor PUSH lo anulará de todos modos).
¿Cómo puedo depurar esto y descubrir por qué la conexión no se mantiene activa?
Respuesta1
Esta suele ser la señal de que hay más de un cliente que está utilizando este par de clave/certificado:
- (1) se autentica
- (2) autentica; El servidor ve el mismo certificado, por lo que cree que se acaba de reemplazar la conexión y (1) ya no recibirá pings de mantenimiento de actividad.
- (1) pierde algunos pings, decide que la conexión murió y se vuelve a conectar, ahora (2) no recibirá pings
- (2) pierde algunos pings, decide que la conexión murió y se vuelve a conectar, ahora (1) no recibirá pings
Puedes ver lo que está sucediendo y también está claro cómo ping-restartinterviene aquí el tiempo de espera de inactividad establecido por.
Para que esto no suceda, debe administrar cuidadosamente su CA VPN. En particular:
- Lleve un registro de dónde están instaladas sus claves y quién está a cargo del dispositivo donde está instalada cada clave. Tener una manera de contactar a cualquier persona que tenga claves VPN activas (por ejemplo, registre su número de teléfono, correo electrónico, etc., puede configurar OpenSSL para que solicite esos datos durante la emisión del certificado y registre esos datos directamente en los certificados y el índice de CA) .
- Nunca utilice la misma clave/certificado más de una vez; nunca coloque la clave/certificadoplantillas; Si clona algún sistema, borre las claves allí. Las claves siempre deben generarse y certificarse emitidas de nuevo cada vez que se activa el sistema.desplegada.
- Si algún usuario solicita (otra) clave/certificado mientras tiene uno activo, debe explicar por qué. Es posible que hayan perdido datos antiguos porque se reinstaló el sistema operativo y olvidaron guardar la configuración de VPN; o simplemente pueden necesitar tener una VPN en una computadora adicional. O lo que sea. Al evaluar su explicación, o primerorevocarclave antigua antes de emitir otra, o emitir una clave con otro CN para evitar un conflicto.
- Eduque a sus usuarios para que siempre les notifiquen que su clave/certificado ya no se usa (se pierde o se pierde el motivo de su emisión) para que pueda revocarlo. Y luego hay que revocarlo.
- Muy importante, educar a los usuarios paraugentementenotificarle si sospechan que la clave/certificado fue robado, en cuyo caso deberá revocarlo inmediatamente.
Estas son partes de un proceso llamado "seguridad de la red". Una VPN no podría ser segura sin cierta disciplina, sin importar cuán perfecto sea su software y la criptografía de última generación que utilice.
Si alguien se pregunta por qué OpenVPN no detecta esta condición y no la informa en los archivos de registro, como se comenta a continuación: sería demasiado poco confiable y engañoso. Los registros deben contener sólo hechos sin procesar, y el único hecho bien establecido es que el mismo CN se conecta repetidamente desde diferentes ubicaciones; no debe contener ninguna suposición sobre por qué sucedió esto.
Cuando sigue los procedimientos de seguridad descritos anteriormente, el problema simplemente no ocurre. Si esto sucede, sólo podría significar que se violó el procedimiento. En ese caso, para garantizar la seguridad de la VPN, lo más seguro es asumir que la clave estuvo comprometida y revocar un certificado inmediatamente. Probablemente la VPN se romperá para alguna persona (cuya clave era), pero esa será la consecuencia natural desuIncapacidad de seguir el procedimiento establecido: no te informaron que no están usando VPN en alguna computadora y la copiaron en otra, o te robaron el certificado, lo que sea. Después de la reeducación sobre el tema, podrá emitirles un nuevo certificado.