프록시 사용을 강제해야 하는 Linux 패킷 경로는 어디인가
네트워크 프록시 강제 제어를 그것이 관리해야 할 패킷 경로에 두어야 하며, 게이트웨이로 향하는 연결만 필터링해서는 안 된다.
Linux 게이트웨이는 프록시 프로세스를 실행하면서 그 옆으로 트래픽을 라우팅할 수도 있다. 이 둘은 같은 패킷 경로가 아니다.
| 연결 | 관련 로컬 역할 |
|---|---|
| 클라이언트가 게이트웨이의 프록시에 도달 | 로컬 호스트로 향하는 트래픽 |
| 클라이언트가 게이트웨이를 통해 다른 호스트에 도달 | 전달되는 트래픽 |
| 프록시가 웹사이트 연결을 연다 | 로컬 프로세스가 생성한 트래픽 |
Netfilter는 입력, 전달, 출력 경로를 구분한다. 게이트웨이 자체의 프록시 리스너에 대한 접근을 규율하는 규칙이 그 머신을 거치는 모든 라우팅 연결을 자동으로 제한하지는 않는다.
무엇을 강제할지 정의한다
클라이언트가 승인된 프록시를 사용해야 한다면, 정책은 의도한 리스너를 허용하는 것과 함께 대체 아웃바운드 경로도 다루어야 한다. 익숙한 프록시 포트를 쓴다는 이유만으로 임의의 원격 서비스 연결을 허용하는 것은 자신의 프록시 엔드포인트만 허용하는 것과 같지 않다.
프록시 자체의 이후 접근은 따로 둔다. Squid의 경우 아웃바운드 허용을 적용하기 전에 로컬 소켓 소유권과 LAN 사용자 신원을 구분한다. 프록시의 모든 유용한 아웃바운드 연결을 거부하면 필요한 경로를 사용할 수 없게 된다. 관리 트래픽, 이름 해석, 지원되는 비웹 작업도 배포 정책에서 의도적으로 다루어야 한다.
프로토콜 범위가 중요하다. TCP 규칙은 QUIC을 포함한 UDP 트래픽을 그 자체로 설명하지 않는다. 트래픽 가로채기는 또 다른 설계이며, 명시적 HTTPS 프록시는 웹사이트 세션을 복호화하지 않고 CONNECT를 제공할 수 있다.
규칙 집합을 편집하기 전에 의도한 연결을 지도화한다. 브라우저 설정은 참여 클라이언트의 경로를 고른다. 네트워크 강제는 어떤 다른 경로가 성공할 수 있는지를 결정한다. 어느 것도 프록시 로그인 성공만으로 추론해서는 안 된다.