Android: Always-On과 VPN 없는 차단, 올바른 짝 고르기

Always-On과 VPN 없는 차단은 서로 다른 두 설정이며 하나를 켠다고 다른 하나가 켜지지 않습니다. 필요한 짝은 기기 소유자, 터널이 덮는 앱, 잠금 해제 전의 동작이라는 세 조건에 달려 있습니다.

서로 다른 약속을 하는 두 스위치

Always-On은 지속을 약속하며 서비스가 끊기면 다시 시작합니다. 차단은 격리를 약속합니다. 터널을 쓸 수 없는 동안 덮인 트래픽에는 바깥으로 나갈 길이 없습니다.

세 번째 요소는 앱별 범위이며 이는 클라이언트나 관리 정책에 속하고 두 시스템 스위치에는 없습니다. 범위를 정하지 않고 차단하면 요구보다 넓거나 좁은 정책이 됩니다.

첫 번째 결정: 관리 기기인가, 사용자 설정인가

관리 기기에서는 정책이 Always-On과 잠금을 쥐고 있으며 로컬 스위치가 없거나 회색이거나 다음 정책 갱신에서 되돌아갈 수 있습니다. 이는 정책이 작동하는 모습이지 우회할 결함이 아닙니다. 요구는 기기가 아니라 정책에서 바꾸십시오.

개인 기기에서는 사용자가 선택합니다. 정직한 질문은 터널을 쓸 수 없을 때 오프라인을 받아들이느냐입니다. 차단은 가용성의 맞바꿈이므로 그렇게 설명해야 합니다. 스위치가 없다고 root나 관리 해제가 정당화되지는 않습니다.

범위는 기기가 아니라 프로필 단위입니다. 개인과 업무 프로필은 별개의 맥락이며 Android는 사용자 프로필마다 하나의 VPN만 활성화합니다.

업무 프로필의 차단은 개인 쪽에 대해 아무것도 말하지 않으며 한 맥락의 시험이 다른 쪽을 검증하지 않습니다.

두 번째 결정: 전부 차단인가, 일부 앱 제외인가

차단 모드의 앱별 제외는 거꾸로 이해되곤 합니다. Android 문서에 따르면 앱별 VPN에서 제외된 앱은 차단 모드에서 연결을 잃을 수 있고 일반 네트워크를 조용히 쓰지는 않습니다. 따라서 제외는 인터넷 허가증이 아닙니다.

의식적으로 고르십시오. 덮인 트래픽을 모두 차단하고 제외된 앱이 어두워지는 것을 받아들이거나, 차단을 끄고 우회로를 받아들이십시오. 한 앱이 항상 연결되어야 한다면 그 기기에 차단은 잘못된 도구입니다.

세 번째 결정: 잠금 해제 전과 포털에서는 무슨 일이 일어나는가

대부분 클라이언트는 사용자가 기기를 잠금 해제하기 전까지 터널이 올라오지 않으므로 부팅 직후 몇 초는 공백이지 고장이 아닙니다. 배포하는 클라이언트에서 확인하십시오.

캡티브 포털은 다른 쪽 끝입니다. 호텔이나 공항 네트워크는 인증 전 브라우저 세션이 필요하고 강한 차단은 로그인을 불가능하게 만들 수 있습니다. 지지되는 답은 승인된 복구 절차이며 트리거, 최대 기간, 누가 허용하는지, 사후에 강제가 스스로 돌아오는지 확인을 정합니다.

Android VPN 클라이언트 문서는 Always-On과 차단, 앱별 제외, 프로필당 하나의 VPN 규칙을 다룹니다. 기억에 의존해 설계하기 전에 읽으십시오.

오프라인 상태를 시험한 뒤 수용 조건을 쓰십시오

무해한 트래픽과 클라이언트가 지원하는 장애 시험을 쓰십시오. 정상 연결, 터널 손실, 복구, 잠금 해제 전 재부팅을 확인하고 덮인 앱이 연결되었는지, 의도대로 차단되었는지, 다른 경로를 택했는지 기록하십시오.

상태 아이콘이 아니라 자원과 리졸버를 검증하십시오. VPN 인터페이스가 있어도 쓸모 있는 경로가 작동하지 않을 수 있습니다. 테더링한 기기도 따로 시험하십시오. 휴대전화 정책은 핫스팟 클라이언트에 전달을 설정하지 않습니다.

수용 조건은 구체적이고 시험 가능합니다. 의도한 프로필의 의도한 앱이 승인된 터널에 도달하고, 도달할 수 없을 때는 요구된 차단 상태에 머뭅니다. 서명하기 전에:

• Always-On과 차단은 플랫폼이 지원하는 곳에서 설정되어 있고 각 설정의 소유자가 알려져 있다.
• 앱 범위는 의도적이며 차단 모드에서 제외된 앱이 어떻게 되는지 확인했다.
• 잠금 해제 전 공백과 캡티브 포털 절차는 발견이 아니라 결정된 상태다.
• 장애 시험은 실제로 배포하는 기기 등급에서 수행했다.