WireGuard에 최신 핸드셰이크가 표시되지 않을 때 먼저 확인할 것

최신 핸드셰이크 필드가 비어 있다는 것은 보통 인터페이스가 올라온 뒤 핸드셰이크를 완료하지 못했다는 뜻이며, 이는 보기보다 구성에 대해 말해 주는 바가 적습니다. WireGuard는 패킷이 인터페이스를 통해 나가야 할 때까지 조용히 있으므로, 보낼 것이 없는 유휴 peer는 정확히 그 상태를 보고합니다. 키를 살펴보기 전에 실제로 무언가가 제시되었는지 확인하세요.

시험은 peer가 실어야 할 목적지로 향하는 허용된 패킷입니다. 그 상태 화면의 나머지 모든 것은 활동이 아니라 의도를 설명합니다.

유휴 인터페이스는 보고할 것이 없습니다

WireGuard는 핸드셰이크를 게으르게 수행합니다. 터널이 필요한 첫 패킷이 교환을 촉발하고, 그때까지 인터페이스는 조용합니다. 구성되었지만 한 번도 사용되지 않은 peer는 빈 핸드셰이크, 수신 바이트 제로, 마지막 이후 늘어나는 간격을 보여 줍니다. 이 상태는 유휴 클라이언트에 건강하며, 트래픽이 이미 흘렀을 것이라고 기대한 경우에만 우려할 만합니다. 전송 카운터도 확인하세요. 보내지 않은 것과 시도했지만 실패한 것을 구분해 줍니다.

양쪽 카운터가 영에 머문다면 문제는 터널 위쪽에 있습니다. 무언가를 촉발하려고 인터페이스에 도달한 것이 없습니다.

peer가 실을 수 있는 트래픽을 촉발하세요

로컬 머신에서 peer의 허용된 프리픽스 안에 있는 주소를 고르고, 라우팅 테이블이 그 주소를 인터페이스로 보낼지 확인하세요. 그 프리픽스 밖의 목적지는 WireGuard가 전혀 관여하지 않는 평범한 라우팅 요청을 만듭니다. ping이나 짧은 TCP 연결처럼 빠르게 응답하는 서비스를 사용해 시도에 눈에 보이는 시작과 끝이 있게 하세요. 그런 다음 화면을 보며 기다리는 대신 핸드셰이크 줄을 다시 읽으세요.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

경로 질의가 ping보다 중요합니다. 물리 인터페이스를 가리킨다면 패킷은 터널에 들어가지 않았고, 빈 핸드셰이크는 암호학적 답이 아니라 라우팅 답입니다. peer를 디버그하기 전에 경로를 고치세요.

키 쌍과 엔드포인트를 비교하세요

트래픽이 실제로 제시되면 다음 확인은 신원입니다. 로컬 개인 키는 상대편이 허용하는 공개 키와 대응해야 하고, 구성된 원격 공개 키는 의도한 peer를 가리켜야 하며, 사전 공유 키가 있다면 양쪽 끝에서 일치해야 합니다. base64 키에서 한 문자만 달라도 구성된 것처럼 보이지만 교환을 끝내지 못하는 peer가 생깁니다. 키를 다시 만들지 말고 프로비저닝 기록과 비교하세요. 새 키는 옛 키를 신뢰한 모든 peer를 무효화합니다.

엔드포인트도 같은 점검이 필요합니다. 호스트 이름, 주소, UDP 포트, 그리고 거기에 도달하는 데 쓰는 주소 체계입니다. 오래된 주소나 잘못된 포트는 메시지가 아니라 침묵을 낳습니다.

외부 UDP 경로를 지켜보세요

핸드셰이크는 UDP로 엔드포인트를 향해 가므로 외부 경로가 그것을 실어야 합니다. 아래 명령은 리스너가 있는지, 로컬 스택이 데이터그램을 내보냈는지, 어떤 엔드포인트가 구성되었는지 확인합니다. 트래픽을 촉발하기 전이 아니라 촉발하는 동안 캡처를 실행하세요.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

시작만 보이고 응답이 없는 캡처는 머신 바깥을 가리킵니다. 상대편이 듣지 않거나, 필터링되었거나, 주소가 잘못되었기 때문입니다. 아무것도 보이지 않는 캡처는 패킷이 나간 적이 없다는 뜻이며, 이는 경로와 관여한 소켓 마크로 되돌아가게 합니다. 양쪽 끝을 관리한다면 일반 캡처 대신 서버의 좁은 캡처와 시각으로 시도를 대조하세요. TCP 포트 시험은 여기서 아무것도 증명하지 못합니다. 프로토콜은 UDP뿐입니다.

핸드셰이크가 나타나면 터널을 통해 애플리케이션을 시험하세요. 완료된 교환은 신원과 도달 가능성을 증명할 뿐, 쓸 만한 처리량이나 올바른 DNS를 증명하지는 않습니다. 변경 전후의 상태 출력을 보관하면 그 차이가 증거가 됩니다.