Android VPN은 전체 호스트 이름은 확인하지만 짧은 이름은 확인하지 못한다

터미널 에뮬레이터에files를 입력하면 아무것도 돌아오지 않습니다. 그런데files.corp.example를 입력하면 같은 서버가 곧바로 응답합니다. VPN 자격 증명은 아무것도 바뀌지 않았고 사설 DNS 서버가 고장 난 적도 없습니다. Android에서는 짧은 레이블과 전체 이름이 리졸버를 거치는 경로가 다르며, 그중 하나는 터널 소유자가 제공해야 하는 설정에 의존합니다. 지금의 결정은 어떤 DNS 서버를 바꿀지가 아니라, 앱이 실제로 쓰는 네트워크를 누가 통제하는지입니다.

검색 도메인은 주소가 아닙니다. 리졸버가 포기하기 전에 맨 레이블에 덧붙이는 접미사 목록입니다.

검색 접미사와 DNS 서버는 별개의 필드

리졸버 주소는 어디에 물을지를 Android에 알려 줍니다. 검색 접미사는 맨 왼쪽 레이블만 줄 때 무엇을 물을지를 알려 줍니다. 둘 다 같은 네트워크 객체에 있고, 어느 쪽이든 따로 빠질 수 있습니다.

바로 그 독립성 때문에 전체 호스트 이름이 동작합니다. 완전히 정규화된 이름에는 접미사가 필요 없습니다. 이미 서버로 가는 문자열이기 때문입니다.

Android는 이 분리를LinkProperties을 통해 드러냅니다. DNS 서버 목록과 도메인 검색 목록은 같은 객체에 있고, 앞의 것이 꽉 차 있어도 뒤의 것은 흔히 비어 있습니다. 리졸버는 있는데 도메인이 없는 네트워크는 접미사가 한 번도 적용되지 않은 네트워크이지, 짧은 이름을 거부한 서버가 아닙니다.

무엇이든 바꾸기 전에 실제 네트워크를 읽으세요

Wi-Fi, 셀룰러, VPN 인터페이스는 서로 다른 세 개의 네트워크이고, 터널이 올라오면 기본이 됩니다. 따라서 사무실 Wi-Fi에서 통했던 접미사가 터널이 활성인 동안 유효한 접미사라는 보장은 없습니다. 지난주에 설정한 네트워크가 아니라 앱이 실제로 선택된 네트워크를 확인하세요.

기기의 터미널 셸은 여기서 좋은 증인이 아닙니다. 그resolv.conf은 리졸버에 대한 한 가지 관점만 반영하고 모든 앱의 관점을 반영하지는 않기 때문입니다.

브라우저 주소 표시줄은 층을 하나 더 얹습니다. 맨 단어가 검색 쿼리로 처리되거나,브라우저 자체의 암호화 DNS 정책을 통해 확인될 수 있으므로 Chrome에서 페이지가 열린다고 해서 시스템 조회가 증명되지는 않습니다. 플랫폼 리졸버를 쓰고 무엇이 돌아왔는지 출력하는 것으로 시험하세요. 그다음 짧은 형식과 전체 형식을 같은 세션, 같은 네트워크에서 실행하고 어느 쪽이 응답했는지 기록하세요.

VPN 앱을 만드는 쪽이라면 빌더에서 접미사를 붙이세요

앱이VpnService을 통해 인터페이스를 세울 때,addSearchDomain이것이 이 용도로 지원되는 입력입니다. 다음과 같은 도메인 문자열을 받습니다.corp.example그리고 서버 주소를 넘기는 다른 방법은 아닙니다.

이 호출은 접미사를 짓고 있는 네트워크에 묶으므로 나중에 뒤집을 전역 설정은 없습니다. 앱이 인터페이스를 내렸다가 재연결 시 다시 지으면 새 빌더에 접미사를 다시 더해야 하며, 그렇지 않으면 대체 네트워크는 접미사 없이 올라옵니다.

데스크톱 프로필 가져오기가 이 필드를 잃는 지점이 여기입니다. 내보내기는 도메인을 자기 모델에 적고, Android 프런트엔드는 아는 옵션만 매핑하므로, 결과 인터페이스는 다른 모든 면에서 올바르게 보입니다. 노트북에서 되고 휴대폰에서 안 되는 프로필은 보통 매핑의 빈틈이지 프로토콜 문제가 아닙니다.

VPN을 쓰기만 한다면 이것은 직접 설정할 일이 아닙니다

접미사를 더하는 클라이언트 측 편집은 없고, 가짜로 만들 수 있는 전역 속성도 없습니다. 값은 터널을 소유한 쪽이 전달합니다. 관리형 클라이언트 프로필, 플랫폼별 매핑, 또는 서버가 밀어 주는 무엇이든 통해 옵니다. 어느 플랫폼이고 어떤 이름이 실패하는지 말하세요. 데스크톱과 모바일 프런트엔드는 바로 이 필드에서 갈립니다.

데스크톱 프로필을 다시 가져와도 모바일 매핑에 대해서는 아무것도 증명하지 못합니다.

세 가지 조건이 결함인지 예상된 한계인지를 가릅니다. 첫째, 조직이 짧은 레이블을 애초에 지원되는 이름으로 보는가, 아니면 사무실 Wi-Fi에서만 통했던 편의인가? 둘째, 실패하는 조회가 시스템 리졸버를 완전히 우회할 수 있는 브라우저에서 오는가? 셋째, 짧은 이름이 터널을 통해 닿아야 하는가, 아니면 LAN에서만인가? 마지막 답이 LAN 전용이라면 접미사를 더하는 것은 사무실 밖에서 확인되고 그다음 라우팅되지 않는 이름을 만들 뿐입니다.

접미사가 있는데도 짧은 이름이 실패할 때

도메인 검색 목록에 이미corp.example가 보인다면 접미사를 탓하지 마세요. 리졸버가 확장된 이름에 대해 아예 응답하는지 확인하세요. 접미사는 묻는 질문만 바꿉니다. 서버가 호스팅하지 않는 영역에 권한을 주지는 않습니다.

그다음 경로를 확인하세요. 확인되지만 터널이 나르지 않는 주소는 연결 시 실패하며, 이는 조용히 포기하는 브라우저의 조회 실패와 똑같이 보입니다.

인증서는 따로 언급할 가치가 있습니다. HTTPS 검증은 실제로 입력한 호스트 이름을 쓰므로, 올바르게 확장되는 짧은 이름도 핸드셰이크에서는 여전히files를 제시합니다.files.corp.example위해 발급된 인증서는 그것에 대해 유효하지 않으며, 그 오류는 올바른 동작이고 처음의 DNS 문제의 증상이 아닙니다.

다음에 할 일

무엇이든 만지기 전에 분리를 확인하세요. 전체 이름은 확인되고 짧은 이름은 안 되며, 같은 앱, 같은 세션. 그다음 선택된 네트워크를 찾아 그 도메인 검색 목록을 리졸버 목록과 나란히 읽으세요. 둘 중 어느 쪽이 비었는지가 누가 행동해야 하는지를 알려 줍니다. 앱이 당신 것이면 당신, 아니라면 터널 운영자입니다.

마지막으로 이식성이 중요한 곳에서는 북마크와 클라이언트 구성에 전체 서비스 호스트 이름을 쓰세요. 네트워크 전환을 견디고, 모바일 프런트엔드가 구현하지 않을 수 있는 매핑에 의존하지 않으며, 인증서가 발급된 이름과 일치합니다.