허브에서의 WireGuard 피어 그룹: 소스 소유권과 정책

WireGuard를 실행하는 허브는 그룹마다 별도의 인터페이스나 라우팅 테이블 없이도 피어 그룹을 분리할 수 있습니다. 두 가지 메커니즘이 이 일을 하며, 이 둘을 혼동하는 것이 정책이 올바라 보이면서 아무것도 하지 않는 흔한 이유입니다. 한 계층은 누가 소스 주소를 주장할 수 있는지 결정합니다. 다른 계층은 그 패킷이 어디로 갈 수 있는지 결정합니다.

두 가지 일, 분리해서 보기

터널 계층은 좁은 질문에 답합니다. 이 피어의 키가 이 내부 소스 주소를 승인했는가 하는 것입니다. 포워딩 계층은 더 넓은 질문에 답합니다. 이 패킷이 그 목적지로 나갈 수 있는가 하는 것입니다. 어느 쪽도 상대의 질문에 답하지 않으며, 어느 쪽도 단독으로 완전한 접근 정책이 아닙니다.

이 분리가 바로 피어가 인증되고 주소도 올바르지만 정작 가서는 안 되는 호스트에 도달하지 못하는 이유입니다. 반대 경우도 설명합니다. 모든 것을 허용하는 방화벽 규칙은 누가 어떤 주소를 주장할 수 있는지에 대해 아무것도 증명하지 않습니다.

두 계층을 함께 설계한 뒤 둘 다 시험하세요. 한 계층에서 올바르고 다른 계층에서 시험되지 않은 구성은 기본값에 따라 열린 채로 또는 닫힌 채로 실패합니다.

각 피어에는 자기 주소만 주세요

다중 호스트 피어는 서버 쪽에서 그룹 범위 전체를 주고 싶게 만듭니다. 그 권한은 소스 주소에 대한 주장이므로, 침해되었거나 잘못 구성된 클라이언트가 범위 안의 아무 주소나 제시해도 터널이 그것을 받아들입니다. 각자의 내부 주소에는 피어마다 /32를 할당하세요. 그룹 범위는 클라이언트에만 설정하세요. 거기서 그 범위는 그 클라이언트가 도달할 수 있는 목적지를 뜻하지, 사용할 수 있는 소스를 뜻하지 않습니다.

그러면 방화벽은 신뢰할 수 있는 소스와 대조합니다. 그룹 범위에 맞춰 쓴 규칙은 여전히 유용한 묶음이며, 어떤 단일 피어도 다른 구성원의 주소를 주장할 수 없을 때에만 의미를 갖습니다.

그룹을 분리하는 포워딩 정책을 작성하세요

여기서 다루는 트래픽은 같은 터널 인터페이스로 들어오고 나가므로 호스트 입력 경로가 아니라 포워딩 경로를 지납니다. 규칙은 호스트를 소유한 방화벽 관리자의 기존 포워딩 체인에 들어가며, 완전한 규칙 집합이 아니라 조각입니다.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

처음 두 규칙은 각 그룹 내부의 트래픽을 허용합니다. 마지막 규칙은 그 인터페이스를 지나는 나머지 전부를 차단하며, 이것이 그룹 사이의 격리를 만들어 냅니다. 다른 주소 체계가 필요하면 명시적 규칙을 추가하세요. IPv4용으로 쓴 drop은 IPv6의 동작을 허용하지도 설명하지도 않습니다.

순서가 정책의 적용 여부를 결정합니다

규칙의 순서는 조각 자체보다 중요합니다. 설정된 연결을 허용하는 일반 규칙이 이 항목들보다 앞에 있으면 오래된 그룹 간 흐름이 계속되므로, 격리는 새 연결에만 적용됩니다. 다시 불러오기 전에 두 결과 중 무엇을 원하는지 정하세요.

허용 판정도 같은 훅의 체인 사이에서 항상 최종은 아닙니다. 다른 기본 체인이 나중에 실행되면 실제 정책은 그 조합이므로, 편집한 파일이 아니라 카운터를 확인하세요. 카운터는 이용할 수 있는 가장 값싼 증거입니다. 패킷 수가 없는 규칙은 일치하지 않으며, 일치하는데 뒤의 체인이 허용한다면 drop의 위치가 잘못되었다는 뜻입니다.

파일 개수가 아니라 매트릭스를 시험하세요

기대 결과의 작은 매트릭스를 만들어 모든 칸을 확인하세요. 그룹 A에서 그룹 A로는 되어야 하고, 그룹 B에서 그룹 B로도 되어야 하며, A에서 B로는 안 됩니다. 양방향으로, 그리고 지원한다면 두 주소 체계 모두에 대해 확인하세요.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

처음 두 명령은 무엇이 설정되었는지 보여 줍니다. 잘못된 그룹 구성원에서 보낸 ping은 실제로 무슨 일이 일어나는지 보여 줍니다. conntrack 목록은 오래된 흐름이 아직 허용되는지 보여 주며, 격리 변경이 조용히 효력을 내지 못하는 방식이 바로 이것입니다.

허브의 호스트 서비스와 그 뒤 LAN에 대한 접근은 정책이 다른 별개의 경로입니다. 매트릭스가 어느 쪽을 포괄하는지 기록하세요. 피어 간 트래픽만 확인하는 시험은 둘 중 어느 쪽에 대해서도 아무것도 말해 주지 않습니다.