Mac VPN과 PAC 프록시: 하나의 설정이 아닌 두 가지 판단

Mac은 정책 스크립트를 내려받은 다음 그 스크립트에 요청이 어떤 중개자를 사용해야 하는지 묻는 반면, 터널은 선택된 홉에 어떻게 도달하는지만 결정합니다. 두 답은 같은 소켓에 도착하므로, 둘 다 성공한 뒤 실패하는 요청은 실제로는 두 개의 고장인데도 하나처럼 보입니다. 다운로드와 선택, 선택과 경로를 분리하는 것이 이 티켓 작업의 대부분입니다. 아래 순서는 macOS가 실제로 하는 일을 따르며, 각 단계를 보이게 만드는 점검을 함께 둡니다.

PAC 주소와 프록시가 갈라지는 곳

https://config.corp.example/proxy.pac 같은 주소는 내려받을 문서를 가리키고, 그 문서는 트래픽을 보낼 서버를 가리킵니다. URL을 프록시 호스트 필드에 붙여 넣으면 클라이언트는 그런 연결을 결코 듣지 않는 파일 서버로 프록시 연결을 열라는 요청을 받습니다. 파일 안에는 클라이언트가 요청마다 호출하는 함수가 있고, 그 반환값이 그 단일 목적지에 대한 다음 홉입니다. 이 간접성은 같은 네트워크 서비스에 있는 두 대의 기계가 둘 다 올바른 URL을 가졌는데도 왜 다르게 동작할 수 있는지 설명합니다. 또한 아무도 프록시 자체를 건드리지 않고 정책 변경이 효력을 갖는 이유도 설명합니다.

하류의 무엇이든 해석하기 전에 스크립트를 읽으세요, 안의 규칙이 조직의 예외와 그 적용 순서를 담고 있기 때문입니다. 이른 시점의 넓은 범위는 나중의 내부 접미사를 가릴 수 있고, 분명히 프록시를 우회해야 하는 호스트가 계속 그것을 사용합니다. 누군가 정책이 틀렸다고 주장할 때, 그 주장이 정리되는 유일한 곳이 스크립트입니다.

스크립트는 무엇을 결정하기 전에 먼저 가져와야 한다

정책을 내려받으려면 해석된 이름과 파일을 제공하는 대상으로 가는 경로가 필요하며, 연결된 터널은 둘 중 어느 것도 보장하지 않습니다. 호스트가 사설 DNS로만 해석된다면 그 순간 사용 중인 리졸버가 다운로드를 시작할 수 있는지 결정합니다. 호스트가 사설 범위에 있다면 경로는 동료의 노트북이 아니라 이 기계에서 존재해야 합니다. 이전 세션에서 캐시된 사본은 캐시가 만료되거나 기계가 재시작될 때까지 이 모든 것을 숨깁니다.

아래 세 점검을 순서대로 실행하고 첫 실패에서 멈추세요. 단계들은 원인을 공유하지 않으며, 셋을 합치면 정책이 구성되었는지, 도달 가능한지, 무엇을 반환하는지 보여 줍니다.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

첫 명령은 시스템이 들고 있는 자동 구성 URL을 포함해 활성 서비스의 프록시 사전을 출력합니다. 두 번째는 이름 있는 서비스 하나에 붙은 URL을 보고하며, 이는 Wi-Fi와 Ethernet 사이를 오가는 노트북에서 중요합니다. 세 번째는 파일을 렌더링하지 않고 가져오므로 404, 타임아웃, 리졸버 실패가 구분됩니다. 마지막 명령이 스크립트를 반환하는데 애플리케이션이 여전히 실패한다면, 문제는 이미 가져오기 단계를 지났습니다.

DIRECT 응답이 실제로 건너뛰는 것

PAC 명세는 클라이언트에게 작은 어휘를 주며, DIRECT는 그중 한 단어입니다. 그 단어는 그 요청에 대해 프록시를 건너뛰라고 클라이언트에 말하고, 이후 소켓이 어느 인터페이스를 쓰는지에 대해서는 아무것도 말하지 않습니다. 완전한 터널 위의 직접 소켓도 여전히 VPN을 통해 나가고, 여전히 터널의 출구 주소를 목적지에 보여 줍니다.

DIRECT을 VPN 밖으로 읽는 것이 사람들을 잘못된 설정 패널로 보내는 실수입니다. 거울상도 똑같이 흔합니다, 사설 프록시는 분할 경로로 도달할 수 있지만 나머지 기계는 터널 밖에 남기 때문입니다. 그때 목적지가 보고하는 것은 프록시 자체의 출구에 속하며, 그것은 다른 나라에 있을 수 있습니다. 내부 호스트 하나와 공개 호스트 하나에 대한 기대를 적으면, 스크립트가 둘에게 자주 다르게 답하기 때문에 이것이 빨리 드러납니다. 어느 홉이 주소를 만들었는지 알면 보고서는 더 이상 미스터리가 아닙니다.

하나의 오류 페이지로 나타나는 세 가지 실패

정책이 다운로드에 실패할 수 있고, 선택된 프록시에 도달할 수 없을 수 있으며, 서비스에 도착한 요청이 거기서 거부될 수도 있습니다. 셋 모두 타임아웃이나 일반 오류 페이지로 오고, 어느 것도 깨진 단계를 지목하지 않습니다. 오류 옆에 결정을 기록하는 것이 이들을 구분합니다. 아래 두 프로브는 스크립트가 선택한 홉을 시험하며, 반환할 수 있는 각 분기에 하나씩 대응합니다.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

프록시에 대한 연결이 완료되면 질문은 인증이나 프록시 자체의 정책으로 넘어가며, 그쪽은 담당자가 다릅니다. 경로에 프록시가 없는 내부 호스트로의 연결이 완료되면 경로가 배제되고 정책이 지목됩니다. 두 명령 모두 셸이 프록시 변수를 내보내지 않는 한 macOS 프록시 사전을 무시하므로, 먼저 그것을 지우세요. 어느 프로브도 다른 하나를 증명하지 못하기 때문에 하나의 오류 페이지가 그렇게 오래 오해를 부릅니다.

티켓과 함께 무엇을 넘길지

활성 네트워크 서비스, PAC URL, 실패하는 호스트의 평가 결과, 오류가 나타난 단계를 보내세요. 이 네 가지가 있으면 다음 사람이 어느 계층이 관련되었는지 추측하는 대신 결정을 재현할 수 있습니다. 테스트 시점의 터널 상태를 추가하세요, 재연결 전에 잡은 결과는 낡았기 때문입니다. 스크립트 리비전도 남기세요, 정책 파일은 예고 없이 바뀌고 어제의 답이 더 이상 유효하지 않을 수 있습니다.

스크립트를 가져올 수 없을 때 클라이언트가 어떻게 행동하는지, 구현이 다르고 프록시 결정이 기기 전체의 킬 스위치가 아님을 기록하세요. 어떤 구현은 직접 연결로 돌아가고 어떤 구현은 닫힌 채 실패하며, 그 차이가 장애가 고장 난 프록시처럼 보이는지 작동하는 정책처럼 보이는지를 바꿉니다. 사고 중에 의존하기 전에 정확한 클라이언트와 버전에서 동작을 확인하세요.