Searching ALOHA 12.0
LB Layer 4 Source NAT
LB Layer 4 Source NAT
Warning
Bear in mind that in this mode, the ALOHA is limited to 64000 connections for the service.
The Linux Virtual Server (LVS) analyzes packet per packet and applies load-balancing rules using layer 3 and layer 4 information.
LVS does not hide the client IP address. However, in some cases, it can be useful to change the source IP address to ensure that traffic passes through the ALOHA when in LVS destination NAT mode:
If the server's default gateway cannot be changed
When a router stands between the ALOHA and the server and prevents traffic from returning from the server to reach the ALOHA
To configure the ALOHA to do this:
Enable LVS conntrack
First, you must enable the conntrack module in LVS:
In the ALOHA GUI, browse the Services tab.
Scroll down to the lvs line and click on Setup.
-
Add the keyword
conntrack
to thelvs service
:service lvs ############ Linux Virutal Server, layer 3/4 load balancing conntrack
Click on OK.
Click on Close.
On the lvs line, click on Reload.
Create an LB Layer 4 configuration
In the ALOHA GUI, browse the LB Layer4 tab
-
Set up your configuration according to your needs. The following example uses the port 8000 on the Virtual IP 10.0.0.3:
director web 10.0.0.3:8000 TCP balance leastconn mode nat server web1 10.0.0.20:8000 weight 10 check
Click on OK.
Click on Apply.
Configure a NAT rule
One arm load balancer
In this configuration, the ALOHA is deployed using a single network interface eth0. The servers are in the same subnet as the Virtual IPs hosting the load-balanced services.
--------+-------- 10.0.0.0/24, Virtual IPs, servers
|
| eth0
+---------+
| |
| ALOHA |
| |
+---------+
Warning
The NAT rules must match the traffic as it arrives in the ALOHA, before matching the LVS configuration.
In the ALOHA GUI, browse the NAT tab.
Click on the Add icon.
-
Fill in the following form fields:
Field
Value(s)
IN
eth0
OUT
eth0
Protocol
tcp
Before
Field
Value(s)
Destination
service IP address, i.e. 10.0.0.3
Destination port
TCP port or range, i.e. 8000, or 50000-51000
After
Field
Value(s)
Source
service IP recommended (we could use a local IP, but it means the configuration could not be shared between both members of a cluster)
The form should looks like the picture below:
Click the Apply icon, then click Apply.
Two arms load balancer
In this configuration, the ALOHA is deployed using a two network interfaces: eth0 for public traffic and eth1 for server traffic. The servers and the Virtual IPs are not hosted by the same subnet.
--------+-------- 10.0.0.0/24, Virtual IPs
|
| eth0
+---------+
| |
| ALOHA |
| |
+---------+
| eth1
|
--------+-------- 10.0.3.0/24, servers
Warning
The NAT rules must match the traffic as it arrives in the ALOHA, before matching the LVS configuration.
In order to ensure a consistent configuration over the cluster, we must set up a Virtual IP on eth1 to use to direct traffic to the server. This way, a failover on IPs on eth0 would also trigger a failover of the IP on eth1.
Note
Follow the instructions in the section about VRRP for this purpose.
In the ALOHA GUI, browse the NAT tab.
Click on the Add icon.
-
Fill in the following form fields:
Field
Value(s)
IN
eth0
OUT
eth1
Protocol
tcp
Before
Field
Value(s)
Destination
service IP address, i.e. 10.0.0.3
Destination port
TCP port or range, i.e. 8000, or 50000-51000
After
Field
Value(s)
Source
service IP recommended (we could use a local IP, but it means the configuration could not be shared between both members of a cluster)
The form should looks like the picture below:
Click the Apply icon, then click Apply.
Troubleshooting
To troubleshoot, you can use the packet capture diagnostic tools.
As a filter, use the TCP port used to load-balance (in our example, port 8000
).
$ sudo /usr/sbin/tcpdump -vvvenns0 -c 4 port 8000
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:36:23.148594 [...] 10.0.3.20.41551 > 10.0.0.3.8000: S [...]
11:36:23.148723 [...] 10.0.0.3.41551 > 10.0.0.20.8000: S [...]
11:36:23.149111 [...] 10.0.0.20.8000 > 10.0.0.3.41551: S [...]
11:36:23.149158 [...] 10.0.0.3.8000 > 10.0.3.20.41551: S [...]
4 packets captured
10 packets received by filter
0 packets dropped by kernel
As shown, the traffic from the client 10.0.3.20 was redirect using the VIP 10.0.0.3 when it is forwarded to the server 10.0.0.20.