Systemd와 NetworkManager: 부팅 시 VPN을 누가 시작하는가?

같은 이미지에서 만든 Ubuntu 두 대, 하나의 VPN 프로필, 로그인 시 정반대 결과: 한쪽은 데스크톱이 뜨기 전에 터널이 올라오고, 다른 쪽은 아예 올라오지 않습니다. 여기서 변수는 프로필이 아닙니다. 세 구성 요소 가운데 무엇이 그것을 시작하라는 지시를 받았는지가 다르며, 그 셋은 같은 스위치를 공유하지 않습니다.

나란히 비교하는 편이 추측보다 빠릅니다. 각각은 알아볼 수 있는 방식으로 실패하며, 바로 그래서 비교할 가치가 있습니다.

트리거가 다른 세 가지 기동 방식

패키지로 설치된 openvpn 서비스가 가장 오래된 경로입니다. 이 서비스의 init 스크립트는 /etc/default/openvpn에서 자동 시작 목록을 읽습니다. 그 목록이 주석 처리되어 있거나 비어 있으면, 스크립트는 여러분이 추가한 하나가 아니라 그 디렉터리에서 찾은 모든 구성을 시작합니다. 터널 하나를 위해 추가한 파일 하나가 조용히 여러 개를 올릴 수 있습니다.

사람들이 잘못 설정하는 것은 두 번째 줄입니다. NetworkManager는 가져온 프로필을 보관하고 그것을 시작하지만, 다른 연결의 세컨더리로서만 시작하므로 트리거는 VPN이 아니라 네트워크 링크에 속합니다.

설정 비용과 적용 범위를 비교하십시오

init 스크립트 경로는 한 줄이면 되고 시스템의 모든 구성을 대상으로 합니다. 라우터에는 맞고, 여러 네트워크에 붙는 노트북에는 틀립니다. NetworkManager 경로는 UUID 조회가 필요하고 터널을 하나의 기반 연결에 묶습니다. 사무실 SSID에서는 올라오고 호텔 네트워크에서는 내려간 채로 남습니다.

직접 작성한 unit은 비용이 가장 크고, 다른 서비스와의 순서까지 포함해 가장 많은 통제를 줍니다. 결정적 요인은 적용 범위입니다. 시스템에 네트워크가 하나, 터널이 하나라면 패키지 서비스가 정직하고 예측 가능합니다. 터널이 특정 Wi-Fi를 따라가야 한다면, 추가 스크립트 없이 그 조건을 표현하는 것은 셋 중 세컨더리뿐입니다.

소유자를 하나 고르고 나머지를 제거하십시오

두 소유자가 시작하는 프로필은 부팅마다 달라지는 타이밍을 만듭니다. 어느 한 방식만 쓰는 것보다 나쁩니다. 소유자를 고른 다음, 경쟁 경로를 우연이 아니라 의도적으로 끄십시오.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

정리 대상이 패키지 경로라면 순서를 지키십시오. AUTOSTART을 none으로 설정하고, 생성된 unit이 새 목록을 읽도록 systemctl daemon-reload을 실행한 다음, 더는 원하지 않는 템플릿 인스턴스를 비활성화하십시오. 다시 읽기를 건너뛰면 이전 unit이 활성 상태로 남아 변경이 효과가 없었던 것처럼 보입니다.

멈추지 않는 중지는 별개의 문제이고 답은 제한적입니다. TimeoutStopSec은 systemd가 SIGKILL을 보내기 전에 기다리는 시간을 제한합니다. 이 값을 두기에 맞는 곳은 drop-in 파일입니다. 패키지 unit을 직접 고치면 다음 업그레이드에서 변경이 사라집니다.

실제로 무엇이 시작되었는지 확인하십시오

재부팅하고 설정 파일을 믿는 대신 증거를 읽으십시오. 터널을 소유한 unit은 활성 상태와 부팅 시각에 맞는 시작 타임스탬프를 보여 주고, VPN 인터페이스는 로그인 전에 이미 존재합니다.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

여기서 한 가지 확인이 더 필요합니다. unit의 ExecStart이 여러분이 생각하는 바이너리를 가리키는지 확인하십시오. 직접 빌드한 클라이언트나 snap 패키지는 명시적 경로나 snap run 래퍼가 필요한 경우가 많습니다. systemd가 셸의 검색 순서를 물려받지 않기 때문입니다. command -v openvpn과 unit 파일을 비교하면 몇 초 안에 정리됩니다.

고른 소유자를 프로필 이름 옆에 시스템 메모로 남기십시오. 다음에 사라진 터널을 디버깅하는 사람은 같은 비교를 반복하지 않고 그 줄에서 시작합니다.