WireGuard PersistentKeepalive: NAT 매핑을 살아 있게 유지하세요

집 박스는 터널을 열고 문제없이 클라우드 서버에 도달합니다. 클라우드 서버는 집 박스가 마지막으로 무언가를 보낸 뒤 한두 분 동안 집 애플리케이션에 도달할 수 있고, 그다음에는 멈춥니다. WireGuard 로그에는 아무것도 나타나지 않고, 핸드셰이크 오류도 보고되지 않으며, 터널을 다시 시작하면 잠시 고쳐집니다. 그 패턴은 끊긴 터널이 아니라 만료되는 매핑이며, 아래 런북은 무언가를 바꾸기 전에 그것을 확인합니다.

패턴이 유휴 상태에서의 만료임을 확인하세요

구분되는 점은 타이밍입니다. 집 피어가 트래픽을 보낸 직후 역방향 연결이 작동하고 조용한 간격 후에 실패한다면 경로는 정상이고 중간의 상태가 문제입니다. 트래픽 직후에도 한 번도 작동한 적이 없다면 잘못된 진단입니다.

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

집 피어가 무언가를 보낸 직후 처음 두 명령을 실행하고, 오 분을 기다린 뒤 다시 실행하세요. 새 엔드포인트 없이 일정대로 갱신되는 핸드셰이크 타임스탬프는 터널이 살아 있음을 알려줍니다. 바뀐 것은 외부에서 요청하지 않은 패킷이 도착하는 능력이며, 이는 터널이 아니라 경로의 속성입니다.

그다음 역방향 시도를 하고 전송 카운터를 보세요. 클라우드 쪽이 바이트를 보내는데 집 쪽이 하나도 받지 못한다면, 패킷은 클라우드를 떠나 도중의 상태 저장 장치에서 죽은 것입니다. 이것이 찾고 있는 서명입니다. 두 카운터가 모두 움직이면 터널이 패킷을 전달했고 의심 대상은 애플리케이션입니다.

keepalive를 라우터 뒤의 피어에 두세요

지속적 keepalive는 일정에 따라 작은 인증 패킷을 보내 NAT 매핑과 모든 방화벽 상태를 살아 있게 유지합니다. 설정은 나가는 패킷으로 상태를 만드는 쪽이 바로 그쪽이기 때문에 라우터 뒤의 머신에 있는 원격 피어 항목에 속합니다.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

기존 피어 섹션에 병합하세요. 같은 공개 키로 두 번째 블록을 추가하는 것은 옵션을 추가하는 올바른 방법이 아니며, wg-quick이 대신 병합해 주지도 않습니다. 문서화된 25초는 일반적인 UDP 시간 제한 아래에 있도록 선택된 예시이며, 특별한 의미가 있는 값이 아닙니다.

같은 지시문을 클라우드 쪽에 두는 것은 이 문제에 도움이 되지 않습니다. 그 피어의 패킷은 이미 공인 주소에서 오고 있으므로 중요한 방향에서 보존할 매핑이 없습니다. 트래픽만 늘고 아무것도 바뀌지 않습니다.

간격을 추측하지 말고 타이머를 읽으세요

keepalive는 상태가 만료되는 것보다 더 자주 도착하기 때문에 작동합니다. 그래서 실제로 필요한 숫자는 시간 제한이며, Linux에서는 변환을 수행하는 장치에서 읽을 수 있습니다:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

첫 번째 값은 한 방향으로만 관찰된 UDP 흐름의 시간 제한이고, 두 번째는 응답이 관찰된 뒤에 적용됩니다. 둘 다 보통 짧으며, 조용해진 매핑은 해당 흐름에 적용되는 쪽을 따릅니다.

그 숫자를 간격과 비교하세요. 30초 시간 제한 아래의 25초 keepalive는 작동하지만, 같은 keepalive는 15초 시간 제한 아래에서는 작동하지 않습니다. 아무리 재시도해도 그 산술은 바뀌지 않습니다. 일부 소비자 라우터와 이동통신사는 Linux 기본값보다 훨씬 짧은 값을 사용하며, 그래서 한 네트워크에서 작동하는 구성이 다른 네트워크에서는 실패합니다.

리스너와 방화벽을 따로 확인하세요

살아 있는 매핑은 필요하지만 충분하지 않습니다. 집 박스의 애플리케이션은 올바른 주소에서 수신해야 하고, 호스트 방화벽은 복호화 후 패킷을 허용해야 합니다.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

소켓이 터널 주소가 아니라 물리 인터페이스 주소에만 바인딩되어 있으면, 터널로 들어오는 패킷은 방화벽에 묻기도 전에 버려집니다. 이 실패는 클라우드 쪽에서 보면 매핑 문제와 똑같이 보이며, 어떤 keepalive 조정으로도 해결되지 않습니다.

허용 목록 점검은 반대 방향에서도 똑같이 중요합니다. 클라우드 피어는 응답하려면 집 터널 주소를 출발지로 허용해야 하고, 집 피어는 클라우드 주소를 목적지로 허용해야 합니다. keepalive 패킷은 인증된 트래픽이며 같은 규칙을 적용하므로, 작동하는 것처럼 보이는 keepalive가 작동하지 않는 애플리케이션과 공존할 수 있습니다.

변경을 배포하고 한계를 알아두세요

설정을 적용하고, 그것이 업데이트 방법이라면 인터페이스를 다시 시작한 다음, 즉시 테스트가 아니라 유휴 테스트를 반복하세요. 앞서 읽은 시간 제한보다 더 오래 기다리고, 역방향 요청을 하고, 양쪽 끝에서 카운터가 움직였는지 확인하세요.

간격과 측정한 시간 제한을 옆에 기록하세요. 나중에 라우터 펌웨어가 바뀌거나 모바일 연결로 옮기면 시간 제한이 달라질 수 있습니다. 메모가 있으면 값을 복사하는 대신 다시 도출할 수 있습니다. 한 줄에 숫자 두 개면 나중에 조사 전체를 아낄 수 있습니다.

지속적 keepalive는 상태를 보호합니다. 포트를 열지 않고, 허용 목록에 항목을 추가하지 않으며, 리스너를 나타나게 하지도 않습니다. 역방향 연결이 전혀 작동하지 않을 때 원인은 이 셋 중 하나이며, WireGuard 빠른 시작도 같은 좁은 용어로 keepalive 설정을 설명합니다.