UDP VPN이 유휴 상태에서 멈춥니다: 방화벽이 플로를 잊었습니다

VPN이 연결되어 한동안 작동하다가, 클라이언트가 여전히 세션을 표시하는데도 트래픽 전달을 멈춥니다. 다시 연결하면 해결되므로 클라이언트 버그처럼 보입니다. 보통은 유휴 UDP 매핑을 버린 방화벽이나 NAT 장비이며, 터널이 아직 존재한다는 사실을 모릅니다.

증상은 진단할 수 있을 만큼 일관되며 부하가 아니라 비활성 상태 뒤에 나타납니다.

유휴 멈춤은 어떻게 보이는가

설명하지 말고 측정하십시오. 트래픽이 멈추기 전에 터널이 얼마나 오래 유휴 상태였는지, 새 아웃바운드 패킷이 이를 되살리는지, 클라이언트 인터페이스가 아직 주소를 유지하는지 기록하십시오. 클라이언트의 새 요청은 되는데 기존 플로에 대한 응답은 안 된다면 매핑이 용의자입니다. 다시 연결할 때까지 아무것도 안 된다면 클라이언트의 세션 상태도 사라진 것입니다.

둘 다 유휴와 관련이 있으며 서로 다른 해결책이 필요합니다.

무엇이든 바꾸기 전에 시간을 적어 두십시오. 약 십 분 유휴 후 멈춘다는 보고는 검증할 수 있지만, 무작위로 끊긴다는 보고는 검증할 수 없습니다. 그 차이가 타이머를 쫓을지 라우팅 변경을 쫓을지를 결정합니다.

잊어버린 장비를 찾으십시오

같은 플로의 상태를 로컬 라우터, 상류 변환기, 클라우드 경계, 호스트 방화벽 등 여러 장비가 보관할 수 있습니다. 각자 자기 타이머가 있고 가장 짧은 것이 이깁니다. 다섯 분간 끊기면 보통 한 장비가 다른 장비보다 훨씬 낮게 설정되어 있다는 뜻입니다.

문서에 적힌 기본값이 당신 경로의 타임아웃이라고 가정하지 마십시오. 그것은 한 장비의 기본값입니다.

• 가정용 라우터: 흔히 몇 분, 때로는 훨씬 짧습니다.
• 클라우드 NAT 또는 로드 밸런서: UDP에 특화된 유휴 타임아웃 문서 값을 찾아보십시오.
• 호스트 방화벽: netfilter 추적 타이머가 플로마다 적용됩니다.

실제 경로에서 타이머를 확인하십시오

Linux에서는 netfilter 추적 타이머를 보고 조정할 수 있습니다: sysctl net.netfilter.nf_conntrack_udp_timeout 및 net.netfilter.nf_conntrack_udp_timeout_stream. 두 번째는 트래픽이 양방향으로 관찰된 뒤에 적용되므로, 이미 설정된 터널이 단순 프로브보다 오래 살 수 있습니다.

RFC 4787 은 UDP NAT 동작과 권장 최솟값을 규정합니다. 공급업체 기본값이 비정상적으로 짧아 보일 때 인용할 참조입니다.

Keepalive와 재연결은 서로 다른 도구입니다

Keepalive는 매핑을 살려 두고, 재연결은 죽은 세션을 다시 만듭니다. 둘은 서로 다른 고장을 해결하며 교환 가능한 속도 설정이 아닙니다. WireGuard의 PersistentKeepalive 은 고정 간격으로 패킷을 보내 NAT 바인딩을 열어 둡니다. OpenVPN의 keepalive 옵션은 같은 일을 자기 방식으로 합니다. 중간 장비가 이미 플로를 잊고 양방향을 버리고 있다면 둘 다 도움이 되지 않습니다.

지나치게 잦은 프로브는 잘못된 경계를 고치지 못한 채 작업만 늘립니다.

페이지 새로고침이 아니라 새 요청으로 검증하십시오

타이머를 바꾸거나 keepalive를 추가한 뒤 유휴 시나리오를 이전과 똑같이 반복하십시오. 그다음 대상 애플리케이션에서 정말 새로운 요청을 하십시오. 이미 로드된 브라우저 탭은 캐시에서 렌더링될 수 있어 아무것도 알려주지 않습니다.

멈춤이 계속되면 한 홉 바깥으로 이동해 그 장비의 상태 테이블을 확인하십시오.