OpenVPN up에서 서비스 재시작: 훅이 tun0.device보다 낫다

종속 서비스를 tun0.device에 연결하는 것은 터널을 구독하는 것처럼 보이지만 그렇지 않습니다. 장치 유닛은 인터페이스가 존재함을 반영하며, 이는 실패한 연결과 뒤따르는 재연결 전반에 걸쳐 참으로 남을 수 있습니다. 그러면 서비스는 인터페이스가 그 사이에 사라졌는지에 따라 잘못된 순간에 동작하거나 전혀 동작하지 않습니다. 정말로 신경 쓰는 이벤트를 설명하는 훅은 OpenVPN이 호출하는 훅이지 systemd가 추론하는 것이 아닙니다.

트리거를 고르기 전에 서비스에 어떤 조건이 필요한지 결정하십시오. 세 후보는 서로 교환할 수 없습니다.

장치 유닛이 실제로 추적하는 것

systemd는 커널이 네트워크 인터페이스를 보는 관점에서 장치 유닛을 만들므로, 인터페이스가 나타나면 tun0.device이 활성화되고 제거되면 비활성화됩니다. persist-tun을 사용하면 소프트 재시작이 인터페이스를 그대로 두므로 유닛이 절대 흔들리지 않고 여기에 바인딩된 것도 트리거되지 않습니다. 지속성이 없어도 유닛은 경로, DNS 또는 원격 측이 응답하는지에 대해 아무것도 말하지 않습니다.

그래서 'VPN이 준비되었다'의 대리로서는 부적절합니다. 로컬 주소만 필요한 리스너는 인터페이스의 존재로 만족할 수 있지만, 원격 네트워크의 애플리케이션을 호출하는 서비스는 경로와 도달 가능성이 필요하며 장치 유닛은 이를 표현할 수 없습니다.

up, route-up, up-restart는 서로 다른 의미입니다

up은 TUN/TAP 장치가 열리고 인터페이스가 구성된 후 실행되며, 이는 할당된 주소를 바인딩하는 리스너에게 맞는 시점입니다. route-up은 경로가 설치된 후 실행되며 구성된 경로 지연의 적용을 받고, 경로 단계의 완료가 필요한 작업에 적합합니다. 둘 다 원격 애플리케이션이 응답함을 증명하지 않습니다. 둘 중 선택은 서비스에 무엇이 필요한가의 문제이지 어느 훅이 더 완성되어 들리는가의 문제가 아닙니다.

persist-tun에서는 재시작이 장치를 재사용하므로 up-restart이 설정되지 않는 한 up은 다시 실행되지 않습니다. 그 옵션은 문서화된 재시작 수명 주기에 up 스크립트를 활성화하며, 그 환경은 첫 시작에 비해 축소됩니다. 전체 환경을 가정하는 스크립트는 첫 연결에서 동작하고 다음 연결에서 실패합니다.

기다리지 말고 동작을 보내십시오

systemctl restart을 동기적으로 호출하는 훅은 순서가 터널을 기다리는 유닛과 교착 상태에 빠질 수 있습니다. systemctl --no-block try-restart vpn-dependent.service은 작업을 대기열에 넣고 반환하므로 훅이 자신이 반응하던 연결을 차단하지 않습니다. try-restart은 실행 중인 유닛에만 작용하고, restart은 비활성 유닛도 시작합니다. 습관이 아니라 의도적으로 선택하십시오.

대기열에 넣는 것은 검증이 아닙니다. 작업이 수락되는 즉시 훅이 성공을 반환하므로 확인은 대상 유닛의 저널이나 실제 리스너 상태에서 이루어져야 합니다.

재시작 정책은 훅이 아니라 유닛에 있습니다

RemainAfterExit=yes이 있는 oneshot 유닛은 명령이 끝난 후에도 활성으로 남고, 두 번째 시작 요청은 아무것도 하지 않습니다. systemd가 이미 시작된 것으로 보기 때문입니다. 이것은 설계로 다루어야 할 속성이지 반복적인 시작 호출로 우회할 결함이 아닙니다. 동작이 연결마다 실행되어야 한다면 유닛은 그것을 허용하는 형태여야 합니다.

After=은 유닛의 순서를 정하고 BindsTo=은 수명을 묶지만, 어느 것도 'VPN이 다시 연결될 때마다 이것을 재시작하라'는 뜻이 아닙니다. 터널에 바인딩된 유닛은 터널이 멈추면 멈춥니다. 터널이 돌아와도 무언가가 다시 시작하지 않는 한 스스로 재시작하지 않습니다.

한 번이 아니라 세 번의 재연결을 테스트하십시오

콜드 부팅, 전체 클라이언트 재시작, 소프트 재연결은 각각 다른 경로를 연습합니다. 소프트 재연결이야말로 빠진 up-restart, 축소된 환경 또는 비활성이 된 적 없는 장치 유닛을 드러냅니다. 세 가지를 모두 실행하고 양방향을 확인하십시오: 터널이 올라오면 서비스가 동작하고, Wi-Fi 로밍 같은 무관한 링크 변경에는 재시작되지 않습니다.

종속 서비스가 귀하의 관리 접근을 운반한다면 독립적인 복구 경로를 유지하십시오. 귀하가 연결된 대상을 재시작하는 훅은 귀하를 잠글 수 있는 변경입니다.