절전 훅만으로는 VPN이 돌아오지 않는다

절전 훅에 재연결 명령을 넣으면 문제가 해결된 것처럼 보입니다. 네트워크가 존재한 뒤에 훅이 실행되고, 클라이언트가 인식하는 ID로, 클라이언트가 실제로 구현한 경로를 통할 때만 해결됩니다. 재개 후 실패의 대부분은 이 세 가지 중 하나이며, 어느 것도 훅 자체에는 오류로 나타나지 않습니다. 훅은 어느 쪽이든 성공을 반환합니다.

영으로 끝나는 스크립트는 터널이 돌아왔는지에 대해 아무것도 알려주지 않았습니다.

훅이 실행된다, 그다음은?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

각 이벤트는 전환 전과 후에 훅을 두 번 호출하며, 단계와 이벤트 이름을 넘깁니다. 최소 환경에서 root로 실행되므로 절대 경로가 필요하고 데스크톱 세션 변수는 기대할 수 없습니다. 두 호출이 빨리 반환된다는 것은 스크립트가 실행되었다는 것만 말합니다. 그 뒤에 프로필이 올라왔는지는 별도의 관찰이며 로그에 자체 증거가 필요합니다.

단계 인자를 설계의 일부로 취급하십시오. pre 단계의 재연결 시도는 머신이 모든 것을 잃으려는 순간에 일어나므로 성공할 수 없습니다.

root, 최소 환경, 잘못된 사용자

클라이언트가 사용자별로 로그인 토큰을 보관한다면, 훅을 root로 실행하면 제시할 것이 남지 않습니다. 훅이 실제로 사용하는 ID에서 상태를 확인하십시오. 데스크톱 터미널에서 시험한 ID가 아닙니다. 일부 빌드는 연결 해제 후에도 인터페이스를 잡고 있는 데몬을 남기므로 재연결이 오래된 상태에 떨어지고, 프로세스를 먼저 정리하면 깔끔하지 않은 종료를 대가로 복구됩니다. 정상 경로만 시험하면 두 동작 모두 보이지 않습니다.

훅을 절대 경로로 작성하고, root 소유 및 실행 가능으로 유지하고, 무엇을 했는지 기록하십시오. 그 로그가 없으면 다음 조사는 영에서 시작합니다.

자동 연결은 VPN 경로가 아니다

NetworkManager는 두 가지 활성화 메커니즘을 제공합니다. 프로필의 자동 연결 플래그와, 기본 프로필이 활성화될 때 시작되는 보조 연결입니다. 기본 장치 유형은 전자를 구현하고, VPN 플러그인은 역사적으로 후자만 구현했으므로 OpenVPN 프로필에서 자동 연결을 표시해도 전혀 효과가 없을 수 있습니다. 두 속성을 모두 확인한 뒤, 대신 VPN을 Wi-Fi 또는 Ethernet 프로필의 보조 연결로 붙이십시오.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd 유닛이 관리하는 WireGuard 인터페이스는 훅 대신 그 드롭인이 필요하며, 네트워크가 온라인 된 뒤에 정렬됩니다.

네트워크를 기다리되, 상한을 두고

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

재개 시 Wi-Fi가 아직 다시 결합하는 동안 터널을 요청받을 수 있어, 고정된 절전은 추측이 됩니다. 도달 가능한 주소를 기다린 뒤 프로필을 올리고, 대기를 제한해 훅이 재개 경로를 무한히 열어두지 못하게 하십시오. 숫자 인덱스보다 프로필 이름을 선호하고, 올바른 프로필이 네트워크마다 다르다면 건강한 터널이 선택을 미리 파일에 기록하게 하십시오.

재시작 폭풍도 막으십시오. 시도 횟수를 세고 멈추면 됩니다. 실패한 검사마다 반응하는 감시자는 한 번의 장애를 루프로 만듭니다.

한 번 절전한 뒤 저널에서 훅 자체의 출력을 읽으십시오. 순서를 증명하는 유일한 시험입니다.