회사 VPN이 연결되면 디버그 프록시가 눈을 감는다

프록시 설정은 그대로입니다. 터널 항목이 자체 설정을 들고 오고, 관리형 PAC가 되살아나며, 일부 클라이언트는 시스템 프록시를 아예 읽지 않습니다.

캡처 도구가 아침 내내 잘 돌다가 터널이 연결되면 조용해진다. 끊으면 다시 시작된다. VPN이 프록시를 망가뜨렸다고 생각하기 쉽지만, 프록시 구성은 실제로 아무것도 바뀌지 않았다. 바뀐 것은 애플리케이션이 이제 어느 구성을 읽느냐다. 터널 항목이 자체 프록시 설정을 가질 수 있고, 관리형 프로필이 자동 구성을 다시 켤 수 있으며, 일부 런타임은 운영체제가 제공하는 것의 일부만 읽는다. 전역 값을 건드리기 전에 연결별 값을 읽어라.

Windows는 연결마다 프록시를 따로 둔다

인터넷 옵션에는 대화상자에서 똑같아 보이는 두 계층이 있다. LAN 설정은 일반 로컬 연결에 적용되고, 전화 접속이나 VPN 항목은 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections 아래에 자체 복사본을 이진 값으로 보관한다. 익숙한 전역 레지스트리 값을 써도 그 복사본은 갱신되지 않는다.

도구가 연결 전에는 맞게, 연결 후에는 틀리게 동작하는 이유가 바로 이것이며, 설정 어디에도 보이는 변화는 없다. 들여다보던 대화상자는 LAN 패널이었다. 그것은 옳았고, 그리고 무관했다. Windows가 실제로 사용한 항목은 터널을 위해 만들어진 항목이었다.

항목 하나를 바꾸는 지원 방식은 WinINET 연결 옵션 API다. INTERNET_PER_CONN_OPTION_LIST 를 연결 이름, 플래그, 프록시 서버, 우회 목록으로 채우고 적용한 뒤 새로 고친다. 빠르게 확인하려면 터널 항목 자체의 설정 대화상자를 열어 그 프록시 패널을 LAN 패널과 비교해 보라. 어디를 봐야 하는지 알면 차이는 대개 분명하다.

관리형 PAC는 스스로 다시 켜질 수 있다

macOS에서 자동 프록시 구성 스크립트와 프록시 자동 검색은 네트워크 서비스의 속성이지 머신의 속성이 아니다. 구성 프로필이 이를 강제할 수 있어서 체크를 해제해도 다시 나타나고, 그러면 모든 요청이 스크립트가 고른 프록시로 간다.

점검하고, 권한이 있다면 트래픽을 실어 나르는 서비스에 대해 그 두 스위치를 꺼라.

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

추측이 아니라 실제 서비스 이름을 써라. Wi-Fi와 USB 이더넷 어댑터가 모두 있는 노트북에는 그런 서비스가 둘 있고, 트래픽을 실어 나르는 것은 하나뿐이다. scutil --proxy 는 현재 기본 서비스의 값을 출력한다. 프로필이 이겼다고 결론 내리기 전에 그 출력을 네가 편집한 내용과 비교하라.

도구를 진짜 상류로 향하게 하라

스크립트에 회사 프록시가 들어 있다면 그것을 읽고, 같은 주소를 캡처 도구 안의 외부 프록시로 입력하라. 그러면 도구는 진짜 상류로 전달하며, 회사 프록시가 기대하는 것이 바로 이것이고, 정책과 싸우는 대신 요청 경로에 머문다.

다시 설정하는 대신 디버깅을 계속하게 해 주는 수가 이것이다.

프록시를 터널 안으로 밀어 넣어라

OpenVPN 기반 클라이언트는 터널이 올라온 뒤 적용되는 프록시 옵션을 받아들일 수 있고, 경로를 클라이언트가 쥐고 있을 때 편리하다.

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

그 옵션을 존중하는 클라이언트만 사용하며, 이 옵션은 듣기 포트를 프로필에 단단히 박아 넣는다. 다음 프로필 배포에서 사라지므로 배포 표준이 아니라 실험실 편의로 다뤄라.

시스템 프록시를 아예 읽지 않는 클라이언트도 있다

Firefox는 자체 프록시 설정을 두기 때문에, 시스템 프록시를 쓰는 브라우저가 멈춰도 가끔 캡처를 계속한다. 자동 구성을 이해하지 못하는 오래된 .NET 클라이언트는 어디서 실행되든 직접 연결하므로, 터널 항목으로 불러온 페이지도 애플리케이션 안에서는 여전히 실패할 수 있다.

네트워크 도구에도 나름의 원인이 있다. 터널이나 휴대폰 테더링을 거치며 멈추는 FTP 세션은 클라이언트가 협상하는 능동 대 수동 모드 문제인 경우가 많고, 어떤 프록시 설정으로도 바뀌지 않는다.

설정을 읽어라, 토글이 아니라

이 순서로 진행하라. 터널 항목 자체의 프록시 값, 서비스별 PAC와 자동 검색 상태, 그다음 애플리케이션 자체의 프록시 처리. 가정과 다른 첫 지점에서 멈춰라.

여기의 모든 사례는 구성 우선순위 문제다. 어느 것도 터널이 네 도구를 망가뜨리는 경우가 아니다.

관련 글