대부분의 사람들은 AllowedIPs를 허용 목록, 즉 피어에 연결할 수 있는 주소의 집합으로 읽고, 터널을 위해 작성된 방화벽 규칙과 비슷하다고 생각합니다. 그렇지 않습니다. 이 필드는 양방향으로 작동하는 라우팅 테이블로, 나가는 패킷의 피어를 고르고 들어오는 패킷의 소스를 검증합니다. 이를 접근 목록으로 읽으면 아무도 요청하지 않은 트래픽을 라우팅하는 설정이 만들어집니다.

하나의 필드, 두 명의 독자: 나가는 선택과 소스 검사

클라이언트에서 프리픽스는 어떤 목적지가 그 피어로 가고 어떤 것이 일반 네트워크에 남는지를 결정합니다. 그래서 0.0.0.0/0 항목은 모든 IPv4 목적지를 잡고, 전체 터널 프로필을 가져오면 일반 브라우징이 원격 머신을 거치는 이유도 여기에 있습니다. 좁은 항목은 반대로, 나열한 네트워크만 라우팅하고 나머지는 있던 곳에 둡니다. WireGuard 문서의 암호 키 라우팅 절은 나가는 피어 선택과 들어오는 소스 검증이라는 두 작업을 한곳에서 설명합니다.

서버에서는 같은 필드가 각 피어가 사용할 수 있는 소스 주소를 설명합니다. 이것은 패킷 필터가 아니라 암호학적 검사입니다: 내부 소스가 피어의 목록과 일치하지 않는 패킷은 호스트의 어떤 방화벽도 보기 전에 WireGuard 내부에서 버려집니다. 두 작업은 하나의 목록을 공유하며, 다른 곳에서 복사한 목록이 고려하지 않은 지점에서 잘못 동작하는 이유가 바로 여기에 있습니다.

클라이언트 블록은 이 혼란의 대부분이 시작되는 곳입니다. 분할 터널은 원격 네트워크를 지목하고, 전체 터널은 같은 필드에 기본 프리픽스를 넣은 것입니다:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

두 형태 모두 그 자체로 완전하며, 단계가 아니라 대안입니다. 첫째는 그 두 네트워크만 터널로 보내고, 둘째는 모든 목적지를 보내며 ::/0 항목이 IPv4 기본값에 IPv6를 더합니다. 어느 쪽을 고르든 wg-quick이 경로 설치를 시작하면 그 프리픽스가 해당 피어의 전체 라우팅 결정입니다.

허브에는 다른 목록이 필요합니다

허브는 각 클라이언트의 터널 주소를 호스트 프리픽스로 나열하고, 그 클라이언트 뒤에 실제로 있는 네트워크도 함께 나열합니다. 클라이언트의 넓은 목록을 허브의 모든 피어에 복사하면 많은 피어가 같은 주소를 소스로 쓸 수 있다고 허브에 알리는 셈이며, 그것은 주소 계획이 아닙니다. Endpoint 필드는 전혀 다른 계층에 속합니다: 피어의 바깥 주소와 포트를 지목하며, 터널 안의 목적지는 결코 아닙니다.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

호스트 프리픽스는 터널 주소를 나르고 네트워크 프리픽스는 클라이언트 뒤에 있는 것을 나르며, 둘 다 필요합니다. 호스트 프리픽스가 없으면 허브는 클라이언트 자체의 트래픽을 돌려보낼 수 없고, 네트워크 프리픽스가 없으면 그 뒤의 LAN은 도달할 수 없는 채로 남고, 뒤에 아무것도 없는 피어는 호스트 프리픽스만 받습니다.

경로 설치를 건너뛰면 빈틈이 남습니다

wg-quick은 구성 파일에서 인터페이스를 올리는 도우미로, 그 작업의 일부로 인터페이스 주소와 경로를 설치합니다. Table = off를 설정하면 도우미에게 경로 작업을 건너뛰라고 지시하며, 이는 대체 경로를 설치하지 않고 사설 네트워크를 도달 가능하게 만들지도 않습니다. 자동 경로가 이미 일을 한다면 필요한 프리픽스를 적는 것이 더 명확한 구성입니다. 경로 관리를 끄고 대체 경로를 쓰지 않는 것은 설계가 아니라 누락입니다.

기본 wg 도구는 다르게 동작합니다: 인터페이스를 구성하고 경로는 절대 건드리지 않으므로, 그것 위에 직접 세운 설정에는 자체 경로 명령이 필요합니다. 한 도구를 위해 쓴 지침을 다른 도구에서 따르면 틀려 보일 수 있습니다. 성공한 ping도 약한 증거인데, 필요한 모든 응용 프로그램 경로가 아니라 하나의 경로만 시험하기 때문입니다.

DNS와 IPv6는 따로 결정됩니다

터널이 알리는 DNS 서버 주소를 확인하고, 고른 프리픽스를 통해 그 주소로 가는 경로가 있는지 확인하십시오. 리졸버 설정은 리졸버를 도달 가능하게 만들지 않으며, 터널을 좁히면 그곳으로 가던 경로가 조용히 사라질 수 있습니다. IPv6도 따로 살펴보아야 합니다, 올바른 IPv4 분할은 여전히 물리 링크를 가리키는 IPv6 기본 경로에 대해 아무것도 말해 주지 않습니다. 피어 블록 하나를 편집할 때 세 가지 별개의 결정이 한꺼번에 바뀔 수 있습니다.

그다음 알려진 시작 구성에서 사설 자원 하나와 일반 웹사이트 하나를 여십시오. 자원이 응답하고 브라우징이 여전히 로컬 연결로 나간다면 분할은 요청한 대로 작동합니다. 같은 순간에 브라우징이 끊긴다면 터널이 기본 경로를 가져간 것이며, 프리픽스 목록이 살펴볼 곳입니다.

관련 글