하나의 경로를 증명하는 두 피어 WireGuard 테스트 구축 방법

기본 경로, LAN 프리픽스, DNS, 방화벽 예외를 함께 실은 WireGuard 테스트로는 그중 무엇이 깨졌는지 알 수 없다. 피어 둘, 주소 쌍 하나, 허용된 서비스 하나로 줄이면 실패가 숨을 곳이 없다. 지루한 기준선이 바로 진단이다. 먼저 그것을 구축하라. 십오 분이 걸리고, 그렇지 않으면 추측에 쓸 오후를 아낀다.

기준선이 증명하는 것은 대부분이 기대하는 것보다 좁다. 두 신원이 일치하고, UDP가 수신 포트에 도달하며, 허용된 목적지 하나가 요청을 나른다는 것만 증명한다. 포워딩, NAT, LAN 경로, DNS는 나중에 하나씩 추가하는 별개 기능이다.

키, 주소, 단일 엔드포인트

각 시스템에서 키 쌍을 만들고 공개 절반만 서로 옮긴다. wg genkey | tee privatekey | wg pubkey > publickey 는 문서화된 한 줄 명령이며, 나중에 보호할 수 있는 파일에 개인 키를 남긴다. 소유한 다른 어떤 구성에도 나타나지 않는 대역에서 터널 주소를 고른다, 예를 들어 10.99.0.1/24와 10.99.0.2/24다. 어떤 주소가 어느 머신에 속하는지 적어 두라. 이후의 모든 확인이 그 매핑에 달려 있다.

개인 키는 절대 이동하지 않는다. 테스트를 위해 한쪽을 다른 쪽으로 복사해야 한다면 그 테스트는 이미 잘못된 것이다. 두 시스템이 NAT 뒤에 있다면 적어도 하나는 도달 가능한 UDP 포트가 필요하고 다른 하나는 그것을 가리키는 Endpoint를 지닌다. 공인 주소와 포트는 51820에 대한 가정이 아니라 메모에 적어야 한다.

다른 외부 포트로 매핑하는 포트 포워딩은 Endpoint가 그것과 일치하는 한 잘 동작한다. 여기서 불일치는 오류가 아니라 침묵을 낳는다. 그래서 케이블에서 디버깅하기 전에 종이에 확인할 가치가 있다.

wg에 속하는 필드와 그렇지 않은 필드

핵심 필드 집합은 작다. Interface 아래의 PrivateKey와 ListenPort, Peer 아래의 PublicKey, AllowedIPs, Endpoint다. Address와 DNS는 wg 자체가 아니라 wg-quick에 속하며, 같은 구성이 다른 도구로 옮겨지는 순간 그 구분이 아프게 작용한다.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs는 두 가지 일을 동시에 한다. 어떤 목적지가 터널로 들어갈지 선택하고, 도착 시 그 소스 주소를 사용하도록 피어에게 권한을 준다. 그래서 반대편의 미러 항목은 당신의 터널 주소를 정확히 지목해야 한다. 잘못된 피어에 대한 /32는 라우팅 문제로 읽히고 권한 문제처럼 동작한다. WireGuard 빠른 시작 은 필드 이름을 비교하려면 같은 두 피어 형태를 표준 표현으로 보여 준다.

아이콘 대신 핸드셰이크 읽기

인터페이스를 그것을 소유한 무엇이든 통해 올린 다음, 상태 표시등이 아니라 상태를 읽어라. wg show 는 피어별 최근 핸드셰이크와 바이트 카운터를 출력한다. 최근 몇 분 안의 핸드셰이크는 키, 엔드포인트, UDP 경로가 모두 동작한다는 뜻이다. 한 방향으로만 증가하는 카운터는 그 자체로 답이며, 결코 일어나지 않는 핸드셰이크와 같은 실패가 아니다.

두 실패는 서로 다른 조사를 뜻한다. 핸드셰이크가 전혀 없다면 키 불일치, 잘못된 Endpoint, 차단된 UDP, 또는 핸드셰이크 자체를 버리는 방화벽을 가리킨다. 핸드셰이크는 성공하는데 데이터가 어디에도 가지 않는다면 AllowedIPs, 터널 주소에서 수신하지 않는 서비스, 또는 LAN에는 포트를 허용하지만 터널 인터페이스에는 허용하지 않는 호스트 방화벽을 가리킨다. 이것들은 시스템의 서로 다른 절반이며, 규칙을 바꾸기 전에 기준선이 둘을 분리한다.

허용된 서비스 하나를 증명한 뒤 반대 방향

다른 피어의 터널 주소로 응답해야 하는 서비스에 요청을 보내고, ping보다 나은 것을 고른다. ICMP 응답이 없는 것은 터널 결함이 아니라 호스트 필터링일 수 있으므로 조용한 ping은 어느 방향도 증명하지 못한다. 열려 있다고 아는 포트로의 TCP 연결이나 데이터를 돌려주는 요청은 해석할 수 있는 답을 준다.

반대 방향은 자체 결과를 가진 별도 테스트로 실행하라. 두 방향은 방화벽과 AllowedIPs 항목이 따로이고 독립적으로 실패할 수 있기 때문이다. 핸드셰이크는 되는데 요청이 안 된다면 문제는 터널이 아니라 데이터 경로, 곧 AllowedIPs나 수신 서비스나 호스트 방화벽에 있으니 포워딩, NAT, DNS를 추가하기 전에 고쳐라, 그렇지 않으면 한 번도 원인이 아니었던 기능을 디버깅하며 오후를 보내게 된다.

기준선을 참조로 유지하기

동작하는 토폴로지와 프로필 소스를 복원할 수 있는 곳에 저장하고, 공개 서비스와 동기화되는 어떤 디렉터리에도 두지 마라. 그다음 포워딩, NAT, LAN 경로, DNS 순으로 한 번에 기능 하나를 추가하며 매번 원래 요청을 반복하라. 테스트를 깨는 추가는 이제 식별할 수 있다. 다른 것은 움직이지 않았기 때문이다.

아이콘만 초록으로 바꾸는 기준선은 다음 실패를 어떤 추가가 일으켰는지 아무것도 말해 주지 않는다. 유일하게 허용된 경로를 참조로 계속 동작시키고, 이후의 모든 변경은 그것과 비교해 측정한다.