Mac VPN On Demand: SSID 일치는 실제로 무엇을 증명하는가?

사무실 Wi-Fi를 제외한 모든 곳에서 VPN을 연결하는 것은 두 줄짜리 정책처럼 들리지만, 어려운 부분은 네트워크 이름을 알아보는 일이 아니었습니다. 어려운 부분은 일치하는 이름이 무엇을 증명해도 되는지 결정하는 것입니다. 어떤 액세스 포인트든 익숙한 SSID를 광고할 수 있고, 한 주소에 대한 성공적인 ping은 단일 탐사가 응답을 받았다는 것만 증명합니다. 두 관찰 중 어느 것도 Mac이 인증된 내부 네트워크에 있다는 것을 입증하지 않습니다.

이름은 신원이 아니다

SSID는 무선이 내보내는 라벨입니다. 그것은 키도, 인증서도, 하드웨어를 누가 소유하는지에 대한 진술도 아니며, 행사장이나 옆 사무실이 아무런 조정 없이 같은 문자열을 브로드캐스트할 수 있습니다. 라벨을 보호를 끄라는 지시로 취급하면 결정은 가장 가까운 액세스 포인트를 설정한 사람에게 넘어갑니다.

ping 테스트가 실패하는 이유는 더 미묘합니다. 그것은 도달 가능성에 대한 질문에 답할 뿐, 구성원 자격에 답하지 않습니다. 응답하는 대상은 어디서든 도달 가능할 수 있고, 판단하려는 터널을 통해서만 도달 가능할 수도 있으며, 응답처럼 보이는 것을 돌려주는 캡티브 포털일 수도 있습니다. 도달 가능성은 유용한 사실이지만 신뢰 경계로는 형편없습니다.

On Demand가 규칙 집합을 평가하는 방식

Apple의 On Demand 모델은 동작을 선택적 네트워크 조건과 짝지으며, 규칙은 순서대로 평가됩니다. 모든 조건이 일치하는 첫 번째 규칙이 동작을 제공하고 나머지는 검토되지 않습니다. 그 순서가 곧 정책이므로, «만일을 대비해» 덧붙인 규칙이 작동하던 동작을 조용히 다시 쓸 수 있습니다.

SSID 조건은 현재 기본 연결 네트워크를 가리키며, 스캔에서 보이는 모든 이름을 가리키지 않습니다. 이로 인해 세 가지 서로 다른 상태가 생기는데, 그것을 둘로 접는 것이 흔한 구성 실수입니다:

정책이 있는 곳에서 구성하세요

승인된 VPN 클라이언트나 관리 워크플로가 이 규칙이 있어야 할 자리이며, 공급자마다 사용 가능한 제어의 부분 집합을 다르게 노출합니다. 따라서 그 패널에 없는 옵션은 클라이언트가 노출하지 않았다는 뜻이지, 플랫폼이 그것을 표현할 수 없다는 뜻이 아닙니다.

자동 활성화에는 사람 없이 완료될 수 있는 인증 방식, 예를 들어 인증서나 다른 지원 방법도 필요합니다. 저장된 일회용 코드는 그런 방식이 아니며, 인증이 완료될 수 없는 동안 발동하는 규칙은 백그라운드에서 조용히 실패하는 연결 시도를 만듭니다.

runbook에 적어 둘 만한 두 가지 패턴

첫 번째는 모방 이름입니다. 회의장, 호텔 또는 같은 건물의 임차인이 당신의 규칙이 «내부»로 취급하는 문자열을 브로드캐스트하고, 보호는 당신이 가장 원하지 않는 바로 그곳에서 꺼집니다. 이름은 거짓말하지 않았습니다. 규칙이 이름에게 대답할 수 없는 질문을 던진 것입니다.

두 번째는 스스로를 무력화하는 탐사입니다. 스크립트가 사설 주소로 ping을 보내고, 터널을 통해 응답을 보고, 이미 내부 네트워크에 있다고 결론 내린 뒤 연결을 끊습니다. 그러면 탐사가 실패하므로 스크립트는 다시 연결해 반복하고, 개별 단계는 옳아 보이는데 터널은 진동합니다. 결과가 터널에 의존하는 테스트는 터널이 존재해야 하는지도 함께 결정할 수 없습니다.

기본값을 정하고, 그다음 따로 강제하세요

알 수 없는 네트워크의 경우와 유선의 경우에는 물려받은 기본값이 아니라 명시적인 답이 필요합니다. 시스템이 아직 네트워크를 분류하거나 터널을 올리는 동안 보호된 트래픽이 차단된 채로 남아야 한다면, 그것은 자체적인 지원되는 강제 제어를 필요로 합니다. On Demand 트리거는 연결 동작을 제공할 뿐 차단 보장을 제공하지 않습니다.

올바르게 쓰인 관리자 규칙은 승인된 예외, 그것을 정당화하는 증거, 그리고 그 증거가 없을 때의 의도적인 대체 동작을 밝힙니다. Wi-Fi 이름을 인식하는 것은 그 결정에 대한 정당한 입력입니다. 그것은 결정의 정당화가 아니며, 규칙의 유일한 줄이 되어서는 안 됩니다.