OpenVPN: 부팅 시 로컬 바인드 실패 — 기다릴까, 다시 시도할까

부팅 시 시작되지 않는 OpenVPN 서버에는 두 가지 해결책이 제시됩니다. 주소를 기다리거나, 바인드가 성공할 때까지 서비스가 다시 시도하게 하는 것입니다. 둘 다 같은 증상을 다른 실패 동작으로 다룹니다. 대기는 특정 전제 조건을 명시하고 그것이 없으면 크게 실패합니다. 재시도는 전제 조건을 숨기고 계속 시도합니다. 어느 쪽이 유닛에 맞는지는 그 주소가 설계된 의존성인지, 타이밍의 우연인지에 달려 있습니다.

둘 다 고정된 슬립보다 낫습니다. 슬립은 아무것도 기다리지 않고, 무엇을 기다렸는지도 보고하지 않습니다.

local 옵션이 실제로 요구하는 것

local는 데몬이 소켓을 바인드하는 주소를 지정합니다. 아직 존재하지 않는 주소에 바인드하면 요청한 주소에 관한 오류와 함께 즉시 실패합니다. 옵션이 없으면 데몬은 모든 주소에서 수신합니다. 그래서 인터페이스가 아직 올라오지 않은 머신에서도 같은 프로필이 동작합니다. 지정한 하나의 주소가 아니라 모든 곳에서 수신하고 있기 때문입니다. 이 차이가 곧 실패 전체이며, 재부팅 전까지는 보이지 않습니다.

요구 사항은 인터페이스가 일반적인 의미에서 올라와 있는 것이 아닙니다. 주소는 바인드하는 순간 올바른 인터페이스에 할당되어 있어야 하고, 같은 데몬이 나중에 만드는 터널이 아니라 언더레이 인터페이스여야 합니다. 로그인 몇 분 뒤에 하는 확인은 부팅 순서에 대해 아무것도 증명하지 못합니다.

주소를 기다리기 vs 바인드 재시도

대기란 주소가 나타날 때까지 폴링하는 ExecStartPre로, 시도 횟수가 제한되고 시간이 다하면 영이 아닌 값으로 종료합니다. 재시도란 메인 프로세스가 실패하게 두고 서비스 관리자에게 다시 시작하도록 요청하는 것입니다. 예를 들어 Restart=on-failure와 RestartSec=5의 조합입니다. 전자는 빠진 전제 조건을 실패한 유닛으로 보고하고, 후자는 결국 멈추는 재시작의 연속으로 보고합니다. 저널에서는 더 시끄럽지만, 예측할 수 없는 이유로 주소가 늦게 도착하는 경우에도 견딥니다.

주소가 설계된 의존성이라면 대기를, 주소가 보통 나타나지만 타이밍이 달라진다면 재시도를 선호하세요. 둘을 조합하는 것도 합리적입니다. 제한된 대기가 일반적인 경우를, 재시작 정책이 예외를 커버합니다. 둘 다 해서는 안 되는 일은 영원히 실행되는 것입니다. 무한히 재시도하는 유닛은 설정 오류를 보고하는 대신 숨기기 때문입니다.

network-online.target으로 충분하지 않은 이유

network-online.target는 활성 네트워크 구현이 online이라고 의미하는 것만 약속하며 그 이상은 아닙니다. systemd-networkd에서는 systemd-networkd-wait-online가 그 타깃 도달 시점을 결정하지만, 기본적인 online 개념은 특정 주소가 존재하기 전에 충족될 수 있습니다. NetworkManager에서는 wait-online 서비스가 자체 규칙을 적용합니다. 타깃 뒤에 정렬하는 것은 건전한 기준선이지, 하나의 주소나 DNS 응답, 원격 피어가 준비되었다는 보장이 아닙니다.

같은 논리로 흔한 대안도 배제됩니다. 데스크톱 자동 시작 항목은 서버에서 결코 열리지 않을 수 있는 사용자 세션을 기다립니다. 지연된 cron 명령은 나타나기를 기대한 리소스를 지목하지 않은 채 경과 시간만 더합니다. 둘 다 몇 달 동안 성공한 것처럼 보이다가, 정작 중요한 한 번의 부팅에서 실패합니다.

콜드 부팅 후 바인드를 확인하세요

서비스 재시작이 아니라 실제 콜드 부팅으로 검증하세요. 재시작은 부팅 순서가 만들어야 했던 주소를 물려받기 때문입니다. 부팅 후 ss -lntp 또는 ss -lunp는 각 리스너가 실제로 바인드한 로컬 주소를 보여 주고, journalctl -b -u openvpn-server@server는 첫 시도가 실패했는지 보여 줍니다. 바인드된 주소를 프로필의 주소와 비교한 다음, 네트워크 재연결 후에 비교를 반복하세요.

프로필에 고정 주소가 전혀 필요 없었다면 local를 제거하는 것은 정당한 단순화입니다. 다만 그것을 문제 해결 습관이 아니라 보안 결정으로 만드세요.

리스너를 넓히면 누가 접근할 수 있는지가 바뀝니다. 그러니 그 변경은 원래 그것을 제한했어야 할 방화벽 정책과 짝지으세요. 모든 인터페이스에서 안정적으로 시작하는 서비스는 원래 문제를 해결한 것이 아니라, 문제를 네트워크 경계로 옮긴 것입니다.