Praktischer Fall I: Informationen zum Layer-Lastausgleich zwischen 4 NAT und DNAT

VERÖFFENTLICHT AM 20. September 2017

Diese praktischen Fälle sind ein Schulungsleitfaden, um besser zu verstehen, wie Vernetzung, Sicherheit und Hochverfügbarkeitstechnologien funktionieren.

Versuchen Sie zunächst folgende Übung:

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

Zweifel und Kommentare im Amt Mailing-Liste!

Antworten

Der Lastverteiler ist ein Netzwerkgerät, das für die Sicherstellung des Datenverkehrs zwischen dem Client und den Backends oder realen Servern verantwortlich ist. Daher werden 4-Schritte ausgeführt, um sicherzustellen, dass der Datenfluss pro Paket der Verbindung auf der Ebene 4 fließt:

Load_Balancer_l4_packet_flows

1. Das Paket vom Client wird vom Client an den Lastenausgleich gesendet
2. Das Paket wird vom Load Balancer an einen ausgewählten realen Server oder Backend gesendet
3. Das Paket antwortet vom Server an den Load Balancer
4. Das Paket wird als Antwort an den Client zurückgesendet

Zevenet Schicht 4 (LSLB - L4xNAT-Profile) verarbeitet alle diese Pakete mit Netfilter Subsystem durch iptables und das Netzwerk-Routing-System.

Aus diesem Grund bei der Konfiguration von a DTA mode farm und führen Sie die iptables-Befehle aus. In den Tabellen können Sie Regeln finden fehlt und nat von netfilter. Weitere Informationen zu Netfiltertabellen hier .

In den Vorausschauend Kette der fehlt In der Tabelle werden die übereinstimmenden Regeln angezeigt:

- Alle eingehenden Pakete von allen Quellen oder Clients, deren Ziel die virtuelle Adresse und der Port des Dienstes ist (im Beispiel) 192.168.101.250:443)
- Markieren Sie dann die Pakete nach einem bestimmten Algorithmus, in diesem Fall handelt es sich um eine Gewichtung, die auf einer Wahrscheinlichkeitsmethode basiert.

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         

Nun, da die ankommenden Pakete markiert sind, in der Vorausschauend Kette der nat In der Tabelle verwenden wir die Paketmarkierung, um die Zieladresse des Pakets in das eine oder andere Backend zu ändern. Für dieses Beispiel die IP-Adressen 192.168.1.10 und 192.168.1.11 sind die echten Server.

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         

Der Conntrack Tabelle verwaltet die Zieladressübersetzung und in der DTA In diesem Modus wird das Rückkehrpaket über Routen verwaltet, da der Lastausgleicher das Standardgateway der Backends ist.

Im Fall von NAT, oder SNAT Wie allgemein bekannt, verwaltet der Conntrack nicht nur die Übersetzung der Zieladresse, sondern auch die Übersetzung der Quelladresse. In diesem Fall ist der einzige Unterschied mit DTA ist, dass das beantwortete Paket nicht vom Routing-System, sondern von der Conntrack-Tabelle verwaltet wird. So finden wir nur 2 neue Regeln in der POSTROUTING kette der nat table zur durchführung der Maskieren mit der virtuellen IP-Adresse der Farm.

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

Weitere Zweifel? Fragen Sie den Mailing-Liste!

Teilen:

Dokumentation unter den Bedingungen der GNU Free Documentation License.

War dieser Artikel hilfreich?

Ähnliche Artikel