VPN 유닛이 네트워크보다 먼저 시작했다가 죽는 이유

머신을 부팅하고 로그인하면 터널이 올라왔다가 몇 초 뒤에 죽어 있는 경우가 있습니다. 프로필은 정상이었고 인증서도 정상이었으며, 남은 유일한 흔적은 그 부팅의 저널입니다. 보통 일어난 일은 경쟁입니다. 유닛이 머신에 주소가 생기기 전에 시작했고, 선언한 순서는 겉보기와 다른 의미였습니다. 아래의 모든 내용은 그 경쟁을 증거로 증명하고 제대로 닫는 방법에 관한 것입니다.

대상은 만남의 지점이지 관리자가 아니다

network-online.target는 네트워크가 무엇인지 모릅니다. 이것은 링크가 사용 가능해질 때까지 시작을 지연시켜야 하는 서비스를 모으는 조정 지점이며, 정의는 머신을 소유한 네트워크 관리자에게 위임합니다. 대부분의 데스크톱과 서버에서는 NetworkManager나 systemd-networkd가 제공하는 대기 서비스를 뜻합니다. 둘 다 활성화하지 않으면 대상은 기다릴 것이 없으므로 무언가가 끌어들이는 순간 완료되며, 그 시점은 DHCP가 응답하기 훨씬 전일 수 있습니다. 유닛의 순서 줄은 정직했지만 여전히 쓸모가 없었습니다.

따라서 첫 질문은 유닛이 무엇을 선언하는지가 아닙니다. 이 머신에서 실제로 무언가가 대기를 수행하고 있는지입니다.

유닛 파일이 아니라 마지막 부팅을 읽으세요

유닛 파일은 의도를 설명하고, 저널은 무슨 일이 있었는지 설명합니다. 그 부팅만, 단조 타임스탬프와 함께 요청해 모든 메시지가 한 시계에 놓이게 하세요. 그다음 두 줄을 찾습니다. 터널 유닛이 시작되기 시작한 순간과, 주소가 나타나거나 대기 서비스가 끝난 순간입니다. 그 두 숫자를 정렬하면 경쟁은 확인되거나 배제됩니다.

의존성 보기가 이를 뒷받침합니다. 터널 유닛의 중요한 체인에 대기 서비스가 없다면 그 경로에서는 아무것도 시작을 지연시키지 않았고, 대상은 가정한 일을 하지 않은 것입니다. 두 가지 보기, 하나의 결론.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

대기를 추가하고, 그다음 재시도를 추가하세요

패키지된 유닛을 편집하는 대신 drop-in을 사용해, 패키지 업데이트가 변경을 조용히 버리지 않게 하세요. 두 지시문이 중요합니다. 유닛은 대상 뒤에 정렬되어야 하고, 대상을 같은 트랜잭션으로 끌어와야 합니다. 순서만으로는 대상을 불러오지 않으며, 원하는 것이 그것을 합니다.

OpenVPN 클라이언트의 패키지된 유닛은 이미 둘 다 갖추고 있습니다. 손으로 쓴 유닛은 보통 하나 또는 아무것도 갖추지 않으므로, 무엇이든 추가하기 전에 확인할 가치가 있습니다.

[Service]
Restart=on-failure
RestartSec=15

고정 sleep이 함정인 이유

ExecStartPre의 sleep은 순서 수정처럼 느껴지고 추가 단계가 있는 지연처럼 행동합니다. 건강했던 부팅을 포함해 모든 부팅을 느리게 만들고, 링크가 선택한 숫자보다 오래 걸리면 여전히 집니다.

더 나쁘게도 대기 서비스가 작동하는지를 숨기므로, 다음 실패는 같은 문제의 다른 타이밍이 아니라 완전히 새로운 문제로 나타납니다. 짧은 재시작 지연이 더 나은 도구입니다. 건강한 부팅에서는 비용이 없고, 잃은 경쟁을 또 다른 시도로 바꿉니다. 간격은 적당히 유지하고 유닛이 성공하게 두세요. 영원히 재시작한다면 프로필이 망가진 것이고 아무리 재시도해도 바뀌지 않으므로, 간격을 올리는 대신 로그를 읽으세요.

순서가 맞아도 이름이 계속 실패할 때

터널 경로가 있는 활성 유닛은 순서가 제 일을 했고 남은 결함이 한 계층 위에 있다는 뜻입니다. 흔한 형태는 터널의 up 스크립트가 링크나 리졸버가 그것을 유지할 준비가 되기 전에 적용한 리졸버 설정입니다. 실패 중의 리졸버 상태와 터널 유닛을 재시작한 뒤의 상태를 비교하세요.

재시작이 조회를 고치면 잘못된 DNS 서버가 아니라 시작 순서의 결함이고, 둘은 서로 다른 수정이 필요합니다. 그런 다음 서비스 재시작 대신 콜드 부팅으로 전체를 증명하세요. 재시작은 이미 올라온 네트워크를 상대로 돌기 때문에 추적 중인 결함을 정확히 숨깁니다. 링크를 일부러 느리게 해서 반복하고, 네트워크가 빠를 때만 작동하는 유닛은 여전히 망가진 것으로 보세요.