라우터 재부팅 후 멈춘 VPN: 달라진 세 가지

라우터가 부팅을 마치고 노트북이 같은 SSID에 다시 연결되는데, VPN은 아무것도 움직이지 않은 채 연결됨 상태에 머문다. 저장된 프로필은 온전하다. 그 아래에서 만료된 것은 경로였고, 클라이언트는 아직 옛 경로를 위해 만든 상태를 붙들고 있다.

세 가지 조건이 해결책을 결정한다. 순서대로 확인하라. 첫 조건이 이미 멈춤을 설명한다면 뒤의 확인은 헛수고다.

조건 하나: 로컬 주소가 바뀌었다

재부팅은 장치에 다른 주소를 줄 수 있다. 그러면 고정 로컬 엔드포인트로 설정된 VPN은 더 이상 존재하지 않는 연결을 계속 사용한다. 소켓을 옛 주소에 묶어 둔 클라이언트도 마찬가지다. 터널 인터페이스는 올라와 있는데 만들어 내는 모든 패킷은 쓸모없는 곳으로 간다.

클라이언트가 쓰는 주소와 인터페이스가 지금 가진 주소를 비교하라. 함께 바뀐 게이트웨이를 가리키는 기본 경로도 이름만 다른 같은 문제다.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

조건 둘: 변환된 매핑이 사라졌다

가정용 라우터는 나가는 흐름을 변환하고 그 매핑은 메모리에 있다. 재부팅은 그 전부를 지운다. 새 연결에는 무해하지만 기존 흐름이 아직 유효하다고 믿는 터널에는 치명적이다. 그러면 반대편은 아무것도 보지 못하므로 클라이언트는 조치할 수 있는 오류를 결코 받지 못한다.

keepalive가 없는 터널이 크게 실패하는 대신 조용히 멈추는 지점이 여기다. WireGuard의 문서화된 제약 도 같은 형태의 실패를 설명한다. 엔드포인트 상태가 틀리면 진단 대신 버려진 패킷이 나온다.

25초의 지속 keepalive가 일반적인 완화책이다. 유휴 타임아웃이 끝나기 전에 매핑을 갱신하기 때문이다. 이미 사라진 매핑을 고치지는 않는다. keepalive를 해결책으로 보지 말고 재연결 로직과 함께 써야 한다.

조건 셋: 공인 주소가 바뀌었다

만약 라우터 자체의 외부 주소가 바뀌었다면, 반대편에서 출발지 주소로 거르는 모든 것은 이제 다른 피어를 본다. 터널은 올라오는데 서버가 트래픽을 계속 버릴 수 있고, 이는 고장 난 클라이언트처럼 보이지만 실제로는 반대편의 정책이다.

재부팅 전후의 외부 주소를 기록하라. 둘이 다르면 문제는 클라이언트에서 허용 목록을 관리하는 쪽으로 넘어가고, 노트북에서 자격 증명을 재설정해도 도움이 되지 않는다.

올바른 순서로 복구하라

먼저 필요한 캡티브 포털 로그인을 마치고, 프로세스를 죽이는 대신 클라이언트가 지원하는 절차로 다시 연결하게 하라. 신원과 데이터 트래픽이 모두 회복되는지 보라. 같은 연결의 두 다른 단계이기 때문이다.

캐시된 페이지는 아무것도 증명하지 못하고, 스스로 다시 연결된 채팅 앱도 마찬가지다. 정말 중요한 엔드포인트를 새 요청으로 시험하라. 중단 중에도 직접 트래픽 정책은 유지하라. 재연결 시도는 차단이 아니다.

이 일이 재부팅마다 반복되면 재시도보다 기록이 중요하다. 로컬 주소, 게이트웨이, 외부 주소, 클라이언트 상태를 전후로 적고 두 열을 비교하라. 그러면 모호한 불만이 누군가 고칠 수 있는 수명 주기 버그가 되고, 매핑 타임아웃 때문에 인증서가 세 번째로 교체되는 일을 막는다.