WireGuard 분할 터널: 기본 경로 없이 구성하기

분할 터널은 무엇을 빼는지로 정의되며, WireGuard는 그 결정을 한 필드에서 내립니다. 클라이언트 피어의 AllowedIPs는 어떤 목적지가 터널을 지나는지 고르는 동시에 어떤 내부 소스 주소를 받아들일지 걸러 내고, wg-quick은 같은 목록을 호스트 경로로 바꿉니다. 목록이 틀리면 터널은 모든 것을 삼키거나 아무것도 나르지 않습니다.

먼저 프리픽스 목록을 정하십시오

설정 파일을 건드리기 전에 터널을 써야 하는 목적지를 적어 두십시오. 사무실 서브넷, 데이터베이스 범위, 관리 네트워크: 각각 이유가 있는 프리픽스입니다. 목록에 없는 것은 물리 경로에 남으며, 그것이 설계의 전부입니다.

목록에 0.0.0.0/0이나 ::/0이 있으면 실패 방식과 DNS 기대가 다르기 때문에 전체 터널을 만든 것이므로 그렇게 말해야 합니다.

나중에 검토자가 라우팅 테이블과 대조할 수 있도록 목록을 충분히 짧게 유지하십시오.

클라이언트 구성: 피어, AllowedIPs, DNS

클라이언트의 인터페이스 블록에는 자체 터널 주소와 개인 키가, 피어 블록에는 서버의 공개 키, 엔드포인트, 첫 단계의 프리픽스가 들어갑니다.

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

클라이언트의 AllowedIPs는 원격 목적지의 집합이며 클라이언트 자신의 주소가 아닙니다. DNS 줄은 wg-quick의 리졸버 통합을 통해서만 효력이 있으므로 resolvconf나 systemd-resolved 지원이 없는 호스트는 이를 무시합니다. PersistentKeepalive는 NAT 매핑을 살려 두는 것이며 직접 경로에서는 필요 없습니다.

각 프리픽스에 그것이 맡는 서비스를 주석으로 달아 두지 않으면 다음 편집은 추측이 됩니다.

서버 구성: 반대쪽 관점

서버에서는 피어 항목이 클라이언트를 나타내므로 그 AllowedIPs는 클라이언트의 터널 주소, 보통 /32입니다. 사무실 서브넷이 아닙니다. 클라이언트 목록을 서버 항목에 복사하는 것이 분할 터널에서 가장 흔한 실수이며, 접근을 넓히거나 핸드셰이크 시 내부 소스 검사를 깨뜨립니다.

서버 자체의 인터페이스 주소와 사무실 쪽으로 필요한 경로는 어떤 피어 항목과도 별개입니다.

두 파일, 두 관점, 그 사이에 나뉜 하나의 프리픽스 집합.

올리고 경로를 읽으십시오

지원되는 관리자로 인터페이스를 시작한 다음, 의도한 것이 아니라 실제로 설치된 것을 보십시오. wg-quick은 AllowedIPs에서 경로를 도출하며, 프로필이 Table = off를 설정하면 아무것도 설치되지 않고 라우팅은 직접 해야 합니다. 각 프리픽스의 경로를 읽고 WireGuard 인터페이스를 가리키는지 확인하십시오. 경로 목록이 비어 있다면 적용된 프로필이 편집한 프로필이 아닐 가능성이 큽니다.

핸드셰이크가 없는 피어는 라우팅이 아니라 키, 엔드포인트, 도달성 문제를 가진 것이므로 핸드셰이크 카운터도 확인하십시오.

다음 사람이 압박 속에서 실행할 것이므로 사용한 명령을 그대로 적어 두십시오.

양쪽을 검증한 뒤 롤백을 기록하십시오

사설 주소, 그 내부 이름, 그리고 직접 남아야 할 목적지를 시험하십시오. 사설 주소가 통하고 직접 목적지가 이제 터널로 나가면 프리픽스 목록이 너무 넓습니다. 주소는 되는데 이름이 실패하면 DNS 줄이 효력을 내지 못한 것입니다. 롤백은 명령 하나이며 같은 메모에 남깁니다.

프로필을 다시 적용하는 관리자는 수동 경로를 바꿀 수 있으므로 다시 연결한 뒤 경로가 여전히 있는지 확인하십시오.

같은 인터페이스를 만드는 두 관리자는 결국 어긋나므로 설정 소유자는 한 명으로 두십시오. wg-quick 설명서에 제공되는 경로와 DNS 동작이 기록되어 있습니다.