휴대폰의 Private DNS가 VPN 이름 조회를 깨뜨리는 이유

터널은 연결된 채로 있고 다른 모든 지표가 정상으로 보이는데도 앱이 이름을 확인하지 못한다. 휴대폰에서는 VPN 프로필이 아니라 기기가 고른 리졸버가 흔한 원인이다. 두 설정이 같은 조회에 대해 각각 권한을 주장할 수 있다. 어느 쪽이 이기는지, 그리고 그것이 질문에 답할 수 있는지 알아내는 편이 터널을 건드리는 것보다 빠르다.

두 설정이 같은 이름을 결정한다

휴대폰의 Private DNS 설정은 기기를 위한 리졸버를 고르며, 자동 선택부터 지정된 호스트 이름까지 모드가 있다. VPN 프로필도 동시에 자체 리졸버를 밀어 넣을 수 있고, 둘은 서로 다른 화면에서 서로 다른 소유자에 의해 구성된다. 모든 앱에서 한쪽이 반드시 다른 쪽을 덮어쓰는 것은 아니다. 그래서 작동하는 터널과 실패하는 조회가 모순 없이 공존한다.

브라우저 안의 보안 DNS가 자체 공급자를 고를 수 있기 때문에 브라우저는 세 번째 계층을 더할 수 있다. 오류를 낸 앱이 셋 중 누가 답했는지 알려 주는 유일하게 신뢰할 수 있는 단서다. 리졸버도 답할 수 있어야 한다. 회사 내부 전용 이름은 공용 리졸버의 데이터에 없으므로, 조회는 연결이 아니라 내용 때문에 실패한다.

필요한 이름에 따라 모드를 고르십시오

기기가 내부 이름을 확인해야 한다면 리졸버는 그 영역을 보유한 것이어야 하며, 보통 터널의 리졸버나 조직이 문서화한 분할 DNS 구성이 그것이다. 공용 이름만 중요하다면 엄격한 암호화 리졸버는 평문 조회도 없애는 정당한 선택이다. 결정은 암호화에 대한 선호가 아니라 이름에서 나온다.

실패 시 동작도 모드에 따라 다르다. 리졸버에 닿지 못하는 엄격한 선택은 모든 이름에서 실패를 내지만, 허용된 폴백이 있는 모드는 공용 이름은 되게 하고 내부 이름은 깨진 채로 둘 수 있다. 그 차이가 설정 화면을 열기 전에 어느 모드인지 알려 준다. 관리 기기에서는 승인된 정책이 결정하며 사용자가 안전하게 우회할 수 없다. 개인 환경에서는 문서화된 비교 한 번이면 충돌을 확인할 수 있고, 의도한 개인정보 보호 설정은 비활성으로 두지 말고 나중에 복원해야 한다.

어떤 앱이 묻는지 확인하십시오

신고한 앱에서 실패를 재현하고, 오류가 이름 오류인지 연결 오류인지 적는다. 한 앱에서는 이름 오류가, 다른 앱에서는 페이지가 열린다면 이는 깨진 터널이 아니라 두 리졸버의 특징이다.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

그 명령들은 기기의 현재 구성을 읽으며, 제조사 빌드는 기본값의 이름을 바꾸거나 제한할 수 있으므로 출력은 사양이 아니라 단서로 다루십시오. Android의 Private DNS 문서는 모드와 기기가 기대하는 호스트 이름 형식을 설명한다.

그 답을 VPN 프로필이 밀어 넣는 리졸버와 비교하십시오. 일치하지 않는다면 충돌을 찾은 것이며, 남은 질문은 조직이 어느 쪽을 이기게 하려는가이다.

비교 한 번 후 의도한 설정을 복원하십시오

설정 하나를 바꾸고, 두 이름을 다시 테스트한 뒤 설정을 되돌리십시오. 허용적 모드로 남겨 둔 기기는 내부 이름을 확인하고 모든 공용 조회를 먼저 답하는 쪽으로 조용히 보내며, 이는 아무도 기록하지 않은 개인정보 변경이다.

결과를 규칙으로 적으십시오: 내부 이름은 이 리졸버로, 공용 이름은 저 리졸버로 확인되고, 브라우저는 기기를 따르거나 따르지 않는다. 리졸버를 지목하는 규칙은 검증 가능하지만, VPN을 고쳤다는 메모는 그렇지 않다. 그다음 기기의 다른 무언가가 당신이 바꾼 리졸버에 의존하는지 확인하십시오. 업데이트 확인, 캡티브 포털 감지, 메일 클라이언트는 각자 요청을 보내며, 사용자가 무관한 문제로 보고하는 방식으로 실패한다.