노트북이 깨어난 뒤 OpenVPN이 죽는 이유는?

머신을 절전 상태로 보냈다가 다시 깨운 다음, 어떤 설정도 건드리기 전에 이 순서로 세 가지를 확인하세요. tun0 이 아직 있는지, 내부 주소로 가는 경로가 여전히 그것을 선택하는지, 서버가 아직 이 피어를 목록에 올려 두는지입니다. 경로가 다른 곳을 가리키는데 장치만 살아 있다면 그것은 잔여물이지 터널이 아닙니다. 경로가 맞는데도 트래픽이 죽는다면 결함은 터널 위에 있고 클라이언트를 다시 시작해도 달라지지 않습니다. 재시작 자동화는 수동 테스트로 세 경우 중 어느 것인지 확인한 뒤에야 의미가 있습니다.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

자동화하기 전에 깨어남을 재현하세요

잠자기는 장치를 제거하는 것보다 암호화된 세션을 끝내는 일이 더 잦습니다. 터널을 살려 두던 UDP 흐름이 멈추고, 서버가 피어를 버릴 수 있으며, 클라이언트는 알아채고 다시 연결하거나 뒤에 아무것도 없는 인터페이스를 그대로 유지합니다. 인터페이스만 확인하는 것으로는 거의 증명되지 않습니다. 왜냐하면 오래된 장치는 작동하는 장치와 똑같이 보이기 때문입니다 패킷이 실제로 그 위를 지나가야 할 때까지는요. 경로 조회와 실제 요청 하나를 터널로 보낸 뒤, 깨어난 시점 전후의 저널을 읽으세요.

클라이언트가 스스로 돌아오면 훅은 신뢰성이 아니라 군더더기를 더합니다. 결코 복구되지 않는다면 자동화가 정직한 해법입니다.

systemd 슬립 훅이 실제로 있는 곳

오래된 안내서 많은 곳은 /etc/pm/sleep.d 를 가리키지만, 이는 pm-utils 소유의 디렉터리이고 systemd 기반 절전이 참조하는 곳이 아닙니다. systemd는 /usr/lib/systemd/system-sleep/ 와 /etc/systemd/system-sleep/ 에서 훅을 읽고 첫 번째 인자로 단계, 두 번째로 동작을 넘기므로 훅이 분기하는 값은 pre 와 post 뿐입니다. 패키지 파일을 고치는 대신 로컬 사본을 /etc 아래에 두고, 스크립트가 전환 중간에 root로 실행되므로 빨리 돌아와야 한다는 점을 기억하세요.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart 는 이미 활성 상태인 유닛에만 손을 대므로, 일부러 내려 둔 터널은 깨어남 동안에도 내려간 채로 남습니다. --no-block 는 클라이언트가 협상하는 동안 훅이 기다리지 않게 하며, 네트워크가 아직 올라오지 않았을 때 중요합니다. 두 플래그를 합치면 깨어남 전체 순서를 붙잡는 대신 조용히 실패하는 훅이 됩니다. 유닛이 이미 중지되어 있으면 아무 일도 일어나지 않으며, 그것이 바로 그 상황에서 원하는 결과입니다.

서비스를 복구하고 tun0은 그대로 두세요

tun0 를 손으로 내리면 데몬이 더 이상 소유하지 않는 인터페이스를 계속 감시하게 되고, 다음 상태 변화에서 혼란스러운 오류가 납니다. 인터페이스가 아니라 서비스나 그 연결 프로필을 대상으로 하고, 먼저 정확한 유닛 이름을 확인하세요. 배포판 패키지, OpenVPN 3, NetworkManager가 모두 다른 이름을 고르기 때문입니다. NetworkManager 프로필은 그 연결을 다시 돌리면 돌아옵니다, 그래서 거기서 대상은 systemd 유닛이 아닙니다. 어떤 메커니즘이든 손으로 검증한 것과 같은 동작이어야 합니다.

재시작은 클라이언트가 연결할 때 밀어 넣은 경로를 다시 설치합니다. 대부분의 깨어남에는 그것이 필요합니다. 자신의 경로를 추가한 머신에는 필요 없으니, 복구가 그것들을 되돌렸다고 가정하지 말고 다시 확인하고, 다음 깨어남이 찾을 수 있는 곳에 적어 두세요.

통제할 수 없는 타이밍을 다루세요

무선 연결과 DHCP는 훅이 실행된 뒤에 끝나는 일이 많아, 서버로 가는 경로가 아직 없을 때 재시작이 실패할 수 있습니다. 그 주소를 잠시 기다리고, 한 번 더 시도하고, 결과를 기록하세요.

이름 확인은 별도의 경쟁입니다. 데스크톱 네트워크 스택이 터널이 이미 올라간 뒤에 DNS를 복원할 수 있기 때문입니다. 작동하는 경로에서 추론하지 말고 resolvectl query internal.example 로 조회를 따로 테스트하세요. 올바르게 라우팅하면서 아무것도 해석하지 못하는 터널은 DNS 문제이지 훅 문제가 아닙니다.

저널에 단계, 유닛 이름, 결과를 적어 훅의 결정을 눈에 보이게 하세요. 어떤 깨어남 테스트를 돌렸는지 머신 노트에 남기면 작동하는 복구와 운 좋은 복구를 구분할 수 있습니다. 서비스를 되살리는 가장 덜 방해되는 동작을 고르고, 스스로 복구되는 클라이언트는 그렇게 두세요. 전체 재시작은 진행 중인 세션을 끊으며, 하루에 여러 번 깨어나는 노트북에서는 실제 비용입니다.