ZeroTier 위의 HTTP는 암호화되는가? 오버레이가 끝나는 지점 확인

이 점검들을 순서대로 진행하고 처음 실패하는 지점에서 멈추십시오. 각 답이 다음 단계의 의미를 바꾸기 때문입니다. 진짜 질문은 좁습니다. ZeroTier 네트워크의 평문 HTTP가 인터넷을 그대로 지나갈까요? 두 ZeroTier 피어 사이에서는 보통 그렇지 않습니다. 오버레이가 그 구간을 암호화하기 때문입니다. 그러나 그것은 두 끝점에 대한 진술일 뿐 요청이 지나는 모든 구간에 대한 것이 아니며, 라우터·브리지·리버스 프록시가 끝점을 옮기면 그 반대편에서 평문이 다시 시작됩니다.

점검 1: 브라우저가 접속하는 주소 찾기

URL을 기계가 실제로 가진 것과 비교하십시오. ip -brief addr show는 zt 인터페이스와 네트워크 컨트롤러가 할당한 오버레이 주소를 나열합니다. URL이 그 주소를 쓰면 브라우저 소켓은 오버레이로 들어갑니다.

이름이 대신 LAN 주소로 확인되면, 클라이언트 상태 표시가 무엇을 암시하든 오버레이는 전혀 관여하지 않을 수 있습니다. ip route get 10.147.20.5는 커널이 고를 인터페이스와 원본 주소를 인쇄하므로, 거기에 zt 인터페이스가 있으면 패킷이 오버레이로 들어가고 물리 NIC 이름이면 들어가지 않는다는 뜻입니다. 이름은 층을 하나 더 더합니다. 오버레이 주소를 가리키는 레코드는 LAN 주소를 가리키는 것과 다르게 동작하며, 검색 접미사나 hosts 파일 항목이 어느 것을 받을지 조용히 결정할 수 있습니다.

점검 2: 양쪽 끝이 피어이며 복호화하는 릴레이가 아님을 확인

ZeroTier는 피어 사이를 암호화하며, 직접 경로가 없으면 패킷은 여전히 암호화된 채로 전달하는 루트를 통해 중계됩니다. zerotier-cli peers는 각 피어의 경로를 지연 수치와 함께 DIRECT 또는 RELAY로 표시합니다. 중계 경로는 왕복 비용을 치를 뿐 기밀성을 잃지 않습니다.

답을 실제로 바꾸는 것은 진짜 끝점이 아닌 구성원입니다. 상대편이 물리 LAN으로 라우팅하거나 브리지하는 ZeroTier 구성원이면 오버레이는 그 구성원에서 끝나고 다음 홉은 평범한 이더넷입니다.

점검 3: 요청이 읽히게 되는 지점 관찰

페이지를 제공한다고 믿는 호스트에서 다시 불러오는 동안 오버레이 인터페이스를 캡처하십시오: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. 그 출력에서 읽을 수 있는 요청 줄이 있으면 트래픽이 그 호스트에 복호화된 채 도착했다는 증거이며, 그것이 찾는 경계입니다.

그다음 LAN의 나머지를 향한 인터페이스에서 캡처하십시오. 같은 요청이 거기 평문으로 나타나면 애플리케이션에 도달하기 전에 오버레이를 떠난 것이고 그 구간의 모든 장치가 읽을 수 있습니다. LAN 쪽에 아무것도 나타나지 않는데 페이지가 여전히 로드되면 애플리케이션은 ZeroTier 호스트 자체에서 끝나는 것입니다.

리버스 프록시가 앞에 있을 때 루프백 캡처도 중요한데, HTTPS를 받아 HTTP를 전달하는 프록시가 경계를 자기 백엔드로 옮기기 때문입니다.

점검 4: 라우터나 브리지 뒤의 모든 홉 계산

오버레이와 LAN 사이를 라우팅하도록 설정된 구성원은 흔한 설계이며 이런 가정 대부분이 깨지는 지점입니다. 오버레이는 브라우저에서 라우터까지의 구간만 보호하고 그 뒤는 보호하지 않습니다. 브리지는 다른 방식으로 같은 이야기를 합니다. 오버레이와 물리 구간이 하나의 브로드캐스트 도메인이 되므로, 브리지된 노트북에서 온 요청은 그 노트북이 ZeroTier 네트워크에 있어도 평범한 이더넷을 지납니다.

가정하지 말고 추적하십시오. 클라이언트에서 서비스 주소까지의 traceroute와 게이트웨이 구성원의 라우팅 테이블은 마지막 홉이 zt인지 eth인지 보여줍니다.

ZeroTier는 성능을 위해 지정된 로컬 경로에서 전송 보안을 포기할 수 있는 신뢰 경로 모드도 제공합니다. 이를 쓰는 네트워크는 일반적인 암호화 경로 가정을 물려받지 않으므로, 인용하기 전에 네트워크 구성을 읽으십시오. 프로토콜 문서는 피어 간 암호화와 그 예외를 모두 설명합니다.

점검 5: 애플리케이션이 아직 해야 할 일 결정

오버레이 구성원 자격은 장치를 네트워크에 인증할 뿐 상대편 서비스가 도달하려던 그 서비스인지는 말해 주지 않습니다. HTTPS는 호스트 이름을 키에 결속하여 다른 질문에 답합니다. 따라서 두 보호는 서로를 대체하지 않고 겹칩니다. 권한이 있는 피어도 잘못된 서비스일 수 있고, 침해된 끝점은 암호화 전과 복호화 후 모두 요청을 읽습니다. 어느 방식도 애플리케이션이 기록하는 내용을 감사하지 않습니다.

재사용 가능한 세션이나 비밀번호가 있는 모든 것에는 애플리케이션 또는 직접 관리하는 프록시에서 TLS를 끝내고 인증서 검증을 켜 두십시오. 레거시 서비스가 평문 HTTP에 남아야 한다면 허용되는 정확한 호스트 간 경로, 누가 접근할 수 있는지, 어느 구간이 보호되지 않는지 적어 두십시오. 그 메모가 미래의 검토자에게 필요한 것입니다.

"VPN이 연결되어 있다"는 이 중 어느 것에 대한 평가도 아닙니다. 정직한 판본은 양쪽 끝점, 그 사이의 경로, 그리고 보호되지 않는 첫 홉을 지목합니다.

캡처 출력과 피어 목록을 서비스 문서 옆에 보관하면 경로를 바꾸거나 브리지를 추가하는 사람이 어떤 가정을 깨려는지 알 수 있습니다.