한 피어는 도달 불가, 다른 피어는 정상인 WireGuard 점검 목록

WireGuard 피어 하나는 트래픽을 통과시키고 두 번째 피어는 핸드셰이크를 마치지만 터널 뒤의 어떤 것에도 결코 도달하지 못합니다. 동작하는 피어는 인터페이스와 UDP 포트, 서버 키가 아마 정상이라는 것만 알려 줍니다. 두 번째 피어의 AllowedIPs, 그 내부 출발지 주소, 둘 사이의 전달 규칙에 대해서는 아무것도 알려 주지 않습니다. 목록을 순서대로 진행하고 조건이 깨지는 첫 단계에서 멈추십시오.

1단계: 패킷이 지나야 할 경로를 적어 두십시오

같은 허브에 있는 두 클라이언트는 자동으로 서로에게 도달하지 않습니다. 허브 앤 스포크 구성에서는 서버가 wg0에서 패킷을 받아 다시 wg0 밖으로 다른 피어에게 전달해야 하며, 이를 위해서는 IP 전달과 전달 규칙이 필요합니다. 직접 피어 투 피어 구성에서는 양쪽 모두 상대의 엔드포인트와 상대의 터널 주소를 AllowedIPs 안에 두어야 합니다. 설정을 읽기 전에 어느 구성을 디버깅하는지 먼저 정하십시오.

예상 경로는 어디를 봐야 하는지도 알려 줍니다. 패킷이 허브를 거쳐야 한다면 실패 지점은 송신자의 AllowedIPs, 허브의 전달, 수신자의 AllowedIPs 중 하나입니다. 직접 가야 한다면 허브는 무관하고 양쪽 피어의 엔드포인트 항목이 중요합니다.

2단계: AllowedIPs는 한쪽이 아니라 양쪽에서 비교하십시오

WireGuard는 AllowedIPs를 라우팅 테이블이자 접근 목록으로 함께 사용합니다. 보낼 때는 터널을 고르기 위해 목적지 주소를 피어의 AllowedIPs에서 찾고, 받을 때는 내부 출발지 주소가 보내는 피어의 AllowedIPs 안에 있어야 하며 그렇지 않으면 패킷이 버려집니다. 어느 한쪽에서 범위가 빠지면 전송은 되는데 내용이 사라지는 같은 증상이 나타납니다.

다시 불러오기가 조용히 실패했을 수 있으므로 파일이 아니라 실제 상태를 읽으십시오: sudo wg show wg0 allowed-ips. 서버에서는 실패한 피어 항목에 그 터널 주소(예: 10.90.0.3/32)가 들어 있어야 합니다. 클라이언트에서는 서버 피어 항목에 시험 중인 목적지가 들어 있어야 하며, 그것이 허브의 터널 주소이든 원격 서브넷이든 마찬가지입니다. 범위가 겹치면 조회가 모호해져 의도하지 않은 피어가 선택될 수 있으므로 반드시 분리하십시오.

3단계: 내부 출발지 주소를 확인하십시오

10.90.0.3을 wg0로 라우팅하면서 패킷은 Wi-Fi 주소에서 보내는 클라이언트는 출발지가 피어의 AllowedIPs와 맞지 않아 수신자에게 거부됩니다. 커널이 실제로 무엇을 고르는지 ip route get 10.90.0.3 from 10.90.0.2로 확인하고, 터널 인터페이스에 지정된 주소를 ip -brief addr show wg0로 확인하십시오.

수신 측 Linux 호스트에서는 역경로 필터링이 두 번째 관문입니다. 되돌아갈 경로를 가진 인터페이스에 엄격한 rp_filter가 걸려 있으면 도착한 인터페이스와 반환 경로가 맞지 않는 터널 트래픽이 버려질 수 있습니다. 끄기 전에 실제 값을 확인하고, 많은 구성에서는 필터를 풀어 두는 것이 아니라 경로를 추가하는 것이 올바른 수정입니다.

4단계: 허브의 전달과 반환 경로를 검토하십시오

허브가 피어 사이를 전달해야 한다면 커널에 net.ipv4.ip_forward=1가 필요하고, 방화벽은 전달되는 흐름을 받아들여야 합니다 — wg0로 들어와 wg0에서 나가며 송신자의 터널 주소에서 수신자의 주소로 향하는 흐름입니다. 흔한 실패는 UDP 51820을 받아들이는 입력 규칙은 있지만 전달 규칙이 없는 것]이며, 그러면 핸드셰이크는 성공하는데 내용이 죽습니다. 유효한 규칙은 sudo nft list ruleset 또는 사용 중인 방화벽 관리자의 해당 명령으로 나열하십시오.

다음으로 응답을 확인하십시오. 목적지 호스트는 송신자로 돌아가는 경로를 가져야 하며, 허브를 거치든 자체 게이트웨이를 거치든 상관없습니다. 허브가 터널 서브넷에 NAT도 한다면 변환이 전달되는 흐름에 적용되고 상태가 만료되기 전에 응답이 허브에 도착하는지 확인하십시오. 키 문제처럼 보이는 단방향 실패는 흔히 이 반환 경로가 원인입니다.

마지막으로 핸드셰이크와 데이터를 분리하십시오. 핸드셰이크는 끝내지만 큰 전송에서 멈추는 피어는 보통 그 경로의 MTU나 MSS 문제이며 AllowedIPs 문제가 아닙니다. 먼저 작은 ping으로, 다음으로 최대 크기 ping으로 시험하고 두 피어를 비교하십시오.

5단계: 한 가지만 바꾸고 동작하는 피어는 그대로 두십시오

실패한 경로에 한 가지 변경만 가하고 두 피어를 다시 시험하십시오. 모든 피어의 AllowedIPs를 0.0.0.0/0로 바꾸는 것은 그 인터페이스의 모든 트래픽에 대한 라우팅 결정이 바뀌기 때문에 이미 동작하던 피어를 깨뜨리는 가장 빠른 방법입니다. 그 한 항목만 편집하고 다시 불러온 뒤 실제 상태를 다시 읽으십시오.

어느 경로가 성공했고 어느 것이 실패했는지, 그리고 각각의 정확한 명령 출력을 기록하십시오. 그 비교는 VPN이 고장 났다는 일반적인 보고보다 값어치가 있으며, 다음 사람이 가장 먼저 요청할 것입니다.