지사 브라우저에서 프록시로: 두 연결, 두 경로

명시적 프록시 뒤의 지사 브라우저는 두 개의 연결을 열고, 각각 다른 이유로 실패합니다. 첫 번째는 브라우저에서 프록시 리스너까지이며, 지사 VPN을 통해 전달됩니다. 두 번째는 프록시에서 웹사이트까지이며, 프록시 자체의 리졸버, 경로, 출구 정책을 사용합니다. 이를 하나의 흐름으로 취급하는 지원 티켓은 사람들을 몇 시간씩 잘못된 장치로 보냅니다. 각각을 의도적으로 설정하고 그 순서대로 테스트하십시오.

1단계: 두 흐름을 적습니다

브라우저의 즉각적인 목적지는 프록시 리스너이며, 사용자가 결국 방문하는 모든 사이트가 아닙니다. 그 한 문장이 이 설계의 혼란 대부분을 해결합니다.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

서로 다른 소스, 서로 다른 경로, 서로 다른 권한. 스케치를 변경 기록에 보관하십시오. 이후의 모든 확인은 그 두 절반 중 하나를 참조하기 때문입니다.

2단계: 브라우저에 리스너로 가는 경로를 줍니다

프록시 호스트 이름, 리스너 포트, 인증 요구 사항, 허용된 지사 소스를 기록합니다. 그 목록이 첫 번째 흐름의 승인 기준이며, 터널 경로뿐 아니라 내부 이름 해석도 포함해야 합니다.

인터넷에 무제한 프록시를 게시하는 대신 의도된 서비스에 좁은 네트워크 규칙을 적용합니다. 의도된 클라이언트가 지원되는 경로를 갖고 있다면 프록시는 내부 네트워크에 남을 수 있습니다.

3단계: 경로 테이블만이 아니라 브라우저를 구성합니다

브라우저의 프록시 설정, PAC 파일 또는 조직의 관리형 검색 메커니즘을 사용합니다. 일반 웹사이트 패킷을 경로로 프록시 주소로 보내는 것만으로는 브라우저가 프록시 프로토콜을 말하게 되지 않습니다. 그것은 투명한 가로채기이며 다른 게이트웨이 설계에 속합니다.

어떤 애플리케이션이 설정을 존중하는지 적어 둡니다. 메일 클라이언트, 업데이터, 게임은 종종 그렇지 않으며 단순한 경로를 계속 사용합니다.

4단계: 프록시의 앞선 연결을 증명합니다

프록시에는 자체 리졸버와 웹사이트로의 허용된 경로, 그리고 인터넷 경계가 요구하는 방화벽 또는 변환 정책이 필요합니다. 리스너에 도달한 브라우저는 그것을 전혀 증명하지 않습니다. 두 번째 흐름은 프록시 자체에서, 사용자가 보고한 같은 목적지와 포트로 테스트하십시오.

HTTPS의 경우 CONNECT가 요청된 목적지로 터널을 엽니다. 일반 전달은 복호화된 페이지를 프록시에 넘기지 않으며, 검사를 즉흥적으로 하기 위해 인증서 검증을 끄는 것은 해결책이 아닙니다.

5단계: 네 가지 실패를 구별합니다

프록시 인증 요청은 리스너에서 오는 407입니다. 거부된 CONNECT는 프록시의 정책 결정이며 보통 자체 상태와 로그 줄이 있습니다. 실패한 앞선 연결은 프록시가 목적지에 대해 기록하는 시간 초과 또는 재설정처럼 보입니다. 웹사이트 응답은 두 연결이 모두 작동했고 문제가 원본에 있음을 의미합니다.

VPN이 실패했다는 요약이 아니라 관찰한 경계를 보고하십시오.

6단계: 범위를 정하고 대체를 계획합니다

프록시나 터널을 사용할 수 없을 때 무슨 일이 일어나는지 결정하고, 이 설계가 어떤 트래픽을 다루는지 분명히 말합니다. 프록시 설정을 존중하는 클라이언트의 웹 액세스를 전달합니다. 메일, 임의의 장치 프로토콜 또는 구성을 무시하는 소프트웨어는 전달하지 않습니다.

설계를 더 많은 클라이언트로 확장하기 전에 승인된 계획에 따라 필요한 브라우저 작업과 한 가지 필요한 거부를 검증하십시오.