ZeroTier 출구 노드가 작동하지 않나요? 경로, NAT, 클라이언트를 확인하세요
클라이언트의 0.0.0.0/0 경로는 출구가 아닙니다. 노드가 전달하고 변환해야 하며, 네트워크가 경로를 알리고, 클라이언트가 이를 받아들여야 합니다.
경로 테이블은 ZeroTier 인터페이스를 통한 기본 경로를 보여 주고, 네트워크는 온라인이라고 보고하며, 브라우저는 여전히 로컬 ISP 주소로 나갑니다. 이 조합은 흔하며 클라이언트의 버그가 아닙니다. 기본 경로는 패킷이 어디로 가야 하는지만 알려 줍니다. 반대편에서 패킷을 전달하고 변환하는 무언가가 필요합니다. 출구 노드가 작동하려면 세 가지 별개의 부분이 모두 참이어야 합니다.
경로는 있지만 아무것도 나가지 않는다
먼저 클라이언트의 경로 테이블을 확인하세요. default via 10.147.20.5 dev zt0 같은 줄은 경로가 설치되었다는 것을 증명할 뿐, 목적지가 트래픽을 받아들인다는 것은 아닙니다. 다음 홉은 이를 전달할 의지와 능력이 있는 구성원이어야 합니다.
같은 요청이 여전히 물리 인터페이스로 나간다면 클라이언트가 경로를 설치하지 않았거나, 로컬 기본 경로에 진 메트릭으로 설치한 것입니다. 경로를 설치한 뒤 요청이 사라진다면 출구 구성원이 패킷을 받고도 전달하거나 변환하지 못하는 것입니다. 물리 기본 경로를 유지하는 클라이언트는 출구로 패킷을 전혀 보내지 않습니다.
이 차이가 어디를 고쳐야 하는지를 결정합니다. 변경 전후에 공인 주소를 비교하면 한 번도 쓰이지 않은 경로와 쓰였다가 버려진 경로를 구분할 수 있고, 전체 구성을 검토하는 대신 명령 하나면 됩니다. 다른 것을 바꾸기 전에 비교하세요. 두 결과가 같은 초기 상태에서 나와야 합니다.
모두 참이어야 하는 세 부분
출구는 사슬이며 가장 약한 고리가 증상을 결정합니다. 아래 표는 보통 실패하는 순서대로 고리를 나열합니다.
| Part | Where it lives | What a failure looks like |
|---|---|---|
| Forwarding and NAT | Exit node kernel and firewall | Traffic arrives, no reply |
| Managed default route | ZeroTier network controller | No default via the tunnel on the member |
| Client acceptance | Member's per-network setting | Route offered but not installed |
| DNS behavior | Client resolver configuration | Pages fail by name, IP works |
첫 번째 줄은 옵션 이름이 감추고 있는 부분입니다. 구성원은 커널이 ZeroTier 인터페이스와 인터넷 쪽 인터페이스 사이에서 패킷을 전달하고, 응답 경로가 터널로 다시 변환될 때만 출구가 됩니다. 그 전달이 없으면 구성원은 피어이지 게이트웨이가 아닙니다.
컨트롤러 줄은 구성이 아니라 권한입니다. 구성원을 통해 0.0.0.0/0 을 알리면 모든 클라이언트에 출구가 어디인지 알려 주지만, 그 구성원이 트래픽을 운반할 수 있게 되지는 않습니다. 구성원이 인터넷으로 가는 작동 경로를 갖는지도 검증하지 않습니다. ZeroTier의 출구 노드 문서도 노드, 경로, 클라이언트 사이의 같은 분리를 다룹니다.
출구 노드가 전달하고 변환하도록 설정하기
IPv4 전달을 영구적으로 활성화한 다음 WAN 인터페이스를 떠나는 트래픽에 소스 NAT를 추가하세요. 필터 규칙은 전달된 흐름을 양방향으로 허용해야 합니다. 전달과 변환은 허가와 별개이기 때문입니다:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTzt0 와 eth0 를 호스트의 이름으로 바꾸세요. 예제 인터페이스용으로 저장한 규칙은 실제 인터페이스에서 패킷을 따라가지 않습니다. 규칙을 소유한 방화벽 관리자를 통해 변경을 영구적으로 만드세요. 대화형 셸의 명령은 다음 재부팅 때 사라집니다.
호스트가 UFW나 firewalld 같은 방화벽 관리자를 실행한다면, 옆에 iptables 줄을 쌓는 대신 그 관리자를 통해 규칙을 추가하세요. 같은 체인을 편집하는 두 소유자는 부팅 순서에 의존하는 정책을 만듭니다. 관리자가 자체 체인을 생성할 때 순서가 중요합니다. 관리자를 다시 로드한 뒤 클라이언트에서 시험하세요. 그 전이 아니라.
경로를 알리고 클라이언트에서 받아들이기
네트워크 컨트롤러에서 다음 홉이 출구 구성원의 ZeroTier 주소인 0.0.0.0/0 용 관리 경로를 추가하세요. 그런 다음 그것을 사용해야 하는 구성원에서 해당 네트워크의 재정의를 허용하세요. 허가는 로컬입니다. 다른 구성원을 재구성하지 않고 컨트롤러도 바꾸지 않습니다.
zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1마지막 명령은 ZeroTier 인터페이스와 출구 구성원의 주소를 보고해야 합니다. 여전히 물리 인터페이스를 보고한다면 경로가 없거나 경쟁 기본 경로의 메트릭이 더 좋은 것입니다.
설정은 그것이 필요한 네트워크로만 제한하세요. 기본 경로 수용을 전역으로 켜거나, 사설 서브넷만 제공해야 하는 네트워크에서 켜면, 그 용도로 설계된 적 없는 출구로 트래픽을 보내게 됩니다.
출구를 검증하고 다른 주소 패밀리를 확인하기
소스를 보고하는 서비스에서 공인 주소를 받아 출구 노드의 WAN 주소와 비교하세요. 그런 다음 이름으로 사이트를 열어 DNS가 여전히 해석되는지 확인하고, 브라우저만이 아니라 중요한 애플리케이션 하나를 시험하세요.
이중 스택 클라이언트는 IPv4가 ZeroTier로 나가는 동안 기본 IPv6 경로를 계속 쓸 수 있습니다. 목표가 모든 트래픽을 숨기거나 제어하는 것이라면 별도의 ::/0 경로와 출구에서의 IPv6 전달이 필요하며, IPv4 시험은 그에 대해 아무것도 말해 주지 않습니다.
Linux의 역경로 필터링도 클라이언트에서 유효한 출구 트래픽을 버릴 수 있습니다. ZeroTier는 참여 구성원을 위한 rp_filter 고려 사항을 문서화합니다. 이 설정은 의도적으로, 그리고 경로와 NAT를 확인한 뒤에만 바꾸세요. 첫 실험으로 삼지 마세요.
요구 사항이 NAS나 사무실 서브넷 하나에 접근하는 것이라면, 그 접두사에 대한 관리 경로는 완전한 출구보다 작고 안전한 변경입니다. 모든 탐색을 다른 장치를 통해 보내는 것은 하나의 사설 리소스에 도달하는 것과 다른 결정이며, 별도의 검토가 필요합니다.