F5 转发IP的配置

A SNAT is an object that maps an original client IP address to a translation address defined on the BIG-IP device. When the BIG-IP system receives a request from a client IP address, and if the client IP address in the request is defined in a SNAT, the BIG-IP system translates the source IP address of the incoming packet to the SNAT address.
When the BIG-IP system translates the source IP address of the incoming packet to the SNAT address, the web server sees request as originating from the SNAT address, not the original client IP address. If the web servers are required to log the original client IP address for requests, the SNAT address translation behavior can become problematic.
It may be necessary for the BIG-IP system to insert the original client IP address in an HTTP header and configure the web server receiving the request to log the client IP address instead of the SNAT address.
Note: HTTP requests processed by the BIG-IP WebAccelerator module will also experience a source address translation.
The client IP address is inserted as an HTTP header named X-Remote-Addr. No configuration is required on the BIG-IP for the X-Remote-Addr HTTP header to be inserted. For information about using the X-Remote-Addr HTTP header to preserve the original client IP ad dress for traffic being translated by a WebAccelerator, refer to SOL7441: Using the X-Remote-Addr HTTP header to preserve the original client IP address for traffic being translated by a WebAccelerator.
To configure the BIG-IP system to insert the original client IP address in an X-Forwarded-For HTTP header, you can use one of the following methods:
∙Enable Insert X ForwardedFor in the HTTP profile
∙iRule
Enabling the Insert XForwardedFor in the HTTP profile
To configure the BIG-IP system to insert the original client IP address in an X-Forwarded-For HTTP header, perform the following procedure:
1. Log in to the BIG-IP Configuration utility.
2. Click Local Traffic.
3. Click Profiles.
4. Click HTTP from the Service s drop-down menu.
5. Click the Create button.
6. Type a name for the HTTP profile.
7. Select the check box next to Insert XForwarded For.
A drop-down menu appears.
8. Select Enabled from the drop-down menu.
9. Click Finished.
You must now associate the new HTTP profile with the virtual
server.
iRule
To configure the BIG-IP system to insert the original client IP address in an X-Forwarded-For HTTP header using an iRule, perform the following procedure:
1. Log in to the BIG-IP Configuration utility.
2. Click Local Traffic.
3. Click iRules.
4. Click the Create button.
5. Type a name in the Name field.
6. Copy and paste the following iRule in the Definition field:
7.when HTTP_REQUEST {
8. HTTP::header insert X-Forwarded-For
[IP::remote_addr]
}
9. Click the Finished button.
You must now associate the new iRule with the virtual server. Configuring the web server to extract the IP address from the HTTP header
Once you have configured the BIG-IP system to insert the original client IP address in an HTTP header using an X-Forwarded-For HTTP header, you must also configure the web
server to extract the IP address from the HTTP header, and log the IP address to the web server log file.
Important: For specific details about using HTTP header information in log files, ref er to the documentation provided by the vendor for your specific web server.
Apache web server
You can configure an Apache web server to extract the IP address from the X-Forwarded-For HTTP header and log the IP address to the web server log file by adding the appropriate logging directives to the Apache httpd.conf file. For example:
LogFormat "%v %{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" X-Forwarded-For CustomLog /var/log/apache/-xforwarded.log X-Forwarded-For
Refer to the Apache logging documentation for more details.
Microsoft IIS web server
You can configure the Microsoft IIS web server to extract the IP address from the
X-Forwarded-For HTTP header and log the IP address to the web server log file. To do so, you will need to download and install the IIS X-Forwarded-For ISAPI Log Filter from
.
The IIS ISAPI filter will look for the X-Forwarded-For HTTP header in the HTTP request. If the IIS ISAPI filter finds an X-Forwarded-For HTTP header in the HTTP request, it will replace the client IP address in the W3SVC log traces with the value of the X-Forwarded-For HTTP header.
To download and install the IIS X-Forward-For ISAPI Filter, perform the following procedure:
1. Log on to .
2. In the upper right corner, search for X-Forwarded-For.
3. In the DevCentral Re sults section, click IIS X-Forward-For
ISAPI Filter.
4. In the article, click CodeShare to download the .zip file.
5. To install the filter, add it to your Microsoft IIS website using the
Microsoft IIS manager utility.
A recent customer issue came up where they were load balancing servers but we unable to get the true client address logged in their IIS logs. They had their servers fronted by a BIG-IP and when clients would make requests the address passed to the server was the internal address of the BIG-IP and not that of the client.
This is a common issue with proxies and fortunately there is a standard for forwarding client information. It is the HTTP X-Forwarded-For header which is handled by most proxies. So, I set out to find an existing ISAPI filter to replace the c-ip (client ip) log value in IIS with the contents of the X-Forwarded-For header (if it exists). I was amazed to find that I couldn't find a single instance of any open source (or even commercial) filter that would do this.
So, I dug out V isual Studio and whipped up a filter that does just that. It's very basic and contains no user configuration so all you need to do is plug it into your Web Applications list of ISAPI Filters within the IIS Administration and you're set to go.
We've released the source under the iControl End User License Agreement (available in any iControl SDK download). Y ou can download it in the CodeShare section of DevCentral. If you find a way to optimize this filter, please let me know and I'll update the sources here.
After 24-hours of posting, a customer already returned some performance testing on the filter indicating that it only effected the traffic by less than 1 percent. I'm sure there are ways to optimize the memory allocation in the filter to speed this up a bit more, but I'll leave that for the community to work on.
Oh, and it should be noted that the X-Forwarded-For header isn't supported the same way across all proxy products so you'll want to make sure you test this out before using it. It is expecting the header to only contain an IP Address as it does a straight substitution on the value in the c-ip section of the log entry.。