WireGuard는 서버가 먼저 보낸 뒤에야 동작한다: 엔드포인트 지식

서버가 먼저 무언가를 보낸 뒤에야 터널이 동작하는 것처럼 보입니다. 클라이언트에서 시작하면 아무 일도 일어나지 않고, 몇 초 기다렸다가 다시 시도하면 성공합니다. 흔한 진단은 끊어진 NAT이지만, 그 흔한 진단은 틀렸습니다. 달라진 것은 한쪽 피어가 다른 쪽이 어디에 있는지 알게 되었다는 점입니다.

도달 가능성이 아니라 엔드포인트 지식

WireGuard 피어는 어디로 보내야 하는지 알기 전에는 핸드셰이크를 시작하지 않습니다. 구성은 이를 주소와 포트로 된 엔드포인트로 제공하고, 실행 상태는 현재 믿고 있는 엔드포인트를 추적합니다.

wg show 는 그 그림의 양쪽을 보여 주며, 출력에 엔드포인트가 없는 피어는 공개 키와 허용된 프리픽스가 아무리 정확해도 아무것도 시작할 수 없습니다. 규칙을 바꾸기 전에 클라이언트의 시각과 서버의 시각을 비교하세요. 누가 무엇을 아는지에 대해 둘은 자주 의견이 다릅니다.

피어가 엔드포인트를 배우는 방식

WireGuard는 의도적으로 조용합니다. 올바르게 인증된 패킷이 피어가 예상하지 못한 주소에서 도착하면, 구현은 그 피어의 엔드포인트를 새 출발지로 갱신하며, 네트워크를 바꾸는 노트북에서 로밍이 동작하는 방식이 바로 이것입니다. 이 동작이 방향 의존성을 설명합니다: 서버가 먼저 보내고 그 패킷이 클라이언트에 도달하면, 클라이언트는 서버의 현재 주소를 배우고 응답할 수 있습니다. 그전까지는 보낼 곳이 없습니다. 이 메커니즘은 첫 사용 시 신뢰라는 지름길이 아니라 인증된 로밍이며, 엔드포인트가 움직이기 전에 패킷이 유효해야 했기 때문입니다.

wg 의 도구 문서가 그 갱신을 설명하며, 이를 중심으로 설계하려면 한 번 읽어 볼 가치가 있습니다.

상태를 가진 변환은 고유한 방향을 더한다

UDP가 변환하는 게이트웨이를 지나면, 게이트웨이는 처음 본 패킷에 대한 상태를 만듭니다. RFC 4787 은 그 동작과 결국 매핑을 제거하는 타임아웃을 설명합니다. 유휴 매핑은 만료되고, 먼 쪽에서 들어오는 패킷은 호스트에 도달하기 전에 게이트웨이에서 버려집니다. 아침 내내 동작하던 터널이 오후에 응답을 멈추는 이유가 바로 이것입니다.

이것은 같은 방향성 증상을 만드는 두 번째이자 독립적인 메커니즘입니다. 엔드포인트 지식과 변환 상태가 모두 올바라야 하며, 하나를 고쳐도 다른 하나는 고쳐지지 않습니다.

실제로 원하는 방향을 구성하세요

연결을 시작해야 하는 클라이언트라면 서버의 엔드포인트를 클라이언트의 피어 섹션에 넣고 그대로 두세요. 서버가 먼저 보낼 것에 의존하는 것은 조용한 네트워크에서 바뀔 트래픽 순서의 우연에 의존하는 것입니다. 구성은 의도한 방향을 밝혀야 하며, 그것을 발견하게 해서는 안 됩니다.

변환 뒤에 있으면서 계속 도달 가능해야 하는 피어라면 그쪽에서 지속적 keepalive를 활성화하세요. 25초마다 keepalive가 일반적인 시작 값이며, 그 목적은 터널을 시험하는 것이 아니라 매핑을 열린 상태로 유지하는 것입니다. 양쪽에서 활성화하면 결과를 개선하지 않은 채 트래픽과 로그 잡음이 두 배가 되므로, 한쪽만 담당하게 하세요.

트리거 전후의 상태를 비교하세요

실패하는 순간 두 시각을 캡처하고, 서버가 보낸 뒤에 다시 캡처하세요. 첫 번째 명령은 엔드포인트와 핸드셰이크 경과 시간을 보여 줍니다. 두 번째는 해당 포트의 변환 항목이 있는지 보여 줍니다. 캡처는 어느 방향이 실제로 회선을 건넜는지 보여 주고, 경로 확인은 클라이언트가 그 트래픽을 전혀 다른 곳으로 보내지 않음을 확인합니다.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

엔드포인트 열과 변환 항목을 함께 기록하세요. 엔드포인트가 없는 피어와 매핑이 없는 게이트웨이는 서로 다른 두 결함입니다. keepalive로 고쳐지는 것은 그중 하나뿐입니다.