같은 서브넷의 웹사이트는 게이트웨이의 투명 프록시를 우회할 수 있다

인터넷 브라우징은 게이트웨이 프록시 로그에 나타납니다. 사무실 LAN의 웹사이트는 나타나지 않습니다. URL 필터를 바꾸기 전에 그 LAN 요청이 게이트웨이에 도달하기는 했는지 먼저 확인하십시오.

직접 연결된 IPv4 목적지의 경우, 클라이언트는 목적지의 링크 계층 주소를 확인해 로컬 세그먼트에서 그 주소로 보낼 수 있습니다. 기본 게이트웨이가 자동으로 그 경로에 있는 것은 아닙니다. 게이트웨이의 투명 가로채기 규칙은 게이트웨이가 받지 못하는 패킷을 우회시킬 수 없습니다.

예를 들어 같은 온링크 서브넷의 두 호스트는 스위치를 통해 트래픽을 주고받을 수 있지만, 프록시 장비는 다른 스위치 포트에 연결되어 있습니다. 그 LAN에 있다는 사실만으로 프록시가 포워딩 지점이 되는 것은 아닙니다.

의도한 경로를 선택하십시오

명시적 프록시 설정은 대상 웹사이트가 로컬이더라도 참여 애플리케이션의 요청을 프록시로 보낼 수 있습니다. 바이패스 규칙과 PAC 결정도 확인하십시오. 사설 이름이나 주소에 대해 의도적으로 DIRECT를 선택할 수 있습니다.

가로채기가 필요하다면 네트워크가 가로채기 지점을 실제로 경로에 두어야 합니다. Linux 게이트웨이에서는 로컬 패킷 경로와 포워딩 패킷 경로를 구분하십시오. 라우팅된 서브넷 분리나 의도적으로 인라인으로 배치한 브리지는 적절한 설계에서 이를 수행할 수 있지만, 각각 포워딩과 장애 동작을 바꿉니다. LAN의 다른 곳에 있는 브리지는 자동으로 인라인이 아닙니다.

애플리케이션 프로토콜 요구 사항은 따로 두십시오. 트래픽이 장비를 지난 뒤에도 리스너가 가로채기 모드를 지원해야 합니다. 패킷을 옮기는 것은 HTTPS를 복호화할 권한도 아니고, 일반 SOCKS 포트가 그 패킷을 받아들일 수 있다는 보장도 아닙니다.

클라이언트가 선택한 경로, 로컬 세그먼트, 실제 포워딩 장치를 기록하십시오. 프록시 로그가 없는 것은 로깅 실패가 아니라 토폴로지를 정확히 설명한 것일 수 있습니다.