mitmproxy, DevTools, Gradle: VPN 뒤의 세 계층

VPN이 연결되고,서로 무관한 세 도구가 세 가지 방식으로 실패합니다같은 오후에. mitmproxy는 요청을 보지 못하고, Chrome은 디버거를 거부하며, Gradle은BindException로컬 소켓을 바인딩하는 중에 예외를 던집니다. 공통된 의심은 터널이 localhost를 막는다는 것입니다. 그럴 수 없습니다:127.0.0.1커널 안에서 처리되며 어댑터에조차 닿지 않고, 게이트웨이는 말할 것도 없습니다.

세 계층, 세 가지 다른 고장

클라이언트와 함께 바뀐 것은 loopback으로 가는 경로가 아닙니다. 로컬 프록시, 머신의 신뢰 저장소, 패킷 필터이며, 각각이 개발자 워크플로의 다른 부분을 깨뜨립니다. 증상을 올바른 행에 분류하는 것이 진단의 대부분입니다:

이런 보고는 거의 모두 마지막 행에서 시작해 위로 올라가는데, 그것은 거꾸로입니다. 터널은 loopback 트래픽을 볼 수 없음이 입증된 유일한 계층이므로 가장 의심받지 않아야 합니다. 프로세스가 무엇을 바인딩했는지부터 보고, 다음으로 어떤 인증서를 신뢰하는지 물은 뒤에야 머신의 정책을 보십시오.

터널이 아니라 리스너부터 시작하십시오

프록시가127.0.0.1:8080에서 트래픽을 받지 않게 되면 세 가지 중 하나가 일어난 것입니다: 시작되지 않았거나, 다른 포트에 바인딩했거나, 필터가 loopback 연결을 떨어뜨렸습니다. 수신 대기 중인 소켓을 나열하면 한 명령으로 답이 나오고, 두 도구가 누가 먼저였는지 다툴 때 어느 프로세스가 포트를 소유하는지도 보여 줍니다.

라우트 조회에서 로컬 주소가 나오는 것은 반대 방향에서 같은 사실을 확인해 줍니다.ip route getloopback 대상에 대해서는 loopback 장치를 보고하며 터널을 보고하는 일은 없고, 누군가 라우팅 변경을 해결책으로 제안할 때 준비해 두면 유용한 문장입니다.

프록시 계층: 환경은 구성이 아닙니다

많은 기업 클라이언트가 HTTP 프록시를 실행하고 애플리케이션이 그것을 쓰기를 기대합니다.HTTPS_PROXY를 셸에서 설정하면 그것을 존중하는 명령줄 도구는 고쳐지지만, 자체 설정 파일을 읽는 도구에는 아무 효과가 없습니다. Gradle, Selenium, gRPC는 각자 자기 구성을 참조하고, 한 터미널에서 내보낸 프록시는 IDE가 띄운 데몬에게 보이지 않습니다.

컨테이너 도구는 이것이 드러나는 흔한 장소입니다. 컨테이너의 loopback은 그 자신의 것이므로,127.0.0.1컨테이너 안에서는 호스트의 프록시를 뜻하지 않으며, 호스트 주소나 호스트 네트워크 설정이 필요합니다. 셸에서는 되는데 빌드에서 실패하는 수정은 보통 이 행이며, 터널이 아닙니다.

신뢰 계층: 도구는 다른 저장소를 읽습니다

가로채기는 두 번째 변경이며 가장 오해를 부르는 오류를 만듭니다. 클라이언트는 검사되는 연결에 자체 인증서를 제시하므로, 기업 루트를 신뢰하는 브라우저는 성공하지만 번들 CA 저장소를 쓰는 도구는 실패합니다. certifi를 통한 Python requests가 전형적인 사례인데, 운영체제 저장소가 올바라도 그 런타임이 그것을 읽지 않으므로 요청은 실패합니다. 오류 문구는 가로채기를 거의 언급하지 않아서, 이 행은 깨진 엔드포인트로 잘못 진단됩니다.

엔드포인트가 실제로 제시하는 것과 도구가 검증한 것을 비교하십시오.openssl s_client는 서버가 보낸 체인을 보여 주고, 도구 자체의 검증 출력은 무엇을 결정했는지 보여 줍니다. 둘이 어긋날 때,REQUESTS_CA_BUNDLE또는SSL_CERT_FILE가 그 런타임의 지렛대이며, 기업 루트는 그 런타임이 읽는 저장소에 있어야 하고, 일부 도구만 존중하는 전역 위치에 있어서는 안 됩니다.

SSL 오류를 고치는 버전 변경은 VPN이 아니라 신뢰와 암호 정책에 관한 증거입니다. SOAP 클라이언트를 동작시킨 Python 다운그레이드는 번들 CA 저장소와 기본 TLS 설정을 바꾼 것이고, 네트워크 경로는 움직이지 않았습니다.

필터 계층: loopback도 떨어뜨릴 수 있습니다

세 번째 변경은 패킷 필터이고, 일부 제품은 터널로 들어가지 않는 트래픽을 떨어뜨리는 규칙을 설치합니다. 로컬 리스너도 포함될 수 있습니다. 그러면 동작하던 소켓이 거부되거나 시간 초과된 연결이 되고, 그 결과 오류는 머신의 정책이 아니라 애플리케이션의 버그처럼 보입니다.

포트 소유권은 이 계층의 나머지 절반입니다.BindException는 소켓을 열 수 없었다는 뜻이며, 연결이 거부되는 것과는 다른 실패입니다. 필터를 탓하기 전에 다른 프로세스가 이미 포트를 잡고 있는지 확인하고, 그다음 로컬 트래픽을 떨어뜨리는 규칙을 찾아 제품이 지원하는 가장 좁은 허용을 추가하십시오. 같은 디버그 포트를 두고 다투는 두 도구는 정책 차단과 똑같은 메시지를 내며, 방화벽 변경으로 고쳐지는 것은 둘 중 하나뿐입니다.

Chrome의 디버그 포트도 같은 계열에서 실패합니다. 브라우저는 시작되지만 드라이버가 DevTools 엔드포인트에 닿지 못하고, 메시지는 네트워크가 아니라 DevTools를 지목합니다. 추가 실행 플래그와 불필요한 드라이버 관리자가 포트 소유 프로세스를 바꾸므로, 그것들을 제거하면 때때로 VPN이 고쳐진 것처럼 보입니다.

실패한 계층을 고치십시오

터널이 아니라 실패한 계층을 고치십시오. 닿을 수 없는 loopback 리스너는 리스너나 포트를 바로잡아야 합니다. 신뢰할 수 없는 인증서는 바로 그 런타임이 보는 곳에 기업 루트를 설치하고 예외는 좁게 유지해야 합니다. 로컬 트래픽을 떨어뜨리는 필터는 비활성화가 아니라 구체적인 허용 규칙이 필요한데, 비활성화하면 그것이 보호하던 다른 모든 것까지 다시 열리기 때문입니다.

VPN을 다시 연결하는 것은 이 계층들 중 어느 것도 검증하지 않습니다. 그것들을 깨뜨린 변경을 다시 실행할 뿐이므로, 같은 세 가지 고장이 재연결마다 돌아오고 클라이언트를 비활성으로 두는 재부팅마다 사라집니다.