Tor 릴레이와 VPN 서버: 서로 대체할 수 없는 이유

Tor 릴레이의 열린 포트는 VPN 엔드포인트가 아닙니다. 먼저 포트가 무엇을 제공하는지, 릴레이 역할, SOCKS 리스너 범위, 프로필을 확인하세요.

주소가 있고 포트가 응답하며 클라이언트는 불평 없이 이를 받아들입니다. 그러나 그중 어느 것도 Tor 릴레이를 VPN 엔드포인트로 만들지 않으며, 프로필이 깔끔하게 가져와지고 나중에 핸드셰이크에서 실패하기 때문에 이 실수는 비쌉니다. 아래 네 가지 검사를 순서대로 사용하며, 각 검사에는 중단 조건이 있고 일찍 멈추는 것이 핵심입니다. 첫 번째 검사가 실패하면 나머지는 도움이 되지 않습니다.

포트가 실제로 무엇을 제공하는지 확인하세요

열린 포트는 리스너의 존재만 증명합니다. 릴레이의 ORPort는 TLS 핸드셰이크 후 Tor 자체의 셀로 대화하므로, 성공한 TLS 검사는 VPN 프로토콜이 그곳에서 허용되는지에 대해 거의 알려주지 않습니다.

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

인증서가 있는지가 아니라 인증서 자체를 읽으세요. 릴레이는 릴레이 트래픽이 일반 HTTPS처럼 보여야 하므로 의도적으로 눈에 띄지 않는 이름의 자체 서명 인증서를 제시하는 반면, VPN 서버의 인증서는 프로필이 기대하는 이름을 담고 있습니다. 상대가 VPN 프로토콜의 첫 패킷에 절대 응답하지 않는다면, 프로필을 아무리 편집해도 결과는 바뀌지 않습니다.

주소가 클라이언트가 보내는 핸드셰이크를 완료하지 않으면 여기서 멈추세요. 그것은 설정 문제가 아니라 프로토콜의 응답이며, 가져온 프로필이 영원히 'connecting'에 머무는 가장 흔한 이유입니다.

네트워크 크기가 아니라 릴레이 역할을 확인하세요

릴레이 역할은 서로 다른 일을 합니다. guard는 클라이언트에게 첫 홉이고 중간 릴레이는 다른 릴레이 사이에서 회로를 전달하며, exit는 목적지에 닿는 역할이고 브리지는 BridgeDB를 통해 배포되는 비공개 진입점입니다. Tor의 용어집은 이 정의들을 분리해 두며, 도달 가능성은 모든 역할의 일부이지만 임의의 클라이언트를 서비스할 권한은 어느 역할에도 포함되지 않습니다.

exit 정책은 전달 규칙과 닮은 유일한 부분으로서 읽을 가치가 있으며, exit가 밖으로 나가도록 허용할 목적지를 규정할 뿐 안으로 들어오는 클라이언트를 규정하지 않습니다. 포트 25를 차단하는 제한적 exit 정책은 외부 악용 통제에 대해 무언가를 말하지만, OpenVPN 클라이언트를 그 기계로 향하게 해도 되는지에 대해서는 말하지 않습니다.

평판에서 추론하는 것, 즉 릴레이가 트래픽을 전달하므로 그 주소가 당신의 트래픽을 받아들여야 한다는 생각은 여기서 멈추세요. Tor는 합의와 자체 프로토콜로 경로를 고르며, VPN 클라이언트는 참가자가 아니고 합류할 회로도 없습니다.

SOCKS 리스너가 로컬인지 공개인지 확인하세요

Tor 클라이언트는 같은 기계의 애플리케이션에 SOCKS 인터페이스를 노출하며, 기본값은 loopback입니다. 그 리스너는 로컬 편의 기능이지 릴레이가 인터넷에 제공하는 서비스가 아니며, 이를 공개 프록시로 다루는 것이 사람들이 의도하지 않은 오픈 릴레이를 운영하게 되는 경로입니다.

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

바인드 주소가 단서입니다. 127.0.0.1:9050 의 SocksPort는 제 일을 하고 있고, 0.0.0.0 에서 수신하며 외부에서 도달 가능한 것은 오픈 프록시이며, Tor 자체의 접근 정책 통제가 존재하는 이유는 바로 그 노출이 기능이 아니라 문제이기 때문입니다.

Tor가 필요한 애플리케이션은 loopback 포트로 향하게 하고 이름 해석을 Tor에 맡기세요(위의 socks5h 형식이 그렇게 합니다). 그 포트에 릴레이 주소를 대신 넣지 마세요—릴레이는 애플리케이션이 요청하는 인터페이스를 제공하지 않기 때문입니다.

VPN 프로필이 실제 엔드포인트와 일치하는지 확인하세요

VPN 프로필은 OpenVPN에는 서버 인증서나 CA, 클라이언트 인증서와 키, 보통 TLS 키가 필요하고 WireGuard에는 상대의 공개 키, 엔드포인트, 허용된 IP가 필요하다는 기대의 묶음입니다. 어느 것도 주소와 열린 포트에서 도출할 수 없기에, 그렇게 만든 프로필은 연결할 때가 아니라 첫 교환에서 실패합니다.

프로필을 받으면, 당신이 통제하는 엔드포인트나 식별할 수 있는 공급자에 대조해 검증하세요.

wg show
openvpn --config client.ovpn --verb 4

OpenVPN 로그에서는 TLS 협상 오류가 불일치를 직접 지목하고, wg show 에서는 핸드셰이크 줄이 없는 상대가 한 번도 완료하지 못한 상태입니다. 둘 다 클라이언트의 회전 표시보다 정보가 많고, 둘 다 Tor가 아니라 키 자료나 프로토콜을 가리킵니다.

실제로 어떤 보호가 필요한지 확인하세요

이것이 아키텍처를 결정하는 검사입니다. Tor 브라우저는 VPN이 주지 않는 회로 격리와 핑거프린팅 방어를 제공하고, VPN은 목적지가 보는 주소를 바꾸고 당신을 공급자에게 인증합니다. 둘 중에서 고르는 것은 호환성 문제가 아니라 위협 모델 문제이며, 둘을 혼동하면 사적인 것처럼 보이지만 그렇지 않은 구성이 됩니다.

연쇄에는 순서가 있습니다. Tor 클라이언트는 나가는 TCP만 필요하기 때문에 Tor 트래픽을 운반하는 VPN은 지원되는 구성입니다. Tor 안에 터널링한 VPN 클라이언트는 같은 것이 아니며 Tor 클라이언트가 구현하는 것도 아니므로, 그것을 전제로 계획하지 마세요.

무엇이든 가져오기 전에 네 가지를 모두 확인하세요.

  • 포트가 단순한 TCP 연결이 아니라 프로토콜의 핸드셰이크를 완료합니다.
  • 호스트의 역할을 알고 있으며 전달을 허가로 착각하지 않습니다.
  • 사용하는 SOCKS 리스너는 loopback이고 당신의 것이며, 다른 사람 릴레이의 공개 포트가 아닙니다.
  • 프로필의 키나 인증서는 연결하는 엔드포인트의 것입니다.

관련 글