프라이빗 DNS와 VPN: 각 계층이 실제로 무엇을 덮는가

휴대폰에는 프라이빗 DNS가 공급자 호스트 이름으로 설정되어 있고 동시에 VPN 앱이 실행 중이다. 둘 중 하나가 이제 이름 조회를 맡는다고 생각하기 쉽다. 이 문장이 암시하는 의미에서는 둘 다 아니다. 이유를 가장 빨리 보려면 링크를 누르는 순간부터 요청 하나를 따라가면 된다.

이 두 기능은 같은 여정의 서로 다른 지점에 있다. 프라이빗 DNS는 리졸버에 보내는 질문을 암호화한다. VPN은 응답의 연결이 가는 경로를 바꾼다.

그러니 둘 다 켜진 기기에서 순서대로 짚어 보고, 각 계층이 여전히 무엇을 볼 수 있는지 적어 두자.

첫 번째 단계: 조회가 앱을 떠난다

링크를 누른다. 무언가 연결되기 전에 앱은 그 호스트 이름에 대한 주소가 필요하다. Android에서는 해당 화면이 설정, 네트워크 및 인터넷, 프라이빗 DNS다. 공급자 호스트 이름을 고르면 기기는 엄격 모드가 된다. 그 호스트 이름으로 포트 853에서 TLS 기반 DNS를 수행하고, 암호화된 교환이 실패하면 포트 53의 평문으로 조용히 되돌아가는 대신 조회가 실패한다.

이것은 자동과는 의미 있는 차이다. 자동은 기회주의적 암호화를 쓰고, 네트워크가 방해하면 암호화되지 않은 리졸버를 기꺼이 사용한다. 조회가 절대 평문으로 나가지 않게 하는 것이 목표라면, 공급자 호스트 이름을 쓰는 엄격 모드가 그에 맞는 설정이다.

이 여정이 처음 드러내는 것은 이것이다. 조회는 로컬 네트워크로부터 보호되지만, 리졸버는 여전히 이름을 안다. 암호화가 덮는 것은 그 한 번의 도약이다. 그 리졸버의 운영자가 요청을 보는 것은 응답하는 일이 그의 일이기 때문이다.

두 번째 단계: 연결이 다른 경로를 택한다

리졸버가 주소를 돌려주고 앱이 그 주소로 연결한다. 이 단계는 조회가 어떻게 암호화되었는지의 영향을 받지 않는다. 터널이 없으면 연결은 평소의 공인 주소에서 나가고, 목적지 IP와 TLS 핸드셰이크 때문에 DNS 암호화 여부와 관계없이 호스트 이름은 보통 네트워크에 그대로 보인다.

VPN을 켜면 바로 이 단계가 바뀐다. 클라이언트의 라우팅 정책에 맞는 트래픽은 터널을 지나고, 로컬 네트워크는 VPN 종단점으로 가는 연결을 보며, 사이트는 보통 출구 주소를 본다. 이름 해석도 클라이언트가 무엇을 밀어 넣느냐에 따라 터널 안을 지날 수 있다.

그 구분이 비교 전체를 한 문장으로 만든 것이다. DNS 암호화는 누가 질문을 읽을 수 있는지에 답한다. VPN은 대화가 어디로 가는지에 답한다.

세 번째 단계: 터널 안에서 DNS는 정책 문제가 된다

이제 두 기능이 서로 맞물리고, 브라우저가 늘 그렇듯 변수를 만든다. 자체 보안 DNS 설정이 있는 브라우저는 운영체제에 묻는 대신 HTTPS로 자기가 고른 리졸버에 조회를 보낼 수 있다. Android의 프라이빗 DNS 설정은 그 결정에 닿지 않는다.

Firefox에서는 스위치가 설정, 개인 정보 및 보안, 보안 DNS 사용 설정에 있다. Chrome에서는 설정, 개인 정보 보호 및 보안, 보안 DNS 사용에 있다. 둘 다 특정 공급자로 고정하거나 꺼 둘 수 있고, 켜면 해당 조회에서는 터널의 DNS 구성이 우회된다. 페이지 트래픽은 여전히 터널을 쓰는데도 그렇다.

VPN이 자기 리졸버를 밀어 넣고 브라우저가 자기 것을 고집하면 분열이 생긴다. 이름은 해석되고 페이지는 열리지만, 터널을 지나야 했던 조회는 곧장 밖으로 나갔다. 리졸버 주소가 VPN 종단점과 다르다는 것 자체가 유출의 증거는 아니다. 그러나 당신이 선언한 의도와 어긋나는 조회 경로는 고칠 만하다.

네 번째 단계: 내부 이름에서 깨진다

회사 VPN에 연결해 인트라넷 호스트를 연다. 브라우저의 보안 DNS가 켜져 있고 공용 리졸버를 가리키면, 그 이름은 브라우저에게 존재하지 않는다. 터널은 올라가 있고 나머지는 다 동작하는데, 호스트 이름 하나만 실패하며 사이트가 죽은 것처럼 보인다.

같은 고장이 Android에서는 반대 방향으로 나타난다. 공용 공급자를 쓰는 엄격한 프라이빗 DNS는 내부 리졸버만 아는 이름을 해석하지 못하고, 엄격 모드에는 대체 경로가 없다. 휴대폰의 DNS를 공용 암호화 리졸버와 기업 리졸버로 나누는 것은 설정 문제가 아니라, VPN을 운영하는 사람이 답해야 할 라우팅 정책 문제다.

터널을 탓하기 전에 이것을 확인하자. 내부 이름을 조회하고, 그다음 브라우저의 보안 DNS를 끈 상태에서 같은 이름을 조회한다. 해석되면 문제는 리졸버 선택이었고 연결이 아니었다.

이 여정이 바꾸라고 말하는 것

거의 모든 것이 네 화면에 담겨 있다. 이 순서로 보고 각 화면이 무엇을 말하는지 적어 두자. 답은 보통 조합 속에서 보인다.

1. Android 설정, 네트워크 및 인터넷, 프라이빗 DNS: 자동 또는 공급자 호스트 이름, 그리고 어느 호스트 이름인지.
2. 브라우저의 보안 DNS 설정: 꺼짐, 또는 특정 리졸버에 고정.
3. VPN 클라이언트의 DNS 정책: 리졸버를 밀어 넣는가, 분할 터널이 여전히 이름이 필요한 무언가를 빼고 있는가.
4. 터널이 올라간 상태에서 내부 호스트 이름 테스트. 두 번 수행하고, 한 번은 브라우저 DNS를 켜고 한 번은 끈다.

그다음 수정을 요구 사항에 맞춘다. 거꾸로가 아니다. 조회가 암호화되어 나가고 당신이 고른 리졸버에 닿는 것이 요구 사항이라면 엄격한 프라이빗 DNS를 설정하고 브라우저를 그에 동의시킨다. 트래픽이 다른 곳에서 나가는 것이 요구 사항이라면 터널을 구성하고, DNS 설정이 주소를 옮겨 줄 것이라는 기대를 버린다.

경계도 잊지 말자. 두 기능 중 어느 것도 적대적인 목적지를 안전하게 만들지 않고, 어느 것도 당신이 로그인한 신원을 지우지 않는다. 암호화는 누가 질문을 읽을 수 있는지를 바꾸고, 터널은 연결이 어디로 가는지를 바꾼다. 둘 다 계정을 익명으로 만들지 않는다.