OpenVPN drop-in 하나가 모든 터널을 바꿨다: 인스턴스 대 템플릿

터널 하나를 위해 추가한 재시작 정책이 머신의 모든 터널에 적용되기 시작합니다. 이것은 systemd 버그가 아니라 인스턴스 drop-in과 템플릿 drop-in의 차이입니다. 파일을 어느 경로 아래에 쓰느냐가 몇 개의 서비스가 그것을 상속하는지 결정합니다.

설정보다 적용 범위를 먼저 고르세요. 두 디렉터리는 거의 똑같아 보이고, 의도한 인스턴스로 제한되는 것은 둘 중 하나뿐입니다.

증상: 한 번의 수정, 모든 터널

인스턴스 전용 drop-in은 전체 인스턴스 이름을 딴 디렉터리 아래에 있습니다. 예를 들어 [email protected] 입니다. 템플릿 drop-in은 [email protected] 아래에 있으며, 사이에 @ 기호가 있고 인스턴스 이름은 없습니다. 첫 번째는 office 에만 적용됩니다. 두 번째는 그 템플릿에서 만들어지는 모든 서비스에 적용됩니다.

템플릿 형태는 별도의 [email protected] 템플릿에는 닿지 않고, 이름에 openvpn이 들어간 무관한 서비스에도 닿지 않습니다.

적용 범위에 맞는 디렉터리 고르기

두 디렉터리 모두 /etc/systemd/system/ 아래에 있습니다. 마지막 system 구성 요소를 빼면 systemd가 시스템 재정의로 읽지 않는 경로가 되는데, 이는 올바르게 보이는 파일이 아무 일도 하지 않게 만드는 조용한 방법입니다. 전체 경로를 한 번 쓰고 다시 사용하세요.

drop-in에는 올바른 섹션 제목도 필요합니다. 서비스 설정은 [Service] 아래에 둡니다. 설정은 있지만 섹션이 없는 파일은 무시되거나 거부되고, 파일이 그 자리에서 권위 있어 보이는 동안 unit은 이전과 같이 동작합니다.

drop-in을 둘 이상 추가한다면 목적을 파일 이름에 남기세요. 사전식 순서가 병합을 결정하며, 파일이 하는 일을 말하는 이름이 그 순서를 읽을 수 있게 합니다.

쓰기 전에 병합된 unit 읽기

무엇이든 쓰기 전에 병합된 unit을 읽으세요. systemctl cat [email protected] 는 기본 unit과 적용되는 모든 drop-in을 병합 순서대로 출력합니다. 템플릿 변경을 고려할 때 두 번째 인스턴스와 비교하세요. 그 비교가 어느 서비스가 수정을 상속할지 정확히 보여 줍니다.

인스턴스 파일은 템플릿 설정을 지우지 않습니다. 둘 다 병합되므로잊고 있던 템플릿 값이 여전히 적용 중일 수 있습니다.

이름이 붙은 다른 drop-in, 런타임 설정, 패키지가 제공하는 구성도 함께 참여합니다. 마지막으로 수정한 파일이 unit 전체라고 가정하지 마세요. 병합된 출력이 곧 unit입니다.

unit 정책을 프로필 밖에 두기

unit 정책과 VPN 구성을 분리하세요. 프로필 지시문은 [Service] 아래에 있다고 해서 유효한 systemd 문법이 되지 않습니다. 재시작 설정도 .ovpn 파일에 속하지 않습니다.

이 분리는 재시작 정책이OpenVPN자체의 피어 복구와 같은 것이 아닌 이유이기도 합니다. 적용 범위를 고르기 전에 어떤 동작을 원하는지 결정하세요.

적용하고 인스턴스 확인하기

변경 후 systemctl daemon-reload 로 관리자의 정의를 다시 불러오세요. 그 재로드는 터널을 재시작하지 않고 unit 파일만 다시 읽습니다. 그다음 의도한 수명 주기 작업을 정확한 인스턴스에 적용하세요.

로드된 unit을 다시 읽고 변경한 동작을 관찰해 확인하세요. 활성 작업을 안고 있는 재시작에는 계획된 중단이 어울리며, 운영 터널에서의 빠른 테스트가 아닙니다. 재정의의 목적과 범위를 배포 옆에 기록해 다음 사람이 그 파일이 공유용이었는지 알 수 있게 하세요.

정책이 정말 공유된다면 의도적으로 템플릿으로 옮기고 끝났다고 하기 전에 두 번째 인스턴스를 확인하세요.systemd unit 참조문서는 drop-in 우선순위와 병합 순서를 설명합니다.