DHCP 갱신 후 VPN이 끊기나요? 주소를 비교하세요

임대 갱신과 VPN 장애는 로그에서 함께 나타나는 일이 많아 사람들은 하나가 다른 하나를 일으킨다고 결론짓습니다. 시간적 일치는 사실이지만 인과성은 대개 아닙니다. 갱신은 임대를 발급한 서버로 보내는 유니캐스트 요청으로, 같은 바인딩을 계속 쓰겠다는 요청이며, 서버는 클라이언트가 주소를 하나도 바꾸지 않고도 연장할 수 있습니다. 이벤트 전후로 클라이언트 자체의 값을 살펴보면 조용히 갱신된 임대와 실행 중인 터널 아래에서 실제로 바뀐 네트워크를 구분할 수 있습니다.

끊긴 클라이언트부터 시작하세요

먼저 클라이언트의 연결 로그를 열고 끊김 시각을 초 단위로 기록한 다음 같은 분의 운영체제 네트워크 로그를 열고 인터페이스가 무엇을 했는지 순서대로 읽으세요. 이 순서가 조사의 전부입니다. 연결 끊김 전의 DHCP 이벤트, DHCP 이벤트 전의 연결 끊김, 사이에 아무것도 없는 두 이벤트는 서로 다른 세 가지 발견입니다. 터널이 이미 다시 연결되는 중에 임대만 언급하는 로그 줄은 장식이지 증거가 아닙니다.

시간선을 기억에 두지 말고 진행하면서 적으세요. 서로 다른 도구의 타임스탬프는 완벽히 일치하는 경우가 드물고, 그 차이 자체가 설명이 되기도 합니다.

이벤트 전후의 네 가지 값을 비교하세요

연결의 로컬 측면을 실제 변화를 잡아낼 만큼 잘 설명하는 값은 인터페이스 주소, 기본 게이트웨이, 리졸버 목록, 인터페이스의 동작 상태입니다. 끊김 후 일 분 안에 이들을 기록하고 터널이 건강했을 때 찍은 캡처와 비교하세요.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

주소가 그대로이고 게이트웨이도 그대로인데 리졸버 목록만 바뀌었다면 라우팅이 아니라 이름 해석을 가리키며, 애플리케이션이 호스트를 찾지 못하게 된 동안 터널은 살아남았을 수 있습니다. 게이트웨이가 바뀌었다면 로컬 네트워크 밖으로 나가는 경로가 이동한 것이고, 이전 게이트웨이를 가리키던 경로를 무효화하기에 충분합니다. 네 값이 모두 건강한 캡처와 일치하면 임대는 원인이 아니며 클라이언트 자체의 재연결 로직이 주제가 됩니다. 장애가 보이는 동안 비교를 찍으세요(재부팅 후에 찍은 건강한 캡처는 주소 이력이 달라 일치하지 않습니다).

갱신이 바꿀 수 있는 것과 바꿀 수 없는 것

RFC 2131은 갱신을 임대 시간의 절반에 원래 서버로 보내는 요청으로 설명하며, 첫 시도에 응답이 없으면 팔 분의 칠 지점에서 아무 서버에나 다시 바인딩합니다. 어느 단계도 클라이언트가 다른 주소를 얻도록 요구하지 않으며, 협조적인 서버는 보통 기존 바인딩을 연장합니다. 실제 주소 변경은 보통 다른 경로로 오는데, 서버가 갱신을 거부하거나, 클라이언트가 상태를 잃고 다시 시작하거나, 네트워크가 장치를 다른 세그먼트로 옮기는 경우입니다.

연결의 공용 측은 로컬 변화 없이도 바뀔 수 있습니다. 통신사급 변환 뒤에서는 VPN 피어가 보는 주소가 로컬 임대가 한 일과 무관하게 재할당될 수 있고, 그 재할당은 클라이언트 내부에서 로컬 네트워크 장애와 똑같이 보입니다. 로컬에서 보고된 주소를 피어 측 관측과 비교하는 것만이 둘을 구분합니다.

클라이언트가 적응하지 못할 때

전송을 이전 주소에 묶었거나, 피어로 가는 낡은 경로를 캐시했거나, 인터페이스 식별자를 저장한 클라이언트는 더 이상 존재하지 않는 경로를 계속 재시도할 수 있습니다. 이는 적응 결함이며, 호스트가 더는 도달할 수 없는 주소로 반복 재전송하는 모습으로 나타납니다. 일부 클라이언트는 설계상 이를 처리하는데, 예를 들어 WireGuard는 올바르게 인증된 패킷이 새 원본에서 도착하면 피어의 엔드포인트를 갱신합니다.

서비스를 되살리는 수동 재시작은 적응이 어디서 실패했는지에 대한 단서이지, 임대와 터널이 양립할 수 없다는 증거가 아닙니다. 시험 중에는 차단 정책을 유지해야 하며, 그렇지 않으면 시험 자체가 다른 원인의 장애가 됩니다. 클라이언트가 스스로 복구했는지, 얼마나 걸렸는지, 어느 주소를 다시 시도했는지 기록하면, 그 순서가 인터페이스에 표시되는 연결 끊김 사유보다 더 많은 것을 알려줍니다.

탓하기 전에 이벤트를 재현하세요

일정을 기다리지 말고, 임대를 해제하고 갱신하거나 동등한 통제된 이벤트를 강제해 터널이 살아남는지 관찰하며 조건을 재현하세요. 관리되는 네트워크에서는 임의의 정적 할당이 이미 그 주소를 가진 장치와 충돌할 수 있으므로 주소 변경을 네트워크 소유자와 조정하세요.

지원되는 수정 후 같은 이벤트를 반복하고 그다음 애플리케이션과 이름 조회를 시험하세요, 다시 연결되지만 DNS를 깨뜨리는 터널은 중요한 시험보다 약한 시험을 통과하기 때문입니다. 예정된 임대를 원인으로 지목하는 대신 관찰한 구체적 변화를 타임스탬프와 함께 보고하세요. 두 보고의 차이는 다음 사람이 장애를 재현할 수 있는지, 소문만 재현할 수 있는지입니다.