Tor 출구 릴레이와 VPN 출구 서버: 각각이 아는 것
Tor 출구 릴레이와 VPN 출구 서버는 모두 하나의 공개 주소를 보여 주지만 지식을 나누는 방식은 다릅니다. 가시성, 적용 범위, 포트 정책을 비교하세요.
두 설계 모두 주소를 하나의 공개 IP 뒤에 숨기며, 보이는 주소를 출력하는 사이트는 둘을 구별할 수 없습니다. 차이는 경로에서 누가 무엇을 알게 되는지, 얼마나 많은 트래픽이 포함되는지, 어떤 포트가 동작할 수 있는지에 있습니다. Tor 출구 릴레이는 세 릴레이로 이루어진 회로의 마지막 홉이고, VPN 출구 서버는 터널을 끝내고 바깥 연결을 스스로 엽니다. 다음은 어떤 작업에 어느 쪽이 필요한지 내가 판단하는 방식과, 하나가 다른 하나처럼 동작한다고 가정하기 전에 확인하는 항목입니다.
하나의 주소에서 끝나는 두 경로
Tor는 가드, 중간 릴레이, 출구를 거쳐 회로를 만들고 페이로드를 계층으로 암호화하므로 각 릴레이는 자기 계층만 벗깁니다. 출구가 목적지와 평범한 TCP 연결을 맺기 때문에 목적지에는 출구 주소가 보입니다. 클라이언트는 목적지와 직접 대화하지 않으며 가드도 목적지를 보지 못합니다.
VPN은 하나의 종단점으로 가는 하나의 터널입니다. 사업자의 서버가 터널을 벗기고 바깥 연결을 열기 때문에 목적지에는 역시 하나의 주소, 이번에는 사업자의 주소가 보입니다. 관찰되는 결과는 같지만 지식은 같지 않습니다. IP를 출력하는 테스트는 어느 체계에 있는지만 알려 주고, 실제로 다른 신뢰 배분에 대해서는 아무것도 말하지 않습니다.
결국 누가 무엇을 아는가
VPN 종단점은 출발지 주소, 목적지, 시각, 볼륨을 한곳에서 봅니다. 이 집중이 곧 설계로, 사업자 하나, 로그 표면 하나, 소환장이나 잘못된 설정을 받아 낼 장소 하나입니다. 얻는 모든 것은 그 당사자에 대한 신뢰와 종단점의 바깥 정책에서 나옵니다.
Tor는 그 지식을 나눕니다. 가드는 주소를 알지만 목적지는 모르고, 출구는 목적지를 알지만 주소는 모릅니다. 하나의 릴레이가 둘 다 배우도록 되어 있지 않습니다. 이는 구조적 속성이며 전역 관찰자, 시각을 상관시키는 릴레이, 침해된 종단점에 대한 약속이 아니므로, 실패할 수 없는 익명성이 아니라 같은 위험의 다른 분배로 다루어야 합니다.
| What is known | Tor exit relay | VPN exit server |
|---|---|---|
| Your public address | Seen by the guard relay, not the exit | Seen at the endpoint |
| Final destination | Seen at the exit | Seen at the endpoint |
| Coverage | Applications configured for Tor, chiefly Tor Browser | Whatever the route policy includes |
| Plain HTTP payload | Readable at the exit | Readable at the endpoint |
적용 범위는 브라우저의 결정인가 경로의 결정인가
Tor 브라우저는 자체 트래픽을 스스로 라우팅하고, 지문 저항, 퍼스트파티 격리, 고정 창 크기, 세션 상태를 버리는 새 신원 동작처럼 일반 VPN 클라이언트가 재현하지 못하는 보호를 더합니다. 다른 애플리케이션은 그렇게 설정되지 않는 한 이 회로를 쓰지 않으며, 시스템 전체 Tor 설정은 브라우저 설치와 별개의 작업입니다.
VPN은 반대 형태입니다. 적용 범위는 라우팅 표를 따르므로 AllowedIPs = 0.0.0.0/0 이 있는 WireGuard 프로필은 모든 것을 잡고, 분할 터널 목록은 거기에 적힌 접두사만 잡습니다. 유출도 바로 이 구조에 있으며, DNS 질의, IPv6, WebRTC는 각각 라우팅 정책에 없던 경로를 탈 수 있습니다. 실패한 애플리케이션 안에서 확인하고, 다른 인터페이스를 쓰고 있을 수 있는 브라우저 탭에서 확인하지 마세요.
포트 정책, 차단되는 목적지, HTTPS
출구 릴레이는 바깥 포트를 거부할 수 있고, 기본 정책은 남용에 취약한 포트 목록을 거부하며 그중에는 SMTP 포트 25도 있습니다. 그래서 Tor를 통해 설정한 메일 클라이언트는 출구에서 실패하며, 이는 네트워크 장애처럼 보이지만 그렇지 않습니다. 릴레이를 운영하는 사람은 이를 명시적으로 설정합니다:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25목적지도 차단하며, 두 체계를 서로 다르게 차단합니다. Tor 출구 주소는 공개되므로 사이트가 목록 전체를 거부할 수 있고, VPN 종단점은 데이터센터 대역에 있어 같은 정도로 쉽게 거부됩니다. 페이지가 실패하면 무엇이든 바꾸기 전에, 출구나 바깥 정책, 출발지를 거부하는 목적지, 첫 요청을 가로채는 캡티브 포털이라는 세 후보를 구분하세요.
어느 체계도 전송 암호화를 대신하지 않습니다. 평문 HTTP는 출구 릴레이와 VPN 종단점 모두에서 읽을 수 있으므로 HTTPS를 켜 두고 인증서 경고를 무시하지 말고 읽으세요. 두 가지 확인으로 경로 문제가 빨리 정리됩니다: 요청이 회로를 지났을 때 curl -s https://check.torproject.org/api/ip 은 IsTor 을 돌려주고, curl -s https://ifconfig.me 은 VPN이 제시할 바깥 주소를 보여 줍니다. 둘 다 실행하면 셸이 실제로 어느 경로를 쓰는지 알 수 있습니다.
하나를 다른 하나처럼 쓰지 마세요
출구 릴레이의 주소는 VPN 프로필이 아닙니다. OpenVPN이나 WireGuard 클라이언트를 포트 443의 릴레이로 향하게 해도, 그곳에는 VPN 서비스가 듣고 있지 않기 때문에 터널은 생기지 않으며, 릴레이는 다른 사람의 회로 안의 한 홉입니다. 반대 방향으로, VPN 종단점은 Tor의 진입점이 아니며 Tor 브라우저의 브리지 설정은 상용 VPN 호스트 이름을 붙여 넣을 곳이 아닙니다. VPN 위에서 Tor를 실행하면 가드는 당신 대신 VPN 주소를 보게 되며, 이는 두 역할을 합치지 않고 배분만 바꿉니다.
고르기 전에, 종단점을 누가 운영하고 무엇을 보관하는지, 이 기기에서 도구가 무엇을 덮는지, 바깥 정책이 어떤 포트와 목적지를 허용하는지, 애플리케이션이 네트워크 경로 너머에 무엇을 더하는지 네 가지 질문에 순서대로 답하세요. 많은 프로그램에 평범한 네트워크 접근이 필요한 작업에는 VPN이 맞습니다. 브라우저 수준 보호와 회로 모델이 필요한 작업에는 최신으로 유지한 Tor 브라우저가 맞습니다. 답이 «둘 다»라면 의도한 순서로 실행하고 어느 쪽이 어느 주소를 보는지 적어 두세요.