☰

OpenVPN이 장시간 절전 모드 후에 Wake-on-LAN으로 다시 연결되지 않음

tag-icon • tag-icon openvpn windows-10 automation
OpenVPN이 장시간 절전 모드 후에 Wake-on-LAN으로 다시 연결되지 않음

저는 부모님 집에 PiVPN이 설정되어 있고 나와 몇몇 친구들에게 개인 VPN 서비스를 제공하도록 구성된 RaspberryPi를 가지고 있습니다. 이 VPN은 처음부터 완벽하게 작동했으며 PC에서 사용해 본 적이 없으며 오류가 발생하지 않았습니다.

저는 최근에 부모님 집에 Windows10이 설치된 다른 컴퓨터를 설치하여 다양한 목적의 서버 역할을 하도록 했습니다. (이 문제와 관련된 경우에는 Plex Media Server와 함께 홈 멀티미디어 서버로 사용하고 Git Repository로도 사용합니다. 개인적인 용도로). VPN에 자동으로 연결하려면 이 정보가 필요하므로 다음을 수행했습니다.

  1. 해당 .ovpn 파일을 생성하도록 PiVPN을 구성하고 새 서버 시스템에 OpenVPN GUI 클라이언트를 설치한 다음 ovpn 파일을 가져왔습니다. 사실 저는 VPN에 대한 모든 연결에 대해 항상 동일한 IP를 갖기를 원하기 때문에 고정 IP를 구성했습니다.
  2. 서버 시작 시 자동으로 연결되도록 OpenVPN을 구성했습니다. 이 폴더에 OpenVPN GUI에 대한 직접 링크를 배치하여 이를 달성했으며 C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp해당 직접 링크에는 다음 인수가 있었습니다."C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect ServerW10.ovpn

  3. AC가 다시 돌아올 때마다 자동으로 부팅되도록 서버 BIOS를 구성했고(그래서 전기가 꺼지면 서버가 다시 부팅됨) Win10을 설치할 때 생성한 사용자에 자동으로 로그인하도록 구성했습니다. 따라서 이를 통해 서버는 전원이 켜질 때마다 항상 로그인되기를 바랍니다.

  4. 부모님 집의 전력 소비가 걱정되어 이 서버를 3시간 동안 활동이 없으면(Windows 10 설정) 절전 모드로 설정하고 오전 2시가 되면 항상 절전 모드로(배치 스크립트 사용) 구성했습니다.

  5. 자동 절전 기능으로 인해 서버를 깨우기 위해 Wake-on-LAN 패킷을 허용하도록 BIOS를 구성했습니다. 나는 이것을 여러 번 테스트했고 잘 작동했습니다. 이렇게 하면 필요할 때마다 3시간 동안(내 목적에 충분함) 서버를 깨울 수 있습니다.

  6. 저는 서버를 테스트하는 데 며칠을 보냈습니다. 수동으로 절전 모드로 전환하고, 3시간 동안 활동이 없으면 절전 모드로 설정하고, 강제 종료하는 등의 작업을 했으며, OpenVPN은 항상 문제 없이 잘 작동하고 다시 연결되었습니다.

이제 "오전 2시 절전" 이후 서버에 대한 VPN 연결을 테스트할 때 문제가 나타났습니다. 서버를 깨운 다음 ​​평소처럼 고정 VPN IP로 핑을 시도했지만 연결할 수 없었습니다. 무슨 일이 일어나고 있는지 확인하기 위해 TeamViewer를 통해 로그인했고 OpenVPN의 GUI를 열었을 때 다음과 같은 루프에 갇혀 있는 것을 발견했습니다.

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...

내 PC로 VPN을 테스트했고 평소처럼 잘 작동하므로 가장 좋은 방법은 서버의 결함이라는 것입니다.

저는 개인적으로 이것이 제가 오전 2시에 PC를 절전 모드로 설정하기 위해 오전 2시에 실행하도록 만들고 프로그래밍한 배치 스크립트와 관련이 있다고 생각합니다. 다른 절전 방법(수동 절전 및 비활성 절전)에는 문제가 없었기 때문입니다. 배치 스크립트는 다음과 같습니다.

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

이에 대한 배치 스크립트를 수행하는 방법에 대한 튜토리얼을 보았기 때문에 이 스크립트를 사용했습니다. 해당 튜토리얼에서 말했듯이 최대 절전 모드 대신 절전 모드를 수행하기 위해 다음 명령도 실행했습니다.

Powercfg -H OFF

무엇이 문제일까요?

답변1

설정에 2가지 문제가 있었지만 마침내 문제를 해결했습니다.

우선, "VPN 설정"에는 한 가지 문제가 있었습니다. OpenVPN 서버(PiVPN이 포함된 RaspberryPi)가 서버 시스템과 동일한 서브넷에 있었습니다.

.ovpn 구성 파일은 내 개인 DNS를 가리키므로 서버 시스템은 RaspberryPi의 VPN에 연결하기 위해 DNS에 도달한 다음 내 부모 라우터의 공용 IP(라우터와 연결한)를 통해 내 RaspberryPi에 연결해야 합니다. . 이는 모든 VPN 트래픽이 고정 UDP 포트를 통해 RaspberryPi의 로컬 IP로 리디렉션되기 때문에 문제가 됩니다. 즉, RaspberryPi가 서버 시스템으로 보낸 응답이 라우터에 도착하면 RaspberryPi로 인해 종료된다는 의미입니다. 리디렉션된 UDP 포트로 이동하므로 서버 시스템은응답을 받은 적이 없다.

.ovpn 파일을 열고 다음에서 VPN에 연결하기 위한 대상 URL이 포함된 줄을 수정하여 이 문제를 해결했습니다.

remote my.personal.dns {port_number}

이에

remote {local_raspberry_pi_IP} {port_number}

또한 OpenVPN 설정에서 절전 스크립트에 버그가 있었는데 이유는 잘 모르겠지만 최대 절전 모드를 비활성화하는 것과 관련이 있는 것 같습니다. 다운로드했습니다Microsoft Ps도구새벽 2시에 PC를 절전 모드로 전환하는 새 스크립트를 만들었습니다. 새로운 스크립트는 다음과 같습니다C:\{path_where_pstools_was_extracted}\PsTools\psshutdown.exe -d -t 0 -accepteula

이러한 수정을 통해 이제 서버가 예상대로 작동합니다.

답변2

귀하의 Windows PC(서버)가 Pi의 VPN에 항상 연결할 수 있기 때문에 포트 리디렉션(전달?)이 여기서 문제를 일으킨 원인이라고는 생각하지 않습니다. 게다가 로컬 IP를 사용하여 Pi에서 VPN에 연결할 수 있다는 사실은 라우터에 문제가 있을 수 있음을 나타냅니다. 그 동안 공용 IP 주소가 변경되어 DNS 레코드가 업데이트되지 않았을 수도 있습니다.

관련 정보