WireGuard가 유휴 후 실패합니다: 먼저 방향을 시험하세요

설정을 바꾸기 전에, 클라이언트가 활성일 때 같은 자원이 되는지, 유휴 기간이 얼마나 길었는지, 기기가 잠들었거나 네트워크를 바꿨는지, 실패가 상대편에서 시작한 트래픽에만 나타나는지 하는 네 가지를 물어야 합니다. 답은 만료된 NAT 매핑을 잠든 라디오나 오래된 앱과 구분해 줍니다. keepalive가 애초에 관련 있는지도 알려 줍니다. 명령 하나면 되고 가능한 원인의 절반을 없애므로 방향부터 시작하세요.

어느 방향이 실패하는가?

클라이언트의 새 나가는 요청과 조용한 기간 뒤에 그쪽으로 들어오는 트래픽은 상태를 가진 장비를 다르게 시험합니다. 나가는 패킷은 떠나면서 매핑을 다시 만들고, 들어오는 패킷은 옛 매핑이 살아남았기를 요구합니다. 이 비대칭이 시험의 전부입니다. 클라이언트가 밖으로 나갈 수는 있지만 들어오는 것이 없으면 매핑이 만료된 것이고, 둘 다 안 되면 터널이나 클라이언트의 네트워크 접근이 사라진 것입니다.

조용한 기간이 얼마나 지속됐는지, 그동안 기기가 잠들었거나 다른 네트워크로 옮겼는지 기록하세요. 이 두 사실이 어떤 설정보다 먼저 진단을 바꿉니다.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

각각이 질문의 다른 부분에 답하므로 조용한 기간 전과 후에 그 세 가지를 실행하세요. 움직이지 않은 handshake 시각은 양쪽이 대화를 멈췄다고 말하고, 바뀐 엔드포인트는 매핑이 죽은 것이 아니라 옮겨졌다고 말합니다. 전송 카운터는 무언가 도착했는지 보여 주며, 그것이 오래된 매핑과 조용한 앱의 차이입니다. 비교가 증거이므로 두 시점 모두 숫자를 적어 두세요.

잠, 라디오, 앱 상태

휴대폰이나 노트북에서 잠든 기기는 네트워크 접근을 완전히 잃었을 수 있고, keepalive는 꺼진 라디오를 되살리거나 충족되지 않은 캡티브 포털을 끝낼 수 없습니다. 모바일 플랫폼은 정책상 백그라운드 작업을 중단하므로 주기적 트래픽이 계속되는지는 플랫폼과 앱이 그것과 협상한 내용에 달려 있습니다. 캐시된 연결은 세 번째 경우이자 가장 오해를 부르는 경우인데, 터널이 돌아오는 것은 앱이 거기에 다시 연결되는 것과 같지 않기 때문입니다.

유휴 기간 뒤에는 열어 둔 탭을 믿지 말고 앱을 다시 여세요. 옛 세션이 실패한 곳에서 새 요청이 성공하면 터널은 처음부터 문제가 아니었습니다.

keepalive가 실제로 하는 일

PersistentKeepalive는 인증된 빈 패킷을 주기적으로 피어에 보내, WireGuard 빠른 시작이 설명하는 대로 피어 사이의 NAT 매핑을 살아 있게 하고 상대편 엔드포인트를 최신으로 유지하기에 충분합니다. 그것은 잠든 라디오, 잃어버린 경로, 결코 다시 시도하지 않는 앱을 고치지 않습니다. 간격은 지원되는 클라이언트 설정으로 고르고, 상태 표시가 조용해졌다는 이유만으로 모든 곳에서 공격적인 값을 켜지 마세요.

대부분의 유휴 기간은 실패가 아닙니다. 오 분의 침묵 뒤에 다시 연결되는 터널은 올바르게 동작하며, 문제는 상대편에서 무언가 도착해야 했던 경우뿐입니다.

예전에 실패하던 간격을 기다리세요

지원되는 변경을 하나만 하고, 그 자원을 다시 시험하기 전에 같은 유휴 기간이 지나게 하세요. 기다림은 시험의 일부이며 형식이 아닙니다. 다시 연결이야말로 상태를 초기화하는 사건이므로 다시 연결된 직후의 성공은 긴 유휴 증상에 대해 아무것도 말하지 않습니다. 문제가 활성 사용 중에도 나타나면 주기적 트래픽을 더 넣지 말고 handshake와 데이터 경로 점검으로 돌아가세요.

시험마다 변경을 하나로 유지하고 사용한 유휴 시간을 적으세요. 그러지 않으면 이후의 모든 비교가 어긋나고 어떤 변경이 중요했는지 아무도 말할 수 없습니다. 네 가지 사실, 즉 방향, 시간, 잠 상태, 앱 동작을 함께 기록하세요.