VPN 없이도 메일이 되는데, 몰래 터널을 타고 있는 걸까?
Exchange 계정은 게이트웨이도, 프로토콜도, 경로도 선택하지 않습니다. 추측하기 전에 배포 방식, 공개 진입점, 관리형 VPN, 활성 터널 중 무엇인지 확인하세요.
VPN 아이콘을 한 번도 표시한 적 없는 휴대폰으로 메일이 계속 도착하면, 보이지 않는 무언가가 터널을 통해 전달하고 있다는 결론에 이르기 쉽습니다. 보통은 보이지 않는 무언가가 개입하지 않습니다. Exchange 계정을 추가해도 게이트웨이, 프로토콜, 인증서, 경로가 선택되지 않는 것은 계정이 서비스 신원이고 터널이 다른 누군가가 구성한 네트워크 배열이기 때문입니다. 유용한 단계는 없었던 터널을 찾는 대신 실제로 어떤 배열을 갖고 있는지 확인하는 것입니다.
세 가지 배열, 하나의 동일한 화면
세 가지 모두 기기에 메일이 나타나는 것으로 끝나고, 설정 화면은 어느 경우든 똑같아 보입니다. 다른 것은 누가 경로를 구성했는지와 그것이 존재함을 어떤 증거가 입증하는지입니다.
| Arrangement | Who set it up | What proves it |
|---|---|---|
| Approved public mail entry | The service owner, at the publishing layer | A published endpoint reached over TLS with its own authentication |
| Managed app or account VPN | Device management, as explicit policy | A profile binding that traffic to a VPN association |
| Already active tunnel | An always-on service or an earlier manual connect | Tunnel state plus routes and scope that include the mail destination |
공개 도달성은 끊임없이 잘못 읽히기 때문에 따로 한 문장이 필요합니다. 공개된 메일 서비스는 인증이 없는 서비스가 아니며, 메일에 도달할 수 있다는 사실은 회사 네트워크의 나머지가 도달 가능한지에 대해 아무것도 말하지 않습니다. 그것은 서로 다른 사람이 내리는 서로 다른 결정입니다.
기기 관리가 실제로 묶을 수 있는 것
Apple 플랫폼은 앱별 및 메일 도메인별 VPN 규칙을 지원하며, 관리형 iOS 또는 iPadOS 메일은 계정별 VPN 연결을 가질 수 있습니다. 그 연결은 누군가 선택한 값이 있는 프로비저닝 설정이고, 그래서 휴대폰에 이메일 주소와 비밀번호를 입력해 추론할 수 없습니다.
Android 관리와 타사 클라이언트에는 자체 앱 및 프로필 제어가 있으며, 어느 것도 Apple 계정 페이로드와 호환되지 않습니다. 한 플랫폼에 있는 정책은 다른 플랫폼에서 의도적으로 재현해야 합니다. 그 정책은 메일 계정을 따라 이동하지 않으며, 같은 사람이 둘 다에 로그인했다고 해서 도착하지도 않습니다. 이 이전이 스스로 일어나리라고 기대하는 것이 플랫폼 간 «내 휴대폰에서는 되는데» 보고의 상당 부분 뒤에 있습니다.
신원과 전송은 분리된 채로 남는다
메일 서비스와 VPN은 디렉터리나 ID 공급자를 정당하게 공유할 수 있고, 사람들은 그 공유 로그인을 공유 세션의 증거로 읽습니다. 그렇지 않습니다. 사용자 이름 텍스트가 반복된다고 해서 메일 앱이 VPN 세션을 물려받았다는 뜻은 아니며, 서비스마다 무관한 비밀번호를 지어낼 이유도 아닙니다.
두 서비스는 각자의 조건으로 각자의 인증을 요구합니다. 성공한 메일 로그인을 VPN 클라이언트에 붙여넣을 대상으로 취급해서는 안 되고, 올라온 터널은 메일 서버가 어떤 계정을 받아들일지에 대해 아무것도 말하지 않습니다. Intune 메일 프로필 참조는 VPN 연결을 계정 이름에서 파생된 속성이 아니라 별도 설정으로 다루기 때문에 여기서 유용한 예입니다.
새 동기화가 캐시된 받은편지함을 이긴다
캐시된 받은편지함은 현재 경로가 전혀 없어도 완벽하게 건강해 보일 수 있다, 그래서 앱을 열어 지난주 메시지를 보는 것은 아무것도 증명하지 않습니다. 승인된 새 동기화 테스트를 사용하고 그에 딸린 상태나 로그 증거를 읽으십시오.
다음으로 결과를 실제로 좌우하는 네 가지, 즉 구성된 서비스 엔드포인트, 리졸버가 반환하는 값, 어떤 관리형 프로필이 적용되는지, 현재 VPN 상태를 확인하십시오. 비슷한 이름의 개인 메일 앱은 업무 앱의 네트워크 정책을 따르지 않으며 완전히 정당한 이유로 다르게 동작하므로 올바른 맥락에서 하십시오. 이 두 맥락을 섞는 것이 작동하는 구성을 고장으로 보고하는 방식입니다. 하나의 앱이 정책을 따르는데 거의 같은 이름의 이웃 앱이 무시하는 대부분의 경우도 이것으로 설명됩니다.
확인한 것을 적어 두십시오
접근에 터널이 필요하다고 가정한다면, 소유자는 허용된 사설 경로와 터널 없이의 동작을 모두 확인해야 합니다. 서비스가 의도적으로 공개되어 있다면, 터널의 부재를 메일이 암호화되지 않았다는 증거로 삼지 말고 TLS 검증, 인증, 접근 제어를 유지하십시오.
지원 기록에는 메일 제품, 엔드포인트, 계정 범위, 연결 정책을 적어야 합니다. 비밀번호가 같다는 것은 그 네 가지 중 어느 것의 증거도 아니며, 티켓에 네 문단이 있고 사실이 하나도 없는 가장 흔한 이유입니다.