WireGuard peer 두 개가 같은 범위를 공유할 때: 패킷을 받는 쪽은 어느 쪽인가

두 peer가 서로 맞닿은 범위를 나열하고, 트래픽은 잘못된 쪽에 도달합니다. 손상된 것은 없으며, WireGuard는 목적지를 설정된 범위와 대조해 peer를 고르며, 가장 구체적인 일치가 이깁니다. 무엇이든 넓히기 전에 어느 peer가 어느 프리픽스를 가져야 하는지 정하세요.

WireGuard 내부에서는 가장 긴 프리픽스가 이깁니다

각 peer 항목은 목적지 프리픽스 집합을 가집니다. 패킷이 인터페이스로 라우팅되면, 구현은 가장 구체적으로 일치하는 프리픽스가 있는 항목을 찾으며, 이는 라우팅 테이블이 적용하는 것과 같은 규칙입니다. 따라서 /24는 그것을 포함하는 /16을 이기고, 더 좁은 peer가 트래픽을 받습니다.

road-warrior 구성은 이것을 의도적으로 사용합니다. 한 peer가 사이트를 위한 넓은 범위를 가지고, 개별 호스트는 다른 peer에 속한 /32 항목으로 잘려 나옵니다. 이 패턴이 동작하는 것은 잘라낸 부분이 더 구체적이기 때문이지, 순서 때문이 아닙니다.

소유권을 프리픽스와 peer의 표로 적어 두세요. 두 항목이 같은 프리픽스를 기술한다면, 그 구성은 더 이상 의도를 표현하지 않고 경쟁을 표현합니다.

운영체제가 먼저 인터페이스를 고릅니다

WireGuard는 한 인터페이스의 peer들 사이에서만 고릅니다. 어느 인터페이스가 패킷을 받는지는 더 앞서 호스트의 라우팅 테이블이 결정하며, 게다가 두 번째 기본 경로나 오래된 경로가 트래픽을 peer 목록이 결코 보지 못하는 곳으로 보낼 수 있습니다. 그래서 peer 수준 진단이 맞아도 여전히 장애를 설명하지 못할 수 있습니다. peer 구성을 읽기 전에 목적지의 경로를 확인하세요—물리 인터페이스를 가리키는 경로는 문제 전체를 우회합니다.

도구는 보통 peer 범위에서 그 경로들을 설치하므로, 한 peer의 목록을 바꾸면 이전에 다른 peer에 속했던 트래픽이 조용히 다시 지정될 수 있습니다. 따라서 peer 편집은 변장한 라우팅 변경입니다. 둘을 함께 검토하세요—그러지 않으면 하나를 고치고 다른 하나를 깨뜨립니다.

들어오는 패킷은 출처로 검사됩니다

범위 목록은 이중 역할을 합니다. 나가는 트래픽에는 목적지로 peer를 고르고, 들어오는 트래픽에는 출처 주소를 승인합니다. 그 peer의 범위 밖 주소에서 도착한 패킷은 어떤 방화벽도 보기 전에 버려집니다.

구성의 한쪽만 읽으면 이 비대칭을 놓치기 쉽습니다. 서브넷에 도달할 수 있는 peer가 그 서브넷에서 보내는 것까지 허용되는 것은 아니며, 두 방향은 서로 다른 검사로 강제됩니다.

출처 소유를 좁히면 이것이 장점이 되며, 각 peer에 자기 주소용 /32를 주면 하위 방화벽이 대조할 신뢰할 수 있는 출처를 갖게 됩니다. 어떤 구성원이든 주장할 수 있는 그룹 전체 범위 대신입니다.

중복 범위는 장애 조치가 아닙니다

같은 프리픽스를 두 peer에 할당해도 로드 밸런서나 대기 경로가 생기지 않습니다—상태 검사도 세션 선호도도 없습니다. 이기는 항목은 구현의 내부 순서가 결정하며, 그것은 설계의 전제로 삼을 계약이 아닙니다. 대체 출구가 필요하면 선택이 정의된 곳에서 표현하세요. 라우팅 정책, 메트릭, 또는 각각 문서화된 소유자가 있는 두 개의 서로 다른 프리픽스는 예측하고 시험할 수 있는 동작을 만듭니다.

무관한 장애를 고치려고 범위를 넓히는 것이 또 하나의 흔한 실수입니다. 동작하던 peer에서 트래픽을 멀어지게 하고, 옛 증상이 이해되기 전에 새 증상이 도착합니다.

편집하기 전에 선택을 검증하세요

세 명령이 세 질문에 순서대로 답합니다. 첫 번째는 각 peer가 주장하는 범위를 나열합니다. 두 번째는 호스트가 목적지에 어떤 인터페이스를 쓸지 보여 줍니다. 세 번째는 트래픽이 흐른 뒤 peer의 실시간 상태를 보여 줍니다.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

변경 전후에 실행해 비교하세요. 경로 출력은 바뀌었는데 트래픽이 여전히 잘못된 peer에 도착한다면, 프리픽스 목록이 아직 적지 않은 방식으로 겹쳐 있습니다. 경로 출력이 바뀌지 않았다면, peer 구성은 애초에 참조된 대상이 아니었습니다.

티켓에 목적지, 선택한 인터페이스, 선택한 peer를 기록하세요. 그 세 가지가 나중에 겹침을 검토 가능하게 만들며, 구성의 스크린샷보다 훨씬 유용합니다.