네트워크가 준비되기 전 OpenVPN이 시작되는 것은 실패가 아니다

부팅 시 클라이언트를 시작했고 유닛은 활성이라고 보고하지만 터널은 없다. 자연스러운 결론은 서비스가 시작에 실패했다는 것이고, 자연스러운 해결은 다시 시작하는 것이다. 둘 다 충분히 자주 틀리므로 원칙으로 삼을 만하다: 재시도 중인 실행 클라이언트는 밖에서 보면 고장 난 클라이언트와 똑같아 보인다. 차이는 프로세스가 무엇을 하는가에 있고 유닛 상태에 있지 않다.

신화: 서비스가 시작되었다는 것은 작동하는 터널을 뜻한다

활성 유닛은 프로세스가 시작되었고 종료되지 않았음을 증명한다. 프로필이 로드되었거나 인증서가 받아들여졌거나 상대편이 응답했음을 증명하지는 않는다. 패키지된 클라이언트는 몇 분 동안 재시도 루프에 머물 수 있고, systemd는 성공만 보고한다. 상태와 동작 사이의 이 간극이 주제 전체다.

반대 경우도 똑같이 흔하다. 키를 읽지 못한 뒤 프로세스가 종료되었을 수 있고, 그러면 유닛은 이유를 말해 주지 않는 실패 상태를 보고한다. 두 상태를 구별하려면 로그가 필요하다.

유닛 상태가 아니라 해당 인스턴스의 저널을 읽어라. 이유 줄은 로그에 있고 상태 레이블에는 없다.

신화: 재시도 설정이 모든 실패를 덮는다

이름 확인과 전송 재시도는 별도 기본값을 가진 별도 제어다. resolv-retry 는 원격 호스트 이름의 반복 조회를 제어하며, 문서화된 기본값은 무한히 계속 시도한다. connect-retry 은 시도 사이의 간격을 정하고, connect-retry-max 는 각 원격 항목을 시도하는 횟수를 제한할 수 있다. 이들 중 무엇이든 바꾸기 전에 로그가 어느 단계를 말하는지 확인하라.

그중 어느 것도 잘못된 프로필, 읽을 수 없는 개인 키, 거부된 계정에는 적용되지 않는다. 이런 것은 수정이 필요하며, 계속 재시도하는 클라이언트는 나아가지 않는다.

승인되지 않은 인증서를 영원히 재시도하는 것은 검증을 없앨 이유가 아니다. 오류를 읽을 이유다.

신화: 런처 하나면 충분하니 하나 더 추가하라

NetworkManager나 패키지된 유닛이 이미 관리하는 연결에는 두 번째 런처가 필요 없다. 같은 경로를 두고 경쟁하는 두 프로세스는 중복 인터페이스, 혼란스러운 로그, 아무도 볼 수 없는 이유로 흔들리는 터널을 만든다. 두 번째 사본은 보통 첫 번째가 느리다는 우회책으로 등장한다.

어느 구성 요소가 터널을 소유하는지 정하라 무엇이든 추가하기 전에. 그런 다음 다른 런처를 비활성화하고 기대하는 대신 제거하라.

소유자는 재시도와 자격 증명이 어디서 오는지도 정하므로 이 결정은 모든 튜닝보다 먼저 온다. 소유권이 먼저 오는 이유가 바로 그것이다.

실제로 순서가 필요한 것

순서는 구성된 주소를 기다릴 수 있고, 그것이 보장하는 전부다. network-online.target 는 관리자가 네트워크를 올라온 것으로 볼 때까지 활성화를 지연시키며, 올라온의 정의는 관리자에 달려 있다. VPN 호스트 이름이 확인되는지, 리스너가 응답하는지, 캡티브 포털이 장치를 들여보냈는지는 말하지 않는다.

의존성을 추가하기 전에 설치된 유닛과 모든 drop-in을 읽어라. 모든 네트워크 서비스에 대한 광범위한 After= 는 실제로 필요한 연결을 맺지 못한 채 부팅만 지연시킨다.

테스트할 수 있는 의존성의 순서를 정하고 나머지는 준비 상태 프로브로 확인하라. 터널을 여는 프로브가 추측하는 타이머보다 낫다.

터널이 처음 올라온 뒤에 일어나는 일

부팅은 여러 사건 중 하나다. 액세스 링크가 바뀌고, 포털 세션이 만료되고, 피어가 재시작된다. 내부 재연결과 서비스 관리자가 처리하는 프로세스 종료를 구별해야 하는데, 둘은 소유자가 다르고 남기는 증거도 다르기 때문이다.

대화형 인증은 무인 복구를 제약한다. 백그라운드 유닛은 데스크톱 키링을 잠금 해제하지 않고 MFA 요청에 답하지 않으므로 서비스 맥락에 승인된 자격 증명 방식을 따르라.

터널이 내려가 있는 동안 애플리케이션이 무엇을 할 수 있는지 따로 정하라. 재시도는 연결을 복구하고, 차단 정책은 그 간극에 직접 트래픽을 허용할지 결정한다.