Estoy intentando realizar un proxy SNI a una subred en un enrutador mientras mantengo la IP src.
Antecedentes: Tengo un enrutador que realiza DNAT para reenviar puertos para muchos puertos de aplicaciones y está conectado a una subred (en realidad, usando una VPN) con diferentes servidores. Para los protocolos que NO tienen algo como HTTP Host o TLS SNI que se puedan enrutar a diferentes IP según la solicitud, simplemente uso DNAT con filtro de puerto TCP y funcionan bien.
Para TLS, estoy usandoSNIProxypara multiplexar las conexiones entrantes a diferentes servidores, basado en TLS SNI. Funciona bastante bien, pero SINProxy envía los paquetes TLS desde el propio enrutador, descartando las direcciones src. Esto interrumpe algunos servicios backend que dependen de la IP src.
Por lo tanto, me pregunto si es posible que netfilter filtre el tráfico usando TLS SNI (opcionalmente con módulos externos) y enrútelo usando DNAT (en lugar de simplemente descartarlo). Si eso no es posible, ¿hay alguna alternativa?
Por cierto, no quiero implementar HTTP completo (ni ningún servidor L5) en mi enrutador porque:
- Tengo que descifrar el tráfico y enviarlo por proxy al backend. Este es un gasto general enorme.
- No quiero implementar certificados TLS en enrutadores debido a la complejidad de la administración.
Muchas gracias por cualquier respuesta útil de antemano.
Respuesta1
En teoría, si se usa -j NFQUEUEpara que el espacio de usuario altere el primer paquete y haga NAT, podría imaginarse haciendo algo como esto. En la práctica, no puede porque necesita haber recibido un mensaje ClientHello completo con la extensión SNI para adivinar la nueva dirección de destino, y dado que el primer paquete TCP estará vacío, o con UDP, DTLS requerirá algunas rondas de todos modos, es entonces demasiado tarde para NAT un flujo ahora administrado por conntrack.
Necesitas un apoderado. Pero el proxy puede hacerse transparente o puede usar el protocolo PROXY con aplicaciones backend que lo admitan (aunque deben admitir el uso conjunto del protocolo PROXY más TLS).
Por ejemplo, haproxyejecutar en la puerta de enlace puede hacer lo siguiente: es el proyecto que propuso elprotocolo proxy, y también puede usar Linuxtproxyobjetivo para proxy transparente (transparente tanto con origen como con destino).
Aquí hay un enlace que encontré a una esencia de github que ofrece ambas opciones:Aproveche HAProxy para enrutar de forma transparente solicitudes a servicios web identificados por el nombre de host. Aquí hay algunas líneas sobre la configuración de proxy transparente, para usar junto con el kernel de Linux.tproxydocumentación (también en la misma esencia):
La configuración del servidor HAProxy sería similar a la siguiente. Funciona tanto para los modos TCP como HTTP.
server app1-tls 192.0.2.10:3001 source * usesrc client weight 0
Respuesta2
Por lo tanto, me pregunto si es posible que netfilter filtre el tráfico utilizando TLS SNI (opcionalmente con módulos externos).
Esto no es posible. NAT debe realizarse comenzando con el primer paquete de la conexión, es decir, el TCP SYN que inicia el protocolo de enlace TCP. Pero el SNI solo está en ClientHello del protocolo de enlace TLS, que se envía solo después de que se realiza el protocolo de enlace TCP. En otras palabras: la información necesaria para NAT aún no está disponible en el momento en que se necesita.
Si eso no es posible, ¿hay alguna alternativa?
haproxy puede finalizar la conexión TCP y luego reenviar los datos según el SNI en ClientHello, sin terminar TLS en el proxy. Luego puede reenviar la IP de origen original del cliente dentro de la conexión TCP utilizando el protocolo PROXY (básicamente un encabezado al comienzo de la conexión reenviada). Si el servidor ascendente no comprende el protocolo PROXY, se puede utilizar software comoproxymmpara SNAT la conexión desde haproxy para que muestre la IP de origen original.