OpenVPN에서 persist-tun과 persist-key가 실제로 살아남기는 것
두 옵션 모두 살아 있는 프로세스 안에서의 소프트 리셋을 다룹니다. 중지 후 인터페이스를 유지하지 않으며 트래픽 차단 정책도 아닙니다.
서비스를 중지하면 persist-tun 이 설정되어 있어도 인터페이스가 제거됩니다. 이것은 옵션이 문서대로 작동하는 것이지 실패가 아닙니다. 이 옵션은 실행 중인 프로세스 안의 한 가지 재시작 경로를 설명하며, systemctl stop 은 그 경로가 아닙니다.
두 이름을 함께 읽으면 설계가 분명해집니다. 하나는 디스크립터를 유지하고 다른 하나는 키 자료를 유지하며, 둘 다 권한을 내려놓은 뒤에 일어나는 일 때문에 존재합니다.
두 리소스와 그것들이 속한 리셋
OpenVPN은 두 가지 평범한 상황에서 자체 재시작을 알립니다. 명시적인 SIGUSR1 이 그렇게 하고, 죽은 피어가 일으킨 ping-restart 도 같은 일을 합니다. 둘 다 프로세스를 살려 두고 연결 설정을 다시 실행하며, 바로 여기서 이 옵션들이 제 몫을 합니다.
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
이 두 옵션이 바꾸는 것은 소프트 리셋 행뿐이며, 그것들이 건너뛰는 작업은 분주한 링크에서 비싼 부분입니다. 장치를 다시 열면 그에 붙은 주소와 경로가 무너지고, 그것들을 다시 만들면 리셋이 시작될 때 이동 중이던 패킷이 떨어질 수 있습니다. 중지는 같은 객체들을 보존할 옵션 없이 파괴합니다.
이 옵션들이 애초에 왜 존재하는가
강화된 OpenVPN 서버는 보통 root로 시작해 키와 장치를 열고, 그다음 권한이 없는 사용자로 내려갑니다. 그 강하 이후에는 일부 작업이 그냥 사라집니다. 모드 0600 키 파일 읽기, 네트워크 인터페이스 생성, 경로 변경은 모두 거부될 수 있습니다.
persist 옵션이 없다면 ping-restart 를 일으킬 만큼 오래 조용한 피어가 바로 그 작업들을 강제합니다. 구성에 아무것도 바뀌지 않았는데도 재연결은 실패합니다. 프로세스는 이유 없이 죽는 것처럼 보이고, 로그에는 네트워크 오류 대신 권한 오류가 표시됩니다.
그것들이 있으면 소프트 리셋은 권한 있는 단계가 이미 얻은 것을 다시 사용합니다. 마법은 없고 프로세스는 아무것도 살아남지 않습니다. 리소스 획득이 그저 미뤄질 뿐입니다.
마지막이 아니라 첫 번째 오류를 읽으십시오
리셋이 실패하면 마지막 대신 첫 번째 오류를 읽으십시오. 보호된 키, auth 파일, 인터페이스 ioctl, 외부 훅은 네 가지 다른 리소스입니다. 하나를 유지한다고 다른 것에 대한 접근을 알 수 없습니다. 방화벽 도구를 호출하는 훅은 여전히 그 도구가 요구하는 권한이 필요합니다.
훅에는 자체 스위치가 있습니다. OpenVPN 설명서는 persist 옵션을 up-restart 과 짝지으며, 이것이 재시작 후 up 및 down 스크립트를 다시 실행할지 결정합니다. 따라서 올라와 있는 인터페이스는 리졸버 통합이 갱신되었는지에 대해 아무것도 알려주지 않습니다.
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0이 두 명령은 두 가지 실패 모드를 몇 초 만에 분리합니다. 존재하지만 경로가 빠진 인터페이스는 훅 또는 경로 문제입니다. 사라진 인터페이스는 프로세스가 실제로 끝났다는 뜻입니다.
유지된 인터페이스는 kill switch가 아닙니다
트래픽이 절대 터널 밖으로 나가서는 안 된다는 요구라면, 유지된 장치는 그것을 제공하지 않습니다. 다른 주소 패밀리의 경로, 두 번째 기본 경로, 프로세스가 완전히 종료되는 경우는 모두 이 옵션의 범위 밖에 있습니다.
두 요구를 분리해 다루십시오. 재연결 사이에 터널 객체를 유지하는 것은 데몬에게 편의입니다. 터널이 내려가 있을 때 나가는 트래픽을 차단하는 것은 자체 규칙과 자체 테스트를 가진 방화벽 정책입니다. 둘을 혼동하면 방어적으로 보이면서 최선의 재연결처럼 동작하는 구성이 됩니다.
진단하기 전에 사건의 이름을 붙이십시오. 소프트 리셋, 실패한 연결 시도, 서비스 중지는 세 가지 행동을 가진 세 가지 사건이며, 첫 번째만이 이 옵션들이 설명하는 것입니다.