Apple VPN 프로파일의 Proxy 필드가 실제로 하는 일

Apple VPN 구성에서 Proxy 필드를 채우면 터널이 웹 포트를 거쳐 우회할 것처럼 느껴집니다. 그렇지 않습니다. 이 필드는 호환되는 앱이 그곳으로 보내기로 한 트래픽을 위한 애플리케이션 계층 중개자를 고릅니다. 반면 VPN 클라이언트 자체가 게이트웨이와 맺는 연결은 설정한 프로토콜, 리스너, 전송이 결정하며, 이는 별개의 결정입니다.

두 개의 연결, 두 명의 소유자

이런 구성에는 클라이언트에서 게이트웨이로 가는 연결과 앱에서 목적지로 가는 연결이 있습니다. Proxy 섹션은 두 번째 연결을 말하지만, 첫 번째와 같은 프로파일에 들어 있습니다.

Apple의 프록시 설정 참조에는 HTTP, HTTPS, SOCKS, 자동 프록시 구성이 나오는데, 이는 앱의 프록시 선택을 설명한 것입니다. IPsec이나 WireGuard 패킷이 게이트웨이에 어떻게 도달하는지는 그 어느 항목에도 없습니다.

결론을 내는 간단한 점검이 있습니다. VPN 클라이언트가 로그에 보고하는 포트와 프로토콜을 확인하십시오. 그 줄이 여전히 UDP 500 또는 UDP 51820이라고 하면, 프록시 필드는 그 줄을 바꾸지 않았습니다.

필드가 올바른 도구일 때

프록시가 터널 앞에 놓이는 실제 사례가 있지만, 그것은 프로파일 필드가 아니라 클라이언트 기능입니다. OpenVPN 설명서는 HTTP CONNECT 프록시를 통해 전달되는 TCP 연결을 위해 --http-proxy 옵션을 기록합니다. 이를 쓰려면 맞는 클라이언트 옵션, 그 경로로 도달할 수 있는 게이트웨이, 사용 중인 포트로의 CONNECT를 허용하는 프록시가 필요합니다.

클라이언트가 그 옵션을 제공하고 네트워크가 포트로의 CONNECT를 허용한다면 작동할 수 있습니다. 클라이언트가 제공하지 않는다면 시스템 프록시를 채워도 터널에는 아무 영향이 없습니다.

아무것도 바꾸지 않을 때

Proxy 필드가 채워졌다고 해서 IKEv2나 IPsec 프로파일이 HTTP 터널이 되지는 않습니다. 구성 형식에 프록시 개념이 없는 WireGuard도 마찬가지입니다. 게이트웨이 포트를 바꿔도 프로토콜은 바뀌지 않습니다. 그리고 일반 HTTPS에 응답하는 엔드포인트가 자동으로 VPN 리스너가 되는 것도 아닙니다.

같은 함정은 오래된 iPad 안내서에서 PPTP 시대 프로파일을 복사하는 사람에게도 걸립니다. 옵션은 인터페이스에 남아 있지만, 그 뒤의 서비스는 더 이상 그 프로토콜을 쓰지 않습니다.

어느 계층을 고칠지 정하기

무엇이든 바꾸기 전에 어느 계층이 실패했는지 물어보십시오. 클라이언트가 세션을 맺지 못하면 전송이 문제이고 프록시 필드는 무관합니다. 터널은 올라갔는데 한 앱이 자기 서버에 닿지 못하면 앱 프록시를 살펴볼 만합니다. 터널은 올라갔는데 모든 앱이 실패하면 터널 내부의 라우팅과 DNS가 용의자입니다.

첫 경우에는 운영자에게 어떤 승인된 대체 전송이나 네트워크를 지원하는지 물어보십시오. TCP 443을 통한 OpenVPN이 있는 이유는 일부 네트워크가 그것만 허용하기 때문이며, 서버가 그것을 수신하고 있어야 한다는 조건은 그대로입니다.

차단된 UDP 포트를 즉석 우회의 허가로 여기지 마십시오. 핸드셰이크를 맞추려고 게이트웨이의 인증서나 신원 검사를 끄는 대신 그대로 유지하십시오.

두 계층을 하나씩 확인하기

먼저 터널을 확인하십시오. 클라이언트 상태 페이지에서 세션이 성립했고 바이트 수가 영이 아닌지 보십시오. 그다음 프록시 설정을 직접 읽으십시오. 유효한 구성은 scutil --proxy, 저장된 값은 networksetup -getwebproxy Wi-Fi를 씁니다. 그다음 시스템 프록시를 따르는 앱과 무시하는 앱을 하나씩 시험하십시오. 많은 네이티브 앱이 무시합니다.

세 가지 결과, 세 가지 다른 수정.

두 계층이 모두 성공을 보고하는데도 앱이 실패한다면 분할 터널링, DNS, 앱 자체의 네트워크 설정을 보십시오. 그것은 세 번째 계층이며, 역시 프록시 필드가 아닙니다.