WireGuard 전체 터널: AllowedIPs 0.0.0.0/0만으로는 충분하지 않습니다

피어의 AllowedIPs에 0.0.0.0/0, ::/0 를 넣는 것은 누구나 기억하는 단계이며, 피어가 어떤 트래픽을 운반할 수 있는지만 결정합니다. 이 접두사는 경로를 만들지 않고, 반대편에서 아무것도 전달하지 않으며, 모든 애플리케이션의 리졸버를 원래 있던 자리에 그대로 둡니다. 전체 터널이 정말 전체 터널이 되려면 네 가지 별개의 조건이 동시에 성립해야 하며, 나중 검사가 앞선 검사를 구할 수 없으므로 아래 순서로 확인하는 것이 좋습니다. 아래의 각 검사는 머신에서 읽을 수 있는 사실이며, 적용되었기를 바라는 설정이 아닙니다.

피어 접두사가 고르는 것과 고르지 않는 것

AllowedIPs는 선택자인 동시에 허가입니다. 로컬 측에는 어떤 목적지를 이 피어로 보낼 수 있는지 알려주고, 수신 측에는 이 피어가 어떤 출발지 주소를 제시할 수 있는지 알려줍니다. 일은 그것뿐입니다. 그 설명 어디에도 호스트에 경로를 만들거나, 원격 측에서 전달을 켜거나, 이름 해석을 건드리는 요소는 없습니다.

그래서 구성은 완전해 보이면서 스플릿 터널처럼 동작할 수 있습니다. 접두사는 피어가 모든 것을 받아들일 것이라고 말할 뿐이고, 실제로 그곳에 무엇이 도착하는지는 호스트의 경로 표가 결정하며, 무언가 나가는지는 게이트웨이가 결정합니다. 이 세 가지 결정 중 어느 것도 피어 절에 있지 않습니다.

피어 목록만이 아니라 클라이언트를 라우팅하기

예를 들어 wg-quick 같은 관리자는 호스트의 경로 표를 대신 프로그래밍하므로, 동일한 구성 파일 두 개가 인터페이스가 어떻게 올라왔는지에 따라 다르게 동작합니다. 최소 프로필은 한 번에 읽을 수 있을 만큼 짧습니다:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

일은 두 가지 세부 사항이 떠받칩니다. Address 필드는 클라이언트가 자기 것이라고 믿는 서브넷이 아니라 단일 호스트 접두사이며, 기본 AllowedIPs를 실제 기본 경로로 바꾸는 것은 관리자입니다. 같은 파일을 ip link 와 wg setconf 로 올리면 경로가 전혀 나타나지 않는데, 이는 고장 난 터널처럼 보이지만 실제로는 라우팅 단계를 건너뛴 건강한 터널입니다. wg-quick 설명서는 라우팅과 Table 동작을 문서화합니다.

파일이 아니라 결과를 읽으십시오: ip route get 1.1.1.1 는 터널 인터페이스를 지목해야 하고, wg show 는 움직이는 전송 카운터와 함께 최근 핸드셰이크를 보고해야 합니다. 경로 없는 핸드셰이크는 관리자가 한 번도 실행되지 않았다는 뜻이며, 프로필을 다시 편집해도 고쳐지지 않습니다. 사용자가 시작할 방식 그대로 인터페이스를 시작하십시오. 그렇지 않으면 테스트는 배포가 아니라 당신의 셸을 측정합니다.

엔드포인트를 터널 밖에 두기

전체 터널은 존재하기 위해 대화해야 하는 대상까지 포함해 모든 목적지를 붙잡습니다. 관리자는 원래 게이트웨이를 통해 엔드포인트에 대한 호스트 경로를 추가하여 이를 처리하며, 그래서 올바른 구성에는 거의 항상 의도적인 예외가 하나 들어 있습니다. 구성의 절반을 관리자로, 나머지 절반을 손으로 적용하는 것이 이 예외가 사라지는 흔한 경로입니다.

엔드포인트가 여러 주소나 당신이 운반하지 않는 주소 패밀리로 해석되는 호스트 이름이라면, 그 예외는 나쁘게 늙고 일상적으로 보이던 재연결 후에 터널이 실패할 수 있습니다. 엔드포인트를 당신이 통제하는 주소에 고정하거나 관리자가 이를 재평가하는지 확인하고, 네트워크가 바뀔 때마다 호스트 경로를 다시 읽으십시오.

같은 메커니즘이 전체 터널과 캡티브 포털이 왜 싸우는지 설명합니다. 포털은 이제 터널이 붙잡는 트래픽을 가로채기를 기대하므로, 호텔과 공항 네트워크에서는 포털 로그인 후에 터널을 올리며 절대 그 전에 올리지 않습니다.

게이트웨이의 전달과 반환 경로

게이트웨이에서는 운반하는 주소 패밀리에 대해 전달을 켜고, 번역할 때 forward 체인을 양방향으로 허용하며, 출발지별 조회로 반환 경로를 확인합니다. 이 중 어느 것도 성공한 핸드셰이크에서 따라오지 않습니다. 핸드셰이크는 두 피어가 UDP를 교환할 수 있음만 증명하기 때문입니다. 캡슐이 벗겨진 패킷이 그 후 어떻게 되는지는 말하지 않습니다.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

조회는 클라이언트가 아니라 게이트웨이에서 실행됩니다. 그렇지 않으면 다른 경로 표를 읽게 됩니다. 잘못된 인터페이스를 지목하거나 경로가 없다고 보고하면, 클라이언트 측 변경으로는 인터넷 출구가 생기지 않습니다. 게이트웨이가 나가는 길에 클라이언트 주소를 번역할 때 응답은 그 번역 상태에 달려 있으므로, 규칙은 흐름의 나가는 방향만이 아니라 양방향 모두에 존재해야 합니다.

DNS와 실패 상태를 따로 시험하기

프로토콜 자체는 어떤 애플리케이션의 리졸버도 구성하지 않습니다. wg-quick 는 DNS 줄을 배포판의 리졸버 통합을 통해 적용하며, 자체 스택을 가진 컨테이너와 브라우저는 이를 무시할 수 있고, 그래서 터널이 패킷을 완벽하게 운반하는 동안에도 이름이 실패할 수 있습니다. 주소가 아니라 호스트 이름으로 시험하고, 프로필의 서버가 응답했다고 가정하는 대신 어느 서버가 응답했는지 기록하십시오.

주소 패밀리는 별도의 답을 가진 별도의 시험입니다. v4 기본 경로는 애플리케이션의 v6 연결이 어떻게 될지 아무것도 말하지 않으며, 두 번째 패밀리를 조용히 누출하는 터널은 크게 실패하는 터널보다 나쁩니다. 각 패밀리로 이름을 질의하고, 각 요청이 사용한 인터페이스를 읽고, 번역 카운터를 전후로 확인하십시오. 아무것도 일치하지 않는 규칙은 없는 규칙과 똑같이 보이기 때문입니다.

마지막으로 터널이 멈출 때 원하는 상태를 시험하십시오. 전체 터널은 자기가 주장하는 트래픽에 대해 닫힌 채 실패해야 합니다. 인터페이스가 내려가고 애플리케이션이 물리 링크로 조용히 계속된다면 그 설계는 단계가 더 많은 스플릿 터널입니다. 의도한 실패 동작을 적고, 의도적으로 확인하고, 네 가지 답을 기록하며 끝내십시오. 어느 관리자가 인터페이스를 올리는지, 어느 경로가 기본을 운반하는지, 게이트웨이에서 누가 전달하고 번역하는지, 어느 리졸버가 응답하는지입니다.