재부팅 후 VPN 서버 복구 테스트: 먼저 무엇을 확인할까

아무도 로그인하지 않은 상태에서 서버를 재부팅한 뒤, 통제하지 않는 네트워크에서 접속하세요. 이 한 번의 테스트가 복구가 진짜인지 답합니다. 누군가 손으로 명령을 실행한 뒤에야 동작하는 터널은 복구가 아니라 수리입니다. 대부분의 확인은 너무 일찍 멈춥니다. 데몬은 활성으로 보이고 인터페이스는 올라오는데 페이지는 여전히 로드되지 않습니다. 빈틈은 거의 항상 터널 주변 구성 요소의 지속성에 있고, 터널 명령 자체에는 없습니다.

네 가지 소유자, 네 가지 테스트

재부팅 전에 무엇이 터널을 되돌려야 하는지 이름 붙이세요. 실행하는 테스트와 적용하는 수정은 모두 그 답에 달려 있습니다. 흔한 소유자는 네 가지입니다. VPN 데몬의 systemd 유닛, WireGuard 인터페이스의 wg-quick 인스턴스 유닛, 컨테이너 런타임, 네트워크 관리자 프로필입니다. 소유자를 이름 붙일 수 없다면 멈추고 찾으세요. 예상된 시작 경로가 없는 재부팅 테스트는 무언가 일어났다는 것만 알려줍니다.

소유자마다 설정을 두는 곳이 다릅니다. systemd가 관리하는 OpenVPN 서버는 시작할 때 설정을 읽으므로 부팅 시점의 파일 내용이 그대로 실행됩니다. wg-quick 인터페이스는 같은 파일에서 주소, 라우트, DNS를 얻습니다. 따라서 셸에서 손으로 올리고 유닛으로 활성화한 적이 없는 인터페이스는 돌아오지 않습니다. 컨테이너는 진입점을 되돌리지만 호스트 방화벽 변경은 컨테이너 밖에 있지 않는 한 되돌리지 않습니다.

먼저 기준선, 그렇지 않으면 결과는 의미가 없다

동작하는 동안 상태를 기록하세요. 터널의 주소, 클라이언트 서브넷 라우트, NAT 또는 포워딩 규칙, 수신 소켓, 포워딩 sysctl입니다. ip addr show wg0, ip route, nft list ruleset 또는 iptables-save, ss -lunp, sysctl net.ipv4.ip_forward 이면 대부분의 호스트에 충분합니다.

서비스가 실행 중인지만이 아니라 어떻게 시작하도록 설정되어 있는지 기록하세요. systemctl is-enabled wg-quick@wg0 과 systemctl is-active wg-quick@wg0 은 다른 질문에 답하며, 부팅 시 중요한 것은 활성화 상태입니다. systemctl(1) 에 설명된 대로입니다. OpenVPN 의 경우 호스트가 어떤 템플릿을 쓰는지 확인하세요. openvpn@server 과 openvpn-server@server 는 기본값이 다른 서로 다른 유닛입니다.

재부팅을 실행하고 첫 실패를 읽어라

직접 고른 시간대에 의도적으로 재부팅하세요. 콘솔이나 대역 외 경로를 열어 둔 상태에서 합니다. 최종 상태가 아니라 사건의 순서를 보세요. 호스트 도달 가능, 유닛 활성화, 인터페이스 존재, 라우트 설치, 방화벽 규칙 존재, 수신 대기 연결, 클라이언트 수락. 일어나지 않은 첫 단계가 발견이며, 그 뒤의 모든 것은 잡음입니다.

터널을 쓸 수 없는데 데몬이 활성일 수 있고, 이것이 가장 흔한 잘못된 통과입니다. 유닛이 network-online.target 이 아니라 network.target 만 기다리면 네트워크가 온라인되기 전에 시작이 끝날 수 있습니다. 인증서, 키, CRL 같은 참조 파일은 마운트나 비밀 경로가 아직 준비되지 않아 그 시점에 읽히지 않을 수 있습니다. 두 문제 모두 유닛 저널을 읽기 전에는 systemctl status 에 나타나지 않습니다.

호스트 밖에서 테스트하세요. 같은 LAN의 클라이언트는 원격 클라이언트가 절대 쓰지 않을 라우트로 성공할 수 있고, 머신에 대한 SSH 세션은 터널에 대해 아무것도 증명하지 않습니다. 접속하고, 내부 이름을 확인하고, 사설 리소스에 도달한 뒤, 폐기 상태와 키가 여전히 유효한지 확인하려고 한 번 더 접속하세요.

수정을 결정하는 세 가지 조건

터널은 돌아오는데 클라이언트가 아무것도 닿지 못하면 실패는 라우팅이나 NAT 지속성에 있습니다. 클라이언트가 핸드셰이크조차 완료하지 못하면 실패는 인터페이스나 인증 자료에 있습니다. 서비스가 전혀 시작하지 않으면 실패는 유닛 파일이나 그 의존성에 있습니다. 이 세 갈래는 서로 다른 수정으로 이어지므로, 기준선 없는 무모한 재부팅은 아끼는 시간보다 더 많은 시간을 씁니다.

설정의 소유가 있는 곳에서 수정하세요. 포워딩은 sysctl drop-in에, NAT 규칙은 부팅 시 로드되는 규칙 집합에 넣고, 유닛은 시작하는 대신 활성화하며, 비밀은 유닛이 시작되기 전에 존재하는 경로에 두세요. 유닛에 대기를 더하는 것은 의존성을 선언하는 대신 숨기는 것입니다.

결과를 런북에 기록하라

무엇이 스스로 돌아왔는지, 무엇을 시작해야 했는지, 빈틈이 얼마나 지속됐는지 적으세요. 검증에 쓴 정확한 명령을 포함해, 다음 사람이 새로 만들지 않고 테스트를 반복하게 하세요. 어떤 단계에 수동 명령이 필요했다면 그 명령은 설정에 속하며 런북의 영구 단계가 아닙니다.

그다음 테스트는 호스트 네트워크 스택의 다음 변경 이후로 예약하세요. 육 개월 뒤의 달력 날짜가 아닙니다. 당신이 막으려는 실패 모드는 영구적으로 느껴진 임시 명령이며, 그것은 누군가 방화벽 규칙을 편집하거나 서비스를 새 유닛으로 옮길 때 정확히 나타납니다.