Shulou(Shulou.com)06/02 Report--

This article shows you how to get the client source IP in different scenarios. The content is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

There may be many different forms of proxy servers between the client and the container server, so how do you get the real source ip of the client in the container?

K8s has become the standard of containerization nowadays, while people enjoy the efficiency and convenience brought by containers, they also encounter some troubles: there may be many different forms of proxy servers between the client and the container server, so how to get the real source ip of the client in the container? Let's discuss how to get the source ip for several scenario types.

Introduction to the principle:

Layer 4 forwarding:

The Nodeport:nodeport access method is to map the container port to the node port. If "Service Affinity" selects "Cluster level", it is impossible to obtain the client source ip if it needs to be forwarded once, while the "Node Mode" can obtain the client source ip without forwarding.

ELB:ELB access is achieved through Huawei Cloud ELB products, and "service affinity" also requires "node level", where "shared" ELB needs to install TOA plug-in on the node, while "exclusive" ELB defaults to transparent source ip and does not need to install TOA plug-in.

Layer 7 forwarding:

Ingress: when the application is accessed at layer 7, the client source ip is stored in the "X-Forwarded-For" field of the HTTP header by default, and no other operations are required.

Specific operations:

1. Load balancing (LoadBalancer)

In the Service mode of load balancer (LoadBalancer), the following prerequisites must be met to obtain the source IP in the container:

1. Service affinity selects "node level" instead of "cluster level".

two。 Install the TOA plug-in on the node where pod is located. ("exclusive" ELB does not need to do the following)

Install the TOA plug-in as follows:

1) prepare the compilation environment:

Install the gcc compiler by executing the following command.

] # yum install gcc

Install the make tool by executing the following command.

] # yum install make

2) compile kernel module

A) download the TOA kernel module source code.

] # wget https://github.com/Huawei/TCP_option_address/archive/master.zip b) execute the following command to enter the source directory and compile the module.

] # unzip master.zip] # cd TCP_option_address-master/src/] # make

The compilation process does not prompt warning or error, indicating that the compilation is successful. Check whether the toa.ko file has been generated in the current directory.

Note: if the error message "config_retpoline=y but not supported by the compiler, Compiler update recommended" indicates that the gcc version is too old, it is recommended to upgrade gcc to a newer version.

3) load kernel module

Execute the following command to load the kernel module.

] # insmod toa.ko

Execute the following command to verify the module load and view the kernel output.

] # dmesg | grep TOA

If the prompt contains "TOA: toa loaded", the kernel module is loaded successfully.

4) automatically load kernel modules

In order for the TOA kernel module to take effect when the system starts, you can add the command to load the TOA kernel module to the customer's startup script.

Create a new toa.modules file in the "/ etc/sysconfig/modules/" directory. This file contains the loading script for the TOA kernel module. Please refer to the following example:

#! / bin/sh/sbin/modinfo-F filename / root/toa/toa.ko > / dev/null 2 > & 1if [$?-eq 0]; then/sbin/insmod / root/TCP_option_address-master/src/toa.kofi

Note: where "/ root/TCP_option_address-master/src/toa.ko" is the path to the TOA kernel module file, customers need to replace it with their own compiled TOA kernel module path.

Execute the following command to add executable permissions to the toa.modules startup script.

] # chmod + x / etc/sysconfig/modules/toa.modules

In this case, the source IP of the client can be obtained from the layer-4 load balancer (which can be viewed through netstat).

Test points: in this case, you can use netstat to see the IP address where the client connects to the POD.

II. Node access (NodePort)

The service affinity of Service of node access (NodePort) type chooses "node level" instead of "cluster level", that is, the spec.externalTrafficPolicy of Service needs to be set to Local.

Figure 1 Service affinity selection node level

Layer 3 and layer 7 load balancer (Ingress)

In the layer-7 load balancer mode, you cannot obtain the client IP on the layer-4 load balancer (you cannot view the client IP through netstat). You need to configure the application server and obtain it through the x-forward-for in the http header of the layer-7 load balancer.

The real visitor IP will be placed by the load balancer in the X-Forwarded-For field of the HTTP header in the following format:

X-Forwarded-For: visitor real IP, proxy server 1-IP, proxy server 2-IP,...

Key points of testing: get the http request header "x-forward-for" from the container, and the obtained IP is the IP of the client.

The above content is what is the method of obtaining client source IP in different scenario containers. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.