Estos casos prácticos son una guía de capacitación para comprender mejor cómo funcionan las tecnologías de redes, seguridad y alta disponibilidad.

En primer lugar, intente el siguiente ejercicio:

Step 1. Install Zevenet CE from GIT, SF or Docker
            https://www.zevenet.com/community

Step 2. Create L4xNAT farm with 2 backends and NAT or DNAT mode
            https://www.zevenet.com/knowledge-base/

Step 3. Execute in a console of Zevenet CE and try to understand the result of:
            root# iptables -t mangle -n -L
            root# iptables -t nat -n -L

Dudas y comentarios en el funcionario. lista de envío!

Respuesta

El equilibrador de carga es un dispositivo de red encargado de garantizar el flujo de tráfico entre el cliente y los backends o servidores reales, por lo que los pasos de 4 se tomarán en cuenta para garantizar los flujos, paquetes por paquete de la conexión en la capa 4:

1. El paquete del cliente se envía desde el cliente al equilibrador de carga.
2. El paquete se envía desde el equilibrador de carga a un servidor real o backend seleccionado
3. El paquete responde desde el servidor al equilibrador de carga.
4. El paquete se devuelve al cliente como respuesta.

Zevenet La capa 4 (perfiles LSLB - L4xNAT) maneja todos estos paquetes usando netfilter subsistema a través de iptables y el sistema de enrutamiento de red.

Por este motivo, al configurar un DTA modo agrupar y ejecutar los comandos de iptables podemos encontrar reglas generadas en las tablas desaparecido y nat de netfilter. Más información sobre Tablas de Netfilter aquí .

En primera PREROUTING cadena de la desaparecido tabla se muestran las reglas que coinciden:

- Todos los paquetes entrantes de todas las fuentes o clientes cuyo destino es la dirección virtual y el puerto del servicio (en el ejemplo será 192.168.101.250:443)
- Luego marque los paquetes de acuerdo con un algoritmo determinado, en este caso es un peso basado en un método de probabilidad.

root@zevenet:~# iptables -L -t mangle -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0            CONNMARK restore
MARK       tcp  --  0.0.0.0/0            192.168.101.250      statistic mode random probability 1.00000000000 multiport dports 443 /*  FARM_app_1_  */ MARK set 0x20d
MARK       tcp  --  0.0.0.0/0            192.168.101.250      statistic mode random probability 0.50000000000 multiport dports 443 /*  FARM_app_0_  */ MARK set 0x20c
CONNMARK   all  --  0.0.0.0/0            0.0.0.0/0            state NEW CONNMARK save

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Ahora que los paquetes entrantes están marcados, en la PREROUTING cadena de la nat En la tabla utilizamos la marca de paquete para cambiar la dirección de destino del paquete a un backend u otro. Para este ejemplo, las direcciones IP 192.168.1.10 y 192.168.1.11 Son los servidores reales.

root@zevenet:~# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20c /*  FARM_app_0_  */ to:192.168.1.10:443
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20d /*  FARM_app_1_  */ to:192.168.1.11:443

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

EL conntrack tabla gestiona la traducción de la dirección de destino y en la DTA En este modo, el paquete de retorno se gestiona mediante rutas, ya que el equilibrador de carga será la puerta de enlace predeterminada de los backends.

En el caso de los NATo SNAT como se conoce comúnmente, conntrack gestiona no solo la traducción de la dirección de destino, sino también la traducción de la dirección de origen. En este caso, la única diferencia con DTA es que el paquete respondido no es administrado por el sistema de enrutamiento sino por la tabla conntrack. Entonces podemos encontrar solo 2 reglas nuevas en el POSTROUTING Cadena de la tabla nat para realizar el MASQUERADING con la dirección IP virtual de la granja.

root@zevenet:~# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20c /*  FARM_app_0_  */ to:192.168.1.10:443
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20d /*  FARM_app_1_  */ to:192.168.1.11:443

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20c /*  FARM_app_0_  */ to:192.168.101.250
SNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x20d /*  FARM_app_1_  */ to:192.168.101.250

¿Más dudas? Preguntar al lista de envío!