
Tengo las siguientes reglas de iptables.
Reenvío de paquetes desde 1.2.3.4 y 5.6.7.8 (fuentes) que llegan al puerto 10000 a un servidor Socks5 externo en 10.10.10.10:1080. La IP del servidor es 50.50.50.50
Este esquema funciona bien si la cantidad fuente no es alta y al mismo tiempo la cantidad de calcetines externos5 tampoco es alta. Una vez que tenga 50 fuentes y 30k calcetines externos, iptables se bloquea y no se reenvían paquetes, por lo que sospecho que hay un límite en el rendimiento de iptables. ¿Alguien puede decirme si nftables es más potente y, en caso afirmativo, cómo traducir mis reglas a nftables?
*nat
:PREROUTING ACCEPT [1:40]
:INPUT ACCEPT [1:40]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -s 1.2.3.4,5.6.7.8 -p tcp -m tcp --dport 10000 -j DNAT --to-destination 10.10.10.10:1080
-A POSTROUTING -d 10.10.10.10/32 -p tcp -m tcp --dport 1080 -j SNAT --to-source 50.50.50.50
COMMIT
*filter
:INPUT ACCEPT [15:1012]
:FORWARD ACCEPT [26:1348]
:OUTPUT ACCEPT [9:932]
COMMIT
Respuesta1
A continuación se ofrece una explicación aproximada de lo que puede salir mal.
Antes deiptablesnormas:
X (X=2 en el ejemplo inicial de OP) direcciones IP de origen con 2^16 posibles puertos de origen y 1 dirección y puerto de destino:
X * 2^16 conexiones posibles.
Después de laiptablesreglas: X fuentes quedaron agrupadas en una sola fuente
1 * 2^16 conexiones posibles.
X * No se pueden hacer 2^16 conexiones para que quepan en solo 2^16 conexiones. La colisión del puerto de origen comenzará a ocurrir cada vez con más frecuencia y se resolverá cambiando el puerto de origen, pero encontrar un puerto de origen libre que no entre en conflicto con otro flujo será cada vez más difícil: la degradación del rendimiento comienza a aumentar, incluso pueden comenzar a ocurrir paquetes descartados.
¿Esto sucedería de manera diferente siiptablesfueron reemplazados connftables? No. En ambos casos no son las partes que resuelven la colisión. Esta resolución se realiza en el mismo backend común de Netfilter:elnf_nat
módulo del núcleo, posiblemente iterando varias veces si es necesario e incluso rindiéndose (es decir, descartando el nuevoconectarentrada y el paquete ha desencadenado su creación tentativa).
La causa es la NAT de origen realizada cuando hay un único destino posible (el servidor): debe evitarse.
Posibles soluciones:
no utilice NAT de origen. En su lugar, se debe implementar un enrutamiento adecuado (incluso si esto requiere múltiples conexiones o un túnel) para que 10.10.10.10 no tenga que ver una sola fuente 50.50.50.50. La pregunta no explica por qué se requiere este SNAT, por lo que no es posible brindar más detalles.
tener múltiples direcciones de origen para equilibrar la carga y distribuir la presión del puerto de origen. Esto se puede lograr coniptablesutilizando el
statistic
módulo para equilibrar la carga en múltiplesSNAT
objetivos.
Cambiar anftablesSuele ser una mejora, pero en este caso no parece ser la solución.