
src IP를 유지하면서 라우터의 서브넷에 SNI 프록시를 수행하려고 합니다.
배경: 많은 애플리케이션 포트에 대해 포트 전달을 수행하기 위해 DNAT를 수행하는 라우터가 있으며, 이는 다른 백엔드가 있는 서브넷(실제로 VPN을 사용하여)에 연결되어 있습니다. 요청에 따라 다른 IP로 라우팅될 수 있는 HTTP 호스트 또는 TLS SNI와 같은 프로토콜이 없는 프로토콜의 경우 TCP 포트 필터와 함께 DNAT를 사용하면 잘 작동합니다.
TLS의 경우SNIProxyTLS SNI를 기반으로 다른 서버로 들어오는 연결을 다중화합니다. 꽤 잘 작동하지만 SINProxy는 라우터 자체에서 TLS 패킷을 보내고 src 주소를 삭제합니다. 이로 인해 src IP에 의존하는 일부 백엔드 서비스가 중단됩니다.
따라서 netfilter가 TLS SNI(선택적으로 외부 모듈 사용)를 사용하여 트래픽을 필터링하고 (단순히 삭제하는 대신) DNAT를 사용하여 라우팅할 수 있는지 궁금합니다. 그것이 가능하지 않다면 대안이 있습니까?
그런데 다음과 같은 이유로 라우터에 전체 HTTP(또는 L5 서버)를 배포하고 싶지 않습니다.
- 트래픽의 암호를 해독하고 이를 백엔드로 프록시 처리해야 합니다. 이는 엄청난 오버헤드입니다.
- 관리의 복잡성으로 인해 라우터에 TLS 인증서를 배포하고 싶지 않습니다.
미리 도움이 되는 답변을 보내주셔서 진심으로 감사드립니다.
답변1
이론적으로 -j NFQUEUE
사용자 공간을 사용하여 첫 번째 패킷을 변경하고 NAT를 수행하면 이와 같은 작업을 수행하는 것을 상상할 수 있습니다. 실제로는 새 대상 주소를 추측하기 위해 SNI 확장이 포함된 전체 ClientHello 메시지를 수신해야 하고 첫 번째 TCP 패킷이 비어 있거나 UDP를 사용하므로 DTLS는 어쨌든 몇 라운드가 필요하기 때문에 그렇게 할 수 없습니다. 현재 conntrack에서 관리하는 흐름을 NAT하기에는 너무 늦었습니다.
프록시가 필요합니다. 그러나 프록시를 투명하게 만들거나 이를 지원하는 백엔드 애플리케이션과 함께 PROXY 프로토콜을 사용할 수 있습니다(단, PROXY 프로토콜과 TLS를 함께 사용하는 것을 지원해야 함).
예를 들어 haproxy
게이트웨이에서 실행하면 다음 중 하나를 수행할 수 있습니다.프록시 프로토콜, Linux도 사용할 수 있습니다.티프록시투명(소스 및 대상 모두 투명) 프록시를 위한 대상입니다.
두 가지 선택 사항을 모두 제공하는 github 요점에 대한 링크는 다음과 같습니다.HAProxy를 활용하여 호스트 이름으로 식별되는 웹 서비스로 요청을 투명하게 라우팅합니다.. 다음은 Linux 커널과 함께 사용되는 투명한 프록시 구성에 대한 몇 줄입니다.티프록시문서 (동일한 요점에도 있음):
HAProxy 서버 구성은 다음과 같습니다. 이는 TCP 및 HTTP 모드 모두에서 작동합니다.
server app1-tls 192.0.2.10:3001 source * usesrc client weight 0
답변2
따라서 netfilter가 TLS SNI(선택적으로 외부 모듈 사용)를 사용하여 트래픽을 필터링할 수 있는지 궁금합니다.
이건 불가능 해. NAT는 연결의 첫 번째 패킷, 즉 TCP 핸드셰이크를 시작하는 TCP SYN부터 시작하여 수행되어야 합니다. 그러나 SNI는 TCP 핸드셰이크가 완료된 후에만 전송되는 TLS 핸드셰이크의 ClientHello에만 있습니다. 즉, NAT에 필요한 정보는 필요할 때 아직 사용할 수 없습니다.
그것이 가능하지 않다면 대안이 있습니까?
haproxy는 프록시에서 TLS를 종료하지 않고 TCP 연결을 종료한 다음 ClientHello의 SNI를 기반으로 데이터를 전달할 수 있습니다. 그런 다음 PROXY 프로토콜(기본적으로 전달된 연결 시작 부분의 헤더)을 사용하여 TCP 연결 내에서 클라이언트의 원래 소스 IP를 전달할 수 있습니다. 업스트림 서버가 PROXY 프로토콜 자체를 이해하지 못하는 경우 다음과 같은 소프트웨어를 사용할 수 있습니다.mm프록시haproxy의 연결을 SNAT하여 원래 소스 IP를 표시합니다.