재시동 후 iPhone VPN: 먼저 무엇이 일어나야 하나
‘VPN을 켜 둔다’를 시작 시점의 요구 사항으로 바꾸세요. 무엇이 연결되고, 무엇이 아직 사람을 필요로 하며, 첫 보호 작업이 실행되기 전에 무엇이 차단되는지 정리합니다.
‘VPN을 켜 둔다’는 말은 서른 초쯤 질문을 견딘다. 재시동 후에도 켜져 있는가? 기기를 잠금 해제하기 전에도 켜져 있는가? Wi-Fi가 아직 로그인 페이지를 보여 주는 동안에도 켜져 있는가? 터널이 올라올 때까지 트래픽을 막을 것인가, 아니면 첫 앱이 직접 시도하도록 둘 것인가? 이것은 서로 다른 네 가지 요구 사항이고, 그중 일부만 기기 설정으로 보장할 수 있다. 답을 단계가 있는 시간선으로 적고, 실제 재시동 뒤에 각 단계를 확인한다.
| Stage | Personal profile | Supervised Always On |
|---|---|---|
| Before first unlock | do not assume a tunnel | do not assume a tunnel either |
| After unlock, network up | depends on the provider or On Demand rule | activates without user interaction |
| Tunnel negotiating | first app may already be trying | policy decides whether traffic waits |
| Gateway unreachable | usually falls back to whatever the client allows | follows the deployed policy |
요구 사항을 시간선으로 적는다
업무에 중요한 순간부터 시작한다: 어떤 보호 작업이 터널 없이 일어나서는 안 되는지, 그 작업이 부팅 뒤 얼마 만에 실제로 시도되는지. 그 순간 이전의 모든 것은 순서이고, 확인하는 대상은 바로 그 순서다. ‘VPN이 켜져 있어야 한다’는 메모는 시험할 수 없지만, ‘터널이 맺어지기 전에 기록 호스트로 가는 트래픽은 없다’는 시험할 수 있다.
그다음 개인 기기가 할 수 있는 일과 관리되는 기기 집단이 할 수 있는 일을 나누되, 두 답은 서로 바꿔 쓸 수 없다.
첫 단계: 첫 잠금 해제 이전의 상태
잠금 해제 뒤에 본 터널로 잠금 해제 이전의 동작을 추론하지 않는다. 정직한 시험은 재시동하고 기기를 잠근 채 두고, 반대편에서 터널이 생기는지 지켜보는 것이다. 대부분의 개인 설정에서 답은 아니오이며 그것은 결함이 아니라, 기기가 잠금 해제되기 전에는 첫 보호 작업을 시도해서는 안 된다는 뜻일 뿐이다.
요구 사항이 정말로 잠금 해제 이전의 커버리지에 달려 있다면, 클라이언트 설정이 아니라 배포 책임자에게 가져간다.
둘째 단계: 네트워크 준비 상태와 로그인 포털
관리되는 Always On은 사용자 조작 없이 활성화되고 프로필이 설치되어 있는 한 재시동을 넘어 유지되며, 터널 설정은 인터페이스가 IP 도달성을 얻은 뒤에 따른다. 중요한 것은 마지막 문장이다: 아직 주소를 받지 못한 기기에는 기반이 될 것이 없다. 아직 수락하지 않은 호텔 포털은 바로 이 의미에서 준비되지 않은 네트워크이고, 기억된 VPN 환경 설정이 그것을 대신 끝내 주지 않는다.
그래서 인수 메모에는 포털 경우를 위한 한 줄이 필요하다. 기기가 기다리거나, 사용자가 먼저 포털을 통과하거나, 어느 쪽이 허용되는지는 누가 이동하는지에 달려 있다. 아침 일곱 시에 재시동하는 사람이 그것을 지어내지는 않을 것이므로 선택을 적어 두어야 한다. 객실 번호를 요구하는 포털은 확인란만 받는 포털과도 다른 경우다.
셋째 단계: 여전히 사람이 필요한 인증
자동 활성화와 자동 인증은 별개의 기능이다. 기기 인증서를 쓰는 프로필은 사람 없이 후자를 마칠 수 있지만, 일회용 요소를 요구하는 게이트웨이는 그럴 수 없고, 어떤 정책도 그것을 바꾸지 못한다. 손을 대지 않는 부팅 순서를 약속하기 전에 둘 중 무엇을 배포하는지 확정한다.
그다음 중간 상태를 분명히 적는다: 인증이 대기 중이라면 트래픽이 차단되는지, 대기열에 들어가는지, 아니면 곧바로 전송되는지. 그 답은 잘못된 설정이 유출이 되는 창을 가리키므로 계획에 속한다. 게이트웨이에 닿을 수 없게 만들고 기기가 무엇을 하는지 지켜보며 시험하되, 클라이언트가 스스로에 대해 적은 설명은 읽지 않는다.
넷째 단계: 첫 보호 작업, 그다음 전환
계획한 재시동 뒤에 보호 작업을 열어 성공 여부와 터널 사용 여부를 확인한다. 그다음 같은 작업을 Wi-Fi에서 셀룰러로 전환하는 동안 반복하는데, 그 이동이 기반 네트워크를 다시 협상하며 부팅 때만 작동하던 프로필이 실패하기 시작하는 지점이 바로 거기다. 실행마다 세 가지 사실을 기록한다: 연결이 자동으로 올라왔는지, 인증을 해야 했는지, 기대한 자원이 응답했는지.
간격 동안 보호가 의무라면 배포 책임자가 승인한 검증 방법을 쓴다. 페이지 한 번의 성공적인 로드는 그 앞에서 아무것도 직접 나가지 않았다는 것을 보여 줄 수 없다.