Tor인가 VPN인가: 각 경로가 당신에게 누구를 믿게 강요하는지로 결정하라
VPN은 신뢰를 한 운영자에게 쌓고, Tor는 릴레이에 분산합니다. 적용 범위, 누가 당신을 사이트와 연결할 수 있는지, 무엇을 검증할 수 있는지로 결정하십시오.
Tor와 VPN 중 무엇을 고를지는 연결의 양 끝을 보는 것을 어느 쪽에 허용할 수 있는지로 귀결됩니다. VPN은 그 시야를 당신이 선택한 한 운영자에게 집중시킵니다. Tor는 그것을 릴레이에 나누므로, 어떤 단일 릴레이도 당신이 누구이며 무엇을 가져왔는지 알도록 의도되지 않습니다.
두 방식 모두 그 자체로 당신을 익명으로 만들지 않습니다. 남은 신뢰를 소리 내어 말할 수 있는 쪽을 고르고, 그다음 그것이 덮지 못하는 부분을 고치십시오.
누가 당신을 목적지와 연결할 수 있는지 세십시오
VPN에서는 모든 적용되는 흐름이 목적지에 도달하기 전에 운영자의 출구에 도달합니다. 그 운영자는 필연적으로 당신의 출발지 주소를 보고, 그것을 통해 암호화되지 않은 모든 것에 대해서는 당신이 요청한 목적지도 봅니다. TLS는 페이지 내용을 그 시야 밖에 두지만, 연결이 설정되는 동안 보통 호스트 이름은 보이게 남깁니다. 따라서 한 당사자가 당신을 사이트와 연결할 수 있으며, 그 연결이 바로 당신이 주는 신뢰입니다.
Tor는 그 반쪽들을 세 릴레이로 나눕니다: 당신의 주소를 알지만 목적지는 모르는 가드, 어느 쪽 끝도 모르는 중간 릴레이, 목적지는 알지만 당신은 모르는 출구입니다. 이 설계는 어떤 단일 릴레이도 두 사실을 결합하지 않는다고 가정하며, 이는 한 회사를 신뢰하는 것보다 약하고 더 유용한 가정입니다. 릴레이가 정직하다고 가정하지 않으며, 경로의 양 끝을 보는 관찰자도 이기지 못합니다.
두 설계는 하나의 약점을 공유하며, 그것은 목적지에 있습니다. 로그인하면 패킷이 어떤 경로로 도착했든 서비스는 그 세션을 당신의 계정과 연결합니다. 라우팅은 요청이 어디서 오는 것처럼 보이는지를 바꾸지, 페이지가 당신에게 무엇을 제공하라고 요구하는지를 바꾸지 않습니다.
라우팅 다이어그램보다 적용 범위가 더 중요합니다
VPN은 네트워크 계층에서 라우팅하므로, 의도적으로 제외하지 않는 한 기기의 모든 응용 프로그램이 터널을 상속합니다. 그 폭이 메일 클라이언트, 패키지 관리자, 브라우저에 동시에 작동하는 이유입니다.
Tor Browser는 번들이며, 그 보호 기능은 대부분 브라우저 안에 있습니다: 균일한 지문, 사이트 간 격리, 그리고 설치한 확장 기능이 아니라 보안 수준으로 제한되는 스크립트입니다. Chrome을 SOCKS 포트로 향하게 하면 라우팅만 얻을 뿐 그중 어느 것도 얻지 못합니다, 이는 잘못된 곳의 자신감이 흔한 원천입니다.
데스크톱의 나머지는 그대로입니다. 동기화 클라이언트, 업데이터, 다른 프로그램에서 연 다운로드 문서는 그 프로그램이 구성된 대로 연결하며, 거기서 설정하지 않으면 그중 어느 것도 SOCKS 수신기를 통과하지 않습니다. 네트워크와 대화하는 응용 프로그램을 나열하고, 선택한 도구가 실제로 어느 것을 덮는지 물으십시오. 적용 범위는 당신의 구성의 속성이지 의도의 속성이 아닙니다.
세 가지 조건으로 고르십시오
결정은 보통 세 가지 질문으로 풀립니다: 트래픽이 하나의 응용 프로그램에서 오는지, 기기 전체에서 오는지, 목적지가 당신의 주소를 식별할 수 없어야 하는지, 사설 네트워크에 도달해야 하는지입니다. 그 순서대로 답하면 도구는 대개 스스로를 고릅니다.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
두 요구가 충돌할 때는 어느 것을 시행할 수 있는지 저울질하십시오. 제외 목록이 새는 기기 터널은 당신이 입증할 수 있는 브라우저 전용 경로보다 나쁩니다.
검증은 두 경로 모두에 저렴하며, 어느 한쪽에 의존하기 전에 이루어져야 합니다:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
첫 명령의 잘못된 결과는 요청이 회로 밖으로 나갔다는 뜻이며, 그것이 일찍 잡을 가치가 있는 실패입니다. 두 번째는 공급자가 할당한 주소와 비교하고, 지난주에 기억한 주소와 비교하지 마십시오.
어느 옵션도 고치지 못하는 것
응용 프로그램 암호화는 어떤 경로도 하지 않는 일을 여전히 합니다. 프라이버시 네트워크를 통과하는 평문 HTTP는 출구에서 읽을 수 있는 상태로 남고, HTTPS는 페이로드를 끝에서 끝까지 보호하는 유일한 것입니다. TLS는 또한 당신이 입력한 호스트 이름에 대해 아무 말도 하지 않으므로, 경로를 종료하는 누구에게나 목적지는 보이는 상태로 남습니다.
계정은 당신을 식별하며, 어떤 라우팅 선택도 그것을 바꾸지 않습니다: 헤더의 주소와 무관하게 서비스는 누가 로그인했는지 압니다. 네트워크를 충분히 보는 관찰자의 상관관계, 당신 자신의 기기 침해, 양식에 입력하는 모든 것은 두 설계 모두에서 살아남습니다. 두 도구를 신뢰를 옮기는 방법으로 다루고, 삭제하는 방법으로 다루지 마십시오.
각 프로젝트가 문서화하는 기본 구성에서 시작하고, 위의 두 명령으로 경로를 확인한 다음에야 Tor 아래에 VPN을 쌓는 것을 고려하십시오. 그것들을 중첩하는 것은 자체 실패 모드를 가진 구성이지 무료 업그레이드가 아닙니다.