DNS를 통한 VPN은 VPN DNS 서버와 다릅니다

DNS를 통한 VPN은 전송 방식에 대한 개념이며, 기기를 사용자 지정 리졸버로 향하게 하는 것과 같은 말이 아닙니다. 혼란을 정리하는 질문은 DNS 메시지가 실제로 무엇을 나르는가입니다. 일반 VPN은 대상 앱이 사설 이름을 찾을 수 있도록 리졸버를 설치할 수 있고, 그 리졸버를 바꾸면 이름 해석만 바뀝니다. 세 가지 구성은 용어만 공유할 뿐 그 밖에는 거의 공통점이 없으므로 아래 점검을 순서대로 수행하세요.

세 가지 구성을 분리하세요

첫 번째 구성에서는 VPN이 리졸버나 이름 정책 설정을 제공합니다. 애플리케이션 데이터는 여전히 자체 네트워크 연결로 이동하고, 터널은 어느 서버가 조회에 응답하는지에만 영향을 줍니다.

두 번째에서는 암호화된 DNS가 DNS 교환 자체를 보호합니다. HTTPS를 통한 DNS와 TLS를 통한 DNS는 선택한 리졸버로 가는 질의를 감싸며 다른 애플리케이션의 패킷은 나르지 않습니다. 또한 선택한 리졸버로부터 질의 이름을 숨기지도 않는데, 이는 로컬 네트워크로부터 숨기는 것과 다른 신뢰 경계입니다.

세 번째에서는 협력하는 클라이언트가 다른 데이터를 DNS 메시지에 인코딩하고 협력하는 엔드포인트가 이를 재구성합니다. 일반 리졸버 경로가 전송로가 되며, 리졸버는 이제 이름 서비스가 아니라 데이터 경로의 구성 요소입니다.

DNS 메시지가 무엇을 나르는지 확인하세요

리졸버를 바꾸고 애플리케이션의 트래픽 경로가 바뀌는지 관찰하세요. 애플리케이션이 여전히 같은 소켓으로 같은 주소에 연결한다면 이름 해석을 바꾼 것뿐입니다.

DNS로 나르는 터널에는 서버 측의 대응 구성이 필요합니다. Iodine은 문서화된 예로, 프로젝트 문서는 DNS를 통과하는 IP 터널을 설명하며 인코딩을 이해하는 서버 구성 요소를 요구합니다. Android에서 공용 리졸버 주소를 입력해도 그 엔드포인트가 생기지 않으며, 두 제품이 공유하는 마케팅 용어는 프로토콜 명세가 아닙니다.

패킷 캡처가 결정적인 점검입니다. 리졸버로 가는 일반 질의만 보이고 다른 것이 없다면 터널은 없습니다. 질의 이름과 응답에 인코딩된 페이로드가 보인다면 운반자를 찾은 것이고, 다음 질문은 얼마나 옮길 수 있는가입니다.

약속하기 전에 용량을 확인하세요

DNS는 질의와 응답을 위해 설계되었지 대량 전달을 위해 설계되지 않았습니다. 인코딩 오버헤드, 메시지 크기 제한, 리졸버 동작이 모두 명목 경로의 몫을 차지하므로 실제 용량은 기반 링크가 시사하는 것보다 낮습니다. 직접 경로에서 측정하지 않은 처리량 수치는 예산이 아니라 가설로 취급하세요. 요청-응답 운반자에서는 업로드와 다운로드가 서로 다른 한계에 부딪힐 수 있으므로 양방향을 모두 측정하세요.

어떤 트래픽이 터널로 들어갈지도 클라이언트가 결정해야 합니다. 로컬 VPN 서비스 인터페이스는 패킷을 모을 수 있지만, 그 인터페이스는 원격 전송이 패킷을 어떻게 보호하거나 전달하는지에 대해 아무것도 말하지 않습니다. 운반자가 스트림이 아니라 요청-응답 프로토콜일 때 단편화와 재전송은 다르게 동작하며, 열린 채로 유지되는 연결은 대화형 지연에 대해 거의 알려주지 않습니다.

나르려는 트래픽으로 측정하세요. 주기적인 하트비트에는 괜찮아 보이는 터널이 대화형 세션에는 쓸 수 없을 수 있고, 그 반대도 사실입니다.

운반자의 보안을 확인하세요

DNS 캡슐화가 기밀성이나 강한 인증을 제공한다고 가정하지 마세요. 리졸버 경로와 터널 엔드포인트는 구현이 노출하는 것을 볼 수 있고, 그 노출은 설계에 따라 다릅니다.

암호화와 운반자 선택은 별개의 속성입니다. 터널은 평범한 IP 경로 위에서 암호화될 수 있고, DNS로 나르는 터널은 페이로드 보호와 함께 또는 없이 구축할 수 있습니다. 어쨌든 애플리케이션의 HTTPS는 그대로 두고, 터널의 이름이 아니라 실제 보안 설계를 평가하세요.

요구 사항이 로컬 네트워크로부터의 프라이버시라면, 암호화된 DNS와 데이터 터널은 그 서로 다른 부분에 답합니다. 하나를 고르기 전에 어떤 관찰자로부터 지키려는지 적어 두세요.

수정을 실제 장애에 맞추세요

일반적인 느린 VPN의 경우, DNS로 나르는 터널로 바꾸면 문제 위에 제한된 전송로를 더하게 됩니다. 무선 품질, 혼잡, 서버 부하를 고치지 않으며 보통 그것들을 더 눈에 띄게 만듭니다.

사설 이름 장애의 경우 먼저 의도한 리졸버 정책(어느 서버가 응답해야 하는지, 어떤 이름이 범위에 있는지, 클라이언트가 사용할 수 있는지)을 확인하세요. 그다음 요구 사항에 맞는 승인된 전송로를 고르고, 다음 사고에서 같은 조사를 다시 시작하지 않도록 리졸버 구성을 변경 기록에 남기세요.

점검 목록은 짧습니다: 구성을 식별하고, 메시지가 무엇을 나르는지 확인하고, 용량을 측정한 다음 신뢰를 검토하세요. 증상과 맞지 않는 단계가 있다면 나머지 두 구성이 아직 작동 중이라는 뜻입니다.