Практический пример I: Понимание балансировки нагрузки NAT и DNAT уровня 4

РАЗМЕЩЕНО 20 сентября, 2017

Эти практические примеры являются учебным пособием для лучшего понимания работы сетей, безопасности и технологий высокой доступности.

Во-первых, попробуйте следующее упражнение:

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

Сомнения и комментарии в официальном список адресатов!

Ответ

Балансировщик нагрузки - это сетевое устройство, отвечающее за обеспечение потока трафика между клиентом и бэкэндами или реальными серверами, поэтому будут предприняты шаги 4, чтобы обеспечить потоки, пакет на пакет соединения на уровне 4:

Load_Balancer_l4_packet_flows

1. Пакет от клиента отправляется с клиента на балансировщик нагрузки
2. Пакет отправляется с балансировщика нагрузки на один выбранный реальный сервер или серверную часть
3. Пакет отвечает от сервера на балансировщик нагрузки
4. Пакет отправляется обратно клиенту как ответ

Zevenet уровень 4 (профили LSLB - L4xNAT) обрабатывает все эти пакеты, используя Netfilter подсистема через Iptables и система сетевой маршрутизации.

По этой причине при настройке ДТА В режиме фермы и выполнения команд iptables мы можем найти сгенерированные в таблицах правила калечить и натуральный сетевого фильтра. Дополнительная информация о Таблицы Netfilter здесь .

В разделе PREROUTING цепь калечить В таблице показаны соответствующие правила:

- Все входящие пакеты от всех источников или клиентов, местом назначения которых является виртуальный адрес и порт службы (в примере это будет 192.168.101.250:443)
- Затем пометьте пакеты по определенному алгоритму, в данном случае - это вес, основанный на вероятностном методе.

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         

Теперь, когда входящие пакеты помечены, в PREROUTING цепь натуральный В таблице мы используем метку пакета, чтобы изменить адрес назначения пакета на тот или иной бэкэнд. Для этого примера IP-адреса 192.168.1.10 и 192.168.1.11 настоящие серверы.

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         

Наблюдения и советы этой статьи мы подготовили на основании опыта команды трассировщика таблица управляет трансляцией адреса назначения и в ДТА В этом режиме обратный пакет управляется маршрутами, так как балансировщик нагрузки будет шлюзом по умолчанию для бэкэндов.

В случае NAT или SNAT Как известно, conntrack управляет не только трансляцией адреса назначения, но и трансляцией исходного адреса. В этом случае единственная разница с ДТА заключается в том, что ответный пакет управляется не системой маршрутизации, а таблицей conntrack. Таким образом, мы можем найти всего 2 новых правила в POSTROUTING цепочка таблицы nat для выполнения Маскарадинга с виртуальным IP-адресом фермы.

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

Дальнейшие сомнения? Попросить список адресатов!

Поделись:

Документация в соответствии с условиями GNU Free Documentation License.

Была ли эта статья полезна?

Статьи по теме