TPROXY 패킷이 소켓에 도달하기까지 추적하기
수신 소켓, 패킷 마크, 로컬 정책 라우트를 투명 프록시의 하나의 전달 경로로 점검합니다.
애플리케이션이 아무것도 받지 못하는데 TPROXY 카운터만 증가할 수 있습니다. 규칙은 일치했지만 로컬 전달은 여전히 정책 라우팅과 호환되는 수신 소켓에 달려 있습니다.
Linux TPROXY는 DNAT처럼 목적지를 다시 쓰지 않고도 트래픽을 가로챌 수 있습니다. 따라서 비로컬 목적지로 향한 패킷은 적합한 로컬 소켓에 도달해야 합니다.
전달 경로를 따라가기
- 트래픽은 의도한 인터페이스와 주소 패밀리로 가로채기 호스트에 도달합니다.
- 가로채기 규칙과 패킷 마크가 로컬 전달 정책을 지정합니다.
- 일치하는 정책 규칙이 패킷을 로컬로 전달하는 라우트를 선택합니다.
- 프록시는 필요한 소켓 옵션을 갖춘 지원되는 투명 리스너를 사용합니다.
커널의 IPv4 예제는 IP_TRANSPARENT에 대한 애플리케이션 지원을 요구합니다. 같은 포트의 일반 리스너나 전역 비로컬 바인드 설정은 그 지원을 입증하지 않습니다.
| 관찰 | 다음 확인 |
|---|---|
| 관련된 인그레스 패킷이 없음 | 트래픽 경로와 입력 인터페이스 |
| 패킷은 도착하나 가로채기 카운터가 멈춰 있음 | 주소 패밀리, 체인, 일치 조건 |
| 규칙은 일치하나 로컬 전달이 실패함 | 마크와 정책 라우트 선택 |
| 소켓은 대기하나 애플리케이션이 아무것도 보지 못함 | 투명 소켓 기능과 리스너 소유자 |
| 요청은 시작되나 이후 응답이 실패함 | 설정된 소켓 일치와 반환 라우트 |
관찰할 때마다 로드된 구성과 네트워크 네임스페이스를 함께 기록하십시오. 나중 규칙이 마크를 덮어쓰거나 다른 라우트를 선택할 수 있습니다. 리스너가 컨테이너에서 실행되는데 호스트에서 가로채기가 일어나면, 유효한 호스트 로컬 라우트가 그 컨테이너로 자동 전달되지는 않습니다.
이후 패킷을 고려하기
커널 예제에는 소켓 일치와 투명 소켓에 속한 패킷을 표시하는 DIVERT 경로가 포함됩니다. 이를 빼면 첫 가로채기가 성공해도 이후 트래픽이 다른 경로에 남을 수 있습니다.
애플리케이션이 지원하는 투명 모드와 주소 패밀리별 해당 커널 문서를 사용하십시오. IPv4 로컬 라우트 명령은 IPv6를 설정하지 않으며, 한 패밀리의 지원이 다른 패밀리의 소켓 동작을 입증하지 않습니다.
TPROXY는 SOCKS 협상도 만들지 않습니다. 투명에서 SOCKS로 넘기는 구성 요소는 여전히 목적지를 찾아 상위 서버와 협상해야 합니다.
REDIRECT에서 옮겨가기
기존 애플리케이션이 원래 목적지를 어떻게 얻는지 기록하십시오. REDIRECT는 목적지를 바꾸고 적절한 복구 방식에 의존합니다. TPROXY는 자체 투명 소켓과 라우팅 구성이 필요합니다. 애플리케이션과 출발지 주소 정책에 따라 선택하십시오.
가로채기 방식을 바꾸기 전에 카운터를 선택한 라우트, 소켓 기능, 애플리케이션 로그와 함께 맞춰 보십시오. 필요한 기능을 제공하는 배포판에서는 커널을 다시 빌드하는 것보다 빠진 전달 단계를 찾는 편이 더 나은 출발점입니다.