iPhone의 Wi-Fi 설정에 프라이빗 리졸버 주소를 입력하면 그 전화가 네트워크를 떠날 때까지 작동하며, 바로 그때 VPN이 제어를 넘겨받아야 합니다. 이것이 모바일 DNS의 첫 번째 함정인데, 설정을 입력한 위치가 적용 범위를 정의하며 그 범위는 대부분의 사람이 가정하는 것보다 좁습니다. 무엇이든 편집하기 전에, 답이 어떤 제어를 건드려야 하는지를 결정하므로 배포에 대한 세 가지 질문에 답하십시오. 이 순서를 설정 찾기가 아니라 설계 검토로 다루십시오.

리졸버 주소를 입력하기 전의 세 가지 질문

첫째, 어떤 이름에 실제로 특별한 처리가 필요한가요? corp.example 같은 프라이빗 존은 네임스페이스이지 단일 호스트가 아니며, 답은 하나의 레코드가 아니라 도메인이어야 합니다. 둘째, 그에 대해 권한 있는 리졸버는 무엇이고 그 서비스는 누가 소유하나요? 셋째, 터널인지 라우팅된 Wi-Fi 네트워크인지 아니면 전혀 다른 것인지, 어떤 경로가 그 리졸버를 전화에서 도달 가능하게 만드나요?

그 세 가지 중 어느 것에도 소유자가 없으면 멈추십시오. 네임스페이스, 권한 있는 출처, 도달 가능한 경로 없이 이루어진 DNS 변경은 사무실과 다르게 셀룰러에서 실패할 추측입니다.

Wi-Fi DNS 항목은 그 Wi-Fi 네트워크에 속한다

iOS의 수동 DNS 구성은 네트워크별로 저장됩니다. 전화가 해당 SSID에 연결되어 있는 동안 적용되고 연결되어 있지 않으면 적용이 중단되므로, 셀룰러 트래픽을 제어하거나 VPN 클라이언트가 무엇을 하는지 설명할 수 없습니다. 셀룰러에서 실패하는 앱을 고치기 위해 이것을 편집하는 것은 실패하는 경로가 결코 읽지 않는 설정을 바꾸는 일입니다.

그렇다고 네트워크별 DNS가 쓸모없어지는 것은 아닙니다. 홈 랩이나 단일 사무실 SSID에는 내부 리졸버에 도달하는 가장 간단한 방법이며, 그 경계에 대해 정직합니다.

VPN의 DNS 메커니즘은 프로토콜과 클라이언트를 따른다

iOS의 패킷 터널 제공자는 Apple의 DNS 설정 API를 통해 DNS를 구성할 수 있으며, 이는 연결을 소유한 터널에 리졸버 주소와 도메인 일치를 노출합니다. 네이티브 IKEv2 구성은 게이트웨이가 밀어낼 때 IKE 구성 페이로드를 통해 DNS를 받을 수 있지만, 특정 클라이언트가 받은 것을 적용하는지는 검증해야 할 구현 세부 사항입니다. 앱 기반 클라이언트는 자체 확인 경로를 완전히 구현할 수 있습니다.

이들은 서로 다른 통합 지점이며, 그중 하나의 결과가 모든 iPhone의 규칙이 되지는 않습니다. 지원되는 메커니즘은 사용 중인 프로토콜에 대해 프로파일이나 제공자가 문서화한 것입니다.

편의가 아니라 소유권으로 결정하라

기기가 관리되는 경우 프로파일 소유자가 VPN 구성과 함께 DNS 설정을 전달해야 하며, 그러면 재등록 시 사용자가 아무것도 기억하지 않아도 복원됩니다. 제공자 앱이 터널을 소유한다면 그 설정 화면이 살펴볼 곳이며, 그 문서가 무엇을 분리할 수 있는지에 대한 권위입니다. 전화가 개인용이고 필요가 하나의 네트워크에서 하나의 내부 이름이라면 네트워크별 설정이 적절합니다.

결정 규칙은 짧고, 설정은 연결이 프로비저닝되는 곳에 속합니다. 다른 곳에서는 다음 네트워크 변경이 지울 로컬 예외일 뿐입니다.

전화가 실제로 사용하는 경로에서 검증하라

프라이빗 이름이 필요한 앱에서 새 요청을 사무실 Wi-Fi, 셀룰러, 그리고 그 사이의 전환에서 시험하십시오. 자체 리졸버 통합이 있는 앱은 시스템과 다른 경로를 탈 수 있으므로 우연히 작동하는 브라우저 탭이 아니라 실제 앱을 시험하십시오.

프라이빗 이름이 실패할 때는 정확한 오류와 프로파일 상태를 보관하십시오. 이름이 존재하지 않는다고 답하는 공용 리졸버는 잘못된 질문에 올바른 답을 주는 것이며, 그것을 회사 리졸버 옆에 추가하는 것은 네임스페이스 설계가 아닙니다.

마지막으로 검증된 정책을 프로비저닝 출처와 함께 저장하십시오. 다음 재연결이나 등록은 프로파일이 그렇게 말했기 때문에 같은 이름 서비스를 복원해야 하며, 누군가 두 해 전 한 핫스팟에서 한 편집을 기억했기 때문이 아닙니다.

관련 글