VPN을 거쳐도 로컬 네트워크가 여전히 보는 것
터널은 내용을 숨길 뿐 당신의 존재를 숨기지 않습니다. 하나면 모두 가려진다고 가정하기 전에 접속 네트워크, 관리되는 기기, VPN 사업자가 무엇을 아는지 비교하세요.
누군가 VPN이 자기 트래픽을 숨기느냐고 물을 때마다 세 관찰자가 하나의 질문으로 접힙니다. 연결된 네트워크, 손에 든 기기, 그리고 터널의 운영자입니다. 각자는 다른 것을 배우고, 터널은 그 관점들 각각을 다른 방식으로 바꿉니다. 반대 방향으로 생각하며 제시된 주장에서 시작하는 편이 좋습니다. 검증을 견뎌야 하는 것은 바로 그 주장이기 때문입니다. 어떤 주장이 필요한지 정한 다음, 도구를 그 주장과 비교하세요.
첫째 주장: 아무도 트래픽을 읽을 수 없다
가장 좁은 주장부터 시작합니다. 내용은 읽을 수 없는 상태로 남습니다. 경로 위의 수동적 관찰자는 TLS 세션 안을 볼 수 없으므로, 터널은 이미 HTTPS를 쓰는 사이트에 거의 더하지 않고 두 끝점에 대해서는 아무것도 더하지 않습니다. 이 주장을 깨는 쪽은 기기를 통제하는 사람입니다. 검사 프록시가 연결을 종료하고 기기가 이미 신뢰하는 루트로 다시 서명하기 때문입니다. 인증서 사슬에 그 루트를 설치한 조직의 이름이 있어도 자물쇠가 계속 보이는 이유입니다.
security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root
macOS에서는 그 파이프라인이 창을 열지 않고도 기기의 키체인에 있는 인증서마다 주체 줄을 하나씩 출력합니다. Windows에서는 certutil -store Root가 certlm.msc가 그래픽으로 보여 주는 것과 같은 저장소를 나열합니다. 학교나 고용주, 네트워크 보안 제품의 루트가 찾아야 할 항목입니다. 하나를 찾는 것은 가로채기가 가능하다는 것만 증명하며, 그것이 일어나고 있다는 증거는 아닙니다.
그에 대해 무엇을 할 수 있는지는 기술이 아니라 정책의 문제입니다. 소유하지 않은 하드웨어에서 프로필이나 검사 루트를 제거하는 것은 보통 허용 사용 협약을 위반하고, 관리 시스템은 이를 알아채고 다시 적용하는 경향이 있습니다. 따라서 기기 소유자가 당신의 트래픽을 읽지 않아야 한다는 요구에는 다른 설정이 아니라 다른 기기가 필요합니다.
둘째 주장: 아무도 당신이 어디로 가는지 모른다
목적지는 더 어려운 주장입니다. 페이지가 로드되기 전에 두 가지 공개가 일어나기 때문입니다. 조회는 시스템이 사용하도록 설정된 확인자로 가고, 그 응답은 그것을 나르는 네트워크에 보입니다. 이어서 TLS 핸드셰이크는 양쪽 끝에서 Encrypted Client Hello가 지원되지 않으면 요청한 서버 이름을 평문으로 나릅니다. 두 공개 모두 복호화를 포함하지 않으므로 터널은 어느 쪽에도 영향을 주지 않습니다.
resolvectl status | grep -A2 "Link"
nslookup example.com
어떤 확인자가 실제로 쓰이는지가 노출을 결정하며, 이는 논쟁하는 대신 측정할 수 있습니다. Linux에서는 resolvectl status가 링크마다 DNS 서버를 출력하고, 그 출력은 사이트 확인자가 응답하는지 밀어 넣은 확인자가 응답하는지 알려 줍니다. Windows는 같은 질문에 nslookup example.com로 답하며, 그 출력의 첫 블록이 응답한 DNS 서버입니다.
노트북이 터널이 올라오기 전에 사이트 확인자에게 물을 때, 또는 프로필이 대체 서버 없이 도착해 예전 것이 계속 쓰일 때, 관리자는 아무것도 복호화하지 않고 호스트 이름을 계속 수집합니다. 브라우저의 암호화 DNS는 밀어 넣은 확인자를 우회하거나 아예 차단되어 닫힌 채 실패합니다. 출구 사업자는 자기 쪽에서 같은 이름을 봅니다. 따라서 확인자를 바꿔도 그 공개가 터널 제공자에게서 멀어지지 않습니다.
셋째 주장: 아무도 당신이 접속했음을 모른다
셋째 주장은 터널이 뒷받침할 수 없는 주장입니다. 패킷은 여전히 로컬 네트워크를 지나가기 때문입니다. 그 네트워크는 끝점 주소, 대략적인 양, 시각, 그리고 오래 유지되는 암호화 세션이 하나 있다는 사실을 배웁니다. 그것만으로도 차단하고 제한하고 단순히 알아차릴 수 있습니다. 패킷을 읽지 못하는 방화벽도 통과를 거부할 수 있습니다. 관찰되는 것은 아무도 관찰하지 않는 것과 같지 않으며, 관찰자를 옮긴 것이지 지운 것이 아닙니다.
분할 터널링과 밀어 넣은 경로를 무시하는 애플리케이션은 터널 밖에 이전과 똑같이 보이는 흐름을 만듭니다. 세심한 관찰자가 가장 먼저 알아차리는 것이 그 흐름이며, 클라이언트의 경로 표는 어떤 목적지가 제외되는지 보여 줍니다.
반대편 사업자는 그 장면의 거울상을 쥐고 있습니다. 출구 주소, 시각, 양, 그리고 대개 사이트 이름입니다. 당신의 제공자가 시점을 가진 쪽이 되며, 이는 보이지 않음과는 다른 거래입니다. 신뢰하는 제공자를 고르는 것은 실제 결정이지만, 결과를 관찰되지 않는다고 부르는 것은 그렇지 않습니다.
어떤 주장이 필요한지 정하세요
클라이언트를 건드리기 전에 요구 사항을 한 줄로 적으세요. 내용을 숨길지, 목적지를 숨길지, 아니면 접속 여부 자체를 숨길지입니다. 내용은 HTTPS와 터널이 이미 처리하고, 목적지에는 사이트 설비를 완전히 우회하는 확인자와 경로가 필요합니다.
셋째 요구 사항이 어색한 이유는 암호화되었든 아니든 어딘가에서 무언가가 여전히 눈에 보이게 연결되어 있기 때문입니다. 어떤 클라이언트 설정도 그것을 바꾸지 않습니다. 요구 사항과 정책이 갈라진다면 그 간극은 정책을 가진 사람과의 대화에 속하며 클라이언트 옵션에 속하지 않습니다. 그것에 답할 수 있는 사람은 정책을 쓴 사람입니다.