절전 후 VPN이 죽었다: 터널이 끊겼나, 앱이 낡았나?

뚜껑이 열리고 무선 아이콘이 돌아오며 VPN은 여전히 연결됨으로 표시된다. 그다음 첫 내부 페이지는 시간 초과까지 멈춰 있고 새 탭도 마찬가지다. 세 가지 다른 원인이 그런 그림을 만들 수 있고 각각 다른 해결책이 필요하다. 잠들기를 견디지 못한 터널, 아무도 다시 활성화를 요청하지 않은 프로필, 몇 시간 전에 죽은 세션을 아직 붙들고 있는 앱이다. 이들을 비교하는 편이 무엇이든 다시 설치하는 것보다 빠르다.

깨어난 뒤 망가질 수 있는 세 가지

첫 번째 후보는 터널 자체다. 피어와의 연결이 사라져도 인터페이스는 주소를 가진 채 남을 수 있다. 그래서 표시등은 경로가 살아 있다는 증거가 아니다. 잠들기보다 오래된 핸드셰이크가 그 단서이며 확인에는 명령 하나면 충분하다.

두 번째는 활성화다. 많은 클라이언트는 스스로 다시 연결하지만 일부는 그렇지 않다. 돌아오라는 요청을 받지 않은 프로필은 구성된 얼굴로 그 자리에 앉아 있다. 그 실패는 설계상 조용하다. 아무것도 오류를 내지 않기 때문이다.

세 번째는 앱이다. 브라우저 탭, SSH 세션, 데이터베이스 연결은 아래 전송이 죽어 있어도 파일 디스크립터로서 네트워크 변경을 견딜 수 있다. 그러면 새 세션은 완벽하게 동작하며, 터널은 내내 정상이었다는 것을 알려 준다.

무엇이든 바꾸기 전에 셋을 비교하라. 해결책은 서로 겹치지 않는다. 다시 시작하라는 요청을 받은 적 없는 클라이언트를 재시작하면 필요한 증거를 버리는 셈이다. 설정을 건드리기 전에 증상이 어느 후보에 맞는지 적어 두라. 그 한 문장이 보통 나머지 조사를 결정한다.

첫째: 터널이 돌아왔는가

클라이언트의 상태 문구가 아니라 인터페이스와 피어 상태를 보라. 주소는 있지만 최근 핸드셰이크가 없는 인터페이스는 이름만 걸쳐 있는 터널이다.

ip -brief addr show
wg show
ip route show table all | head -20

인터페이스가 아예 없으면 터널은 살아남지 못한 것이고, 누가 되돌려야 했는가라는 질문이 된다. 있지만 핸드셰이크가 오래되었다면 피어와의 연결을 다시 세워야 하고, 클라이언트는 이를 깨울 트래픽을 기다리고 있을 수 있다.

경로와 DNS 설정도 확인하라. 터널은 경로 없이 돌아올 수 있다. 그러면 인터페이스는 올라와 있는데 내부 이름은 여전히 잘못된 서버로 해석되는 혼란스러운 상태가 된다.

둘째: 무언가 돌아오라고 했는가

여기서 비교가 값을 한다. NetworkManager는 OpenVPN 플러그인 프로필과 네이티브 WireGuard 연결을 다르게 다루며, 연결 설정 참조는 connection.autoconnect 이 VPN 프로필을 활성화하지 않는다고 분명히 밝힌다. 연결과 함께 VPN을 올리는 방식은 connection.secondaries 이다.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

수동으로 다시 연결하면 매번 문제가 해결된다면 그것은 고장 난 터널이 아니라 빠진 활성화의 표시다. 로그는 보통 인터페이스가 내려가고 아무것도 그것을 되돌리지 않는 모습을 보여 준다.

곧바로 절전 훅을 추가하고 싶은 충동을 참아라. 네트워크가 회복되기 전에 실행되는 훅은 도우려는 바로 그 프로세스와 경쟁하며, 재현 가능한 문제를 간헐적 문제로 바꾼다.

셋째: 앱이 낡은 상태를 붙들고 있는가

VPN을 건드리기 전에 같은 목적지로 완전히 새 세션을 열어라. 새 세션이 되고 옛 세션이 안 된다면 터널은 정상이고 앱이 죽은 연결을 붙들고 있다.

이것은 세 점검 중 가장 싸고 가장 자주 건너뛰는 점검이다. 실패하는 창이 바로 화면에 있기 때문이다. 창을 닫고 다시 열어 문제가 남는지 적어 보라. 새 세션이 되면 터널 조사를 완전히 멈춰라. 그것도 실패하면 앱은 원인이 아니라 증상이다.

일부 앱은 시간 초과 후 스스로 회복한다. 그래서 몇 분 뒤 증상이 저절로 고쳐진 것처럼 보일 수 있다. 그 행동은 터널이 아니라 앱을 가리키며 따로 기록할 가치가 있다. 그냥 저절로 고쳐졌다고 보고하는 동료는 이 패턴을 설명하는 것이지 행운이 아니다.

비교를 재현 가능하게 만들어라

변수를 작게 유지하라. 하나의 접속망, 하나의 잠들기 시간, 매번 같은 첫 요청이다. 그다음 두 결과를 기록하라. 수동 재연결이 고치는지, 한 번 더 잠들면 실패가 돌아오는지다.

마지막 관찰이 세 후보를 가장 신뢰성 있게 갈라 놓는다. 실패한 옛 세션 뒤에 새 세션이 동작하는 것은 터널 문제가 아니며, 클라이언트를 다시 설치해도 달라지지 않는다.

WireGuard의 상시 keepalive는 이 그림에서 NAT 매핑 keepalive로서만 의미가 있다. 매핑을 열어 두려고 패킷을 보내지만 기기가 잠드는 것을 막지 못하고, 프로세스가 정지된 동안 계속 보낼 수도 없다.

티켓에 찾은 것을 적어라. 셋 중 무엇이 고장 났는지, 무엇이 고쳤는지, 어떻게 재현했는지다. 월요일에 뚜껑을 여는 다음 사람이 고마워할 것이고, 답을 처음부터 다시 찾을 필요도 없을 것이다.