☰

OpenVPN no logra volver a conectarse con Wake-on-LAN después de un largo período de suspensión

tag-icon • tag-icon openvpn windows-10 automation
OpenVPN no logra volver a conectarse con Wake-on-LAN después de un largo período de suspensión

Tengo una RaspberryPi en la casa de mis padres con PiVPN instalado y configurado para brindar un servicio VPN personal para mí y algunos amigos. Esta VPN ha funcionado perfectamente desde el principio, la he usado con mi PC y nunca recibí ningún error.

Recientemente configuré otra computadora con Windows10 en casa de mis padres, para que actúe como servidor para varios propósitos (en caso de que esté relacionado con este tema, lo uso como servidor multimedia doméstico con Plex Media Server y también como Repositorio Git para uso personal). Necesito que se conecte automáticamente a la VPN, así que hice lo siguiente:

  1. Configuré PiVPN para generar el archivo .ovpn correspondiente, instalé el cliente GUI OpenVPN en la nueva máquina servidor e importé el archivo ovpn. De hecho, configuré IP estáticas para todas las conexiones a mi VPN porque quiero que siempre tengan las mismas IP.
  2. Configuré OpenVPN para conectarse automáticamente al inicio del servidor. Logré esto colocando un enlace directo a la GUI de OpenVPN en esta carpeta C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp, y ese enlace directo tenía este argumento"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect ServerW10.ovpn

  3. Configuré el BIOS del servidor para que se inicie automáticamente cada vez que vuelva la CA (de modo que el servidor se inicie nuevamente si se corta la electricidad) y también lo configuré para iniciar sesión automáticamente en el usuario que creé al instalar Win10. Entonces, con esto, es de esperar que el servidor siempre inicie sesión cada vez que esté encendido.

  4. Como me preocupa el consumo de energía en la casa de mis padres, configuré este servidor para que entre en suspensión después de 3 horas de inactividad (configuraciones de Windows 10) y en suspensión siempre (con un script por lotes) al llegar a las 2 a.m.

  5. Debido a la suspensión automática, configuré el BIOS para aceptar paquetes Wake-on-LAN para reactivar el servidor. Probé esto varias veces y funcionó muy bien. De esta manera podía activar el servidor cuando lo necesitara durante 3 horas (suficiente para mis propósitos).

  6. Pasé unos días probando el servidor: poniéndolo en suspensión manualmente, dejándolo en suspensión después de 3 horas de inactividad, forzando el apagado, etc., y OpenVPN siempre funcionó bien y se volvió a conectar sin problemas.

Ahora el problema apareció cuando probé la conexión VPN al servidor después del "suspensión de las 2 a.m.". Desperté el servidor y luego intenté hacer ping como de costumbre con su IP VPN estática pero no pude alcanzarlo. Inicié sesión a través de TeamViewer para comprobar qué estaba pasando y cuando abrí la interfaz gráfica de usuario de OpenVPN, encontré que estaba atascado en un bucle como este:

Thu Mar 01 10:26:28 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Mar 01 10:26:28 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Mar 01 10:26:28 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Thu Mar 01 10:26:29 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Mar 01 10:26:29 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:26:29 2018 UDP link local: (not bound)
Thu Mar 01 10:26:29 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:29 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:27:29 2018 TLS Error: TLS handshake failed

Thu Mar 01 10:27:29 2018 SIGUSR1[soft,tls-error] received, process restarting
Thu Mar 01 10:27:34 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:34 2018 UDP link local: (not bound)
Thu Mar 01 10:27:34 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:28:34 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:28:34 2018 TLS Error: TLS handshake failed
etc...

Probé la VPN con mi PC y funciona bien como siempre, así que lo mejor es que es culpa del servidor.

Personalmente, creo que tal vez tenga algo que ver con el script por lotes que hice y programé para ejecutarse a las 2 a.m. para poner la PC en suspensión a las 2 a.m., porque no tuve problemas con otros métodos de suspensión (suspensión manual y suspensión por inactividad). El script por lotes se ve así:

rundll32.exe powrprof.dll,SetSuspendState 0,1,0

Utilicé este script porque vi un tutorial sobre cómo hacer un script por lotes para esto. Como dice ese tutorial, también ejecuté el siguiente comando para dormir en lugar de hibernar:

Powercfg -H OFF

¿Cual podría ser el problema?

Respuesta1

Finalmente lo solucioné, aunque tuve 2 problemas en mi configuración.

En primer lugar, la "Configuración de VPN" tenía un problema: el servidor OpenVPN (el RaspberryPi con PiVPN) estaba en la misma subred que la máquina del servidor.

El archivo de configuración .ovpn apuntaba a mi DNS personal, por lo que la máquina servidor, para poder conectarse a la VPN de RaspberryPi, tenía que llegar al DNS y luego llegar a mi RaspberryPi a través de la IP pública del enrutador de mis padres (que había vinculado con mi enrutador) . Esto es un problema porque todo el tráfico VPN se redirige a través de un puerto UDP fijo a la IP local de la RaspberryPi, lo que significa que las respuestas que la RaspberryPi envió a la máquina servidor, cuando llegaron al enrutador, terminaron en la RaspberryPi debido al puerto UDP redirigido, por lo que la máquina servidornunca recibí una respuesta.

Arreglé esto abriendo el archivo .ovpn y modificando la línea que contenía la URL de destino para conectarme a la VPN desde esto:

remote my.personal.dns {port_number}

a esto

remote {local_raspberry_pi_IP} {port_number}

Además, el script de suspensión tenía algún error con la configuración de OpenVPN, y no estoy muy seguro de por qué, pero creo que tuvo algo que ver con la desactivación de la hibernación. yo descarguéMicrosoft PsHerramientase hice un nuevo script para poner la PC en suspensión a las 2 a.m. El nuevo script se ve asíC:\{path_where_pstools_was_extracted}\PsTools\psshutdown.exe -d -t 0 -accepteula

Con estas modificaciones el servidor finalmente funciona como se esperaba.

Respuesta2

Como su PC (servidor) con Windows podría conectarse a la VPN en Pi todas las demás veces, realmente no creo que la redirección de puertos (¿reenvío?) Fue lo que le causó el problema aquí. Además, el hecho de que puedas acceder a la VPN (en Pi) usando una IP local indica que podría haber un problema con tu enrutador. Es posible que su dirección IP pública haya cambiado mientras tanto y su registro DNS no se haya actualizado.

información relacionada