WireGuard 핸드셰이크는 성공하지만 응답이 돌아오지 않는다

최근의 핸드셰이크는 좋은 소식이며, 사람들이 쓰고 싶어 하는 문장보다 훨씬 작은 주장입니다. 두 피어는 인증된 핸드셰이크 메시지를 교환했습니다. 애플리케이션 패킷은 여전히 내부 목적지에 도달해 돌아와야 합니다.

건강한 제어 평면과 조용한 데이터 평면 사이의 이 간극이 여기서 다룰 주제 전체입니다. 같은 카운터의 두 번의 판독이 당신이 그 어느 쪽에 있는지 알려 줍니다.

핸드셰이크는 키를 증명할 뿐, 전달을 증명하지 않는다

WireGuard 핸드셰이크는 인증이 포함된 키 합의입니다. 두 피어가 서로 도달할 수 있고 유효한 키를 가지면 곧바로 성공합니다. 라우팅, 방화벽 정책, 목적지 자체는 핸드셰이크가 결코 묻지 않는 질문입니다.

따라서 터널은 완벽하게 수립되었는데 그 안의 모든 패킷이 버려질 수 있습니다. 잘못 라우팅된 내부 패킷과 다른 경로를 택한 응답은 클라이언트 쪽에서 똑같이 보입니다.

내부 주소 하나가 시험의 전부

목적지 하나를 골라 그것에 머무르십시오. 상대 피어 자체의 터널 주소가 가장 쉬운 경우이며, 그 뒤의 호스트는 정확히 한 홉을 더합니다. 변경을 기록하지 않고 둘 사이를 오가면 누구도 비교할 수 없는 결과가 나옵니다.

그다음 클라이언트가 선택하는 경로를 보십시오. 더 구체적인 로컬 경로는 WireGuard에 묻기도 전에 패킷을 다른 곳으로 보낼 수 있으며, 이는 집 LAN이 원격 범위와 겹칠 때마다 일어납니다.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

물리 인터페이스로 해석되는 주소는 이미 질문에 답한 것입니다. 터널은 아무것도 버리지 않습니다. 패킷은 그 안으로 들어간 적이 없습니다.

카운터는 증거이지 판결이 아니다

wg show은 피어별로 보낸 바이트와 받은 바이트를 보고하며, 두 숫자는 독립적으로 움직입니다. 한 번 판독하고, 허용된 요청을 하나 실행한 뒤, 같은 분 안에 다시 판독하십시오.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

수신은 평평한데 송신이 늘어나는 것은 응답 없는 요청의 서명입니다. 요청이 필터링되었는지, 목적지가 꺼져 있었는지, 응답이 다른 경로로 나갔는지는 말해 주지 않습니다. 이는 하나의 증상을 공유하는 세 가지 조사입니다. 설정을 바꾸기 전에 그것들을 분리하십시오.

고정된 바이트 수도 성공의 기준이 아닙니다. 카운터 값은 트래픽을 따르며, 숫자 하나를 건강의 증거로 다루면 자신감에 찬 무의미가 생깁니다.

상대 피어가 돌아오는 패킷을 직접 확인한다

원격 피어는 출발지가 그 피어의 allowedips 안에 들어올 때만 내부 패킷을 받아들입니다. 송신자에 경로가 있다고 충분하지 않습니다. 수신자에 출발지 항목이 없으면 돌아오는 트래픽은 조용히 버려집니다.

호스트 방화벽은 그 확인 뒤에 있습니다. 터널 인터페이스는 허용하지만 내부 서브넷은 허용하지 않는 포워딩 규칙은 핸드셰이크를 받아들이고 패킷을 거부합니다. 클라이언트 쪽에서는 그것이 정확히 죽은 피어처럼 보입니다. 인터페이스가 둘인 호스트는 잘못된 출발지로 응답할 수도 있고, 그러면 피어는 예상하지 못한 응답을 버립니다.

실험을 정직하게 유지하라

도달해야 할 같은 집 네트워크에서 원격 접속 프로필을 시험하면 의도한 경로와 다른 경로를 연습하게 됩니다. 외부 네트워크로 옮기고 그 로컬 프리픽스를 기록해 두어야 두 번의 실행을 비교할 수 있습니다.

작은 교환이 성공해도 모든 경로 문제를 배제하지는 못합니다. 큰 패킷은 작은 패킷이 통과하는 곳에서 실패할 수 있고, 크기나 프로토콜에 맞는 필터는 부하 상태에서 다르게 동작할 수 있습니다.

핸드셰이크를 작동한다고 알려진 단계로 유지하고 거기서부터 나아가십시오. 다음의 유용한 증거는 내부 요청 하나가 어디서 멈추는지이며, 새로운 키 묶음과 또 한 차례의 추측이 아닙니다.