ASP。网络请求。服务器变量生成本地IP地址而不是远程IP

时间:2022-09-28 02:06:52

Got an asp.net web page in c#. One thing we would like to do is track hits to the site including their IP address. I implemented some code (thanks to SO) but the logged IP address always seem to be local, ie: 192.168.x.x. I have tried it from a variety of devices, even my phone and Version MiFi just to make sure its not something weird with the ISP but the log always list the same 2-3 different internal ip addresses (seems to change a little as the day goes on).

在c#中有一个asp.net网页。我们想做的一件事是跟踪网站的点击,包括他们的IP地址。我实现了一些代码(多亏了这个),但是日志IP地址似乎总是本地的,比如:192.168.x。我在各种设备上都试过了,甚至我的手机和MiFi版本都试过了,只是为了确保ISP不会觉得奇怪,但日志总是列出相同的2-3个不同的内部ip地址(似乎随着时间的推移会有所改变)。

Here is my function that gets the IP (again thanks to postings here on SO):

这是我获得IP的函数(再次感谢这里的帖子):

protected IPAddress GetIp(HttpRequest request)
{
    string ipString;
    if (string.IsNullOrEmpty(request.ServerVariables["HTTP_X_FORWARDED_FOR"]))
        ipString = request.ServerVariables["REMOTE_ADDR"];
    else
        ipString = request.ServerVariables["HTTP_X_FORWARDED_FOR"].Split(",".ToCharArray(), StringSplitOptions.RemoveEmptyEntries).FirstOrDefault();

    IPAddress result;
    if (!IPAddress.TryParse(ipString, out result))
        result = IPAddress.None;

    return result;
}

public void logHit()
{
    IPAddress ip = GetIp(Request);
    string sIP = ip.ToString();
}

I tried this as well which yields the same result:

我也试过这个,结果是一样的:

HttpContext.Current.Request.UserHostAddress;

When I do a call on the client side using something like the service on appspot, it works just fine:

当我在客户端使用类似于appspot的服务进行调用时,它工作得很好:

<script type="application/javascript">
    function getip(json) {
        //txtIP is a input box on the form
        document.getElementById("txtIP").value = json.ip;
    }
</script>

<script type="application/javascript" src="http://jsonip.appspot.com/?callback=getip"></script>

I suppose I could do a round-about way by hitting that appspot link and parse it out but that seems like a whole lot of trouble for something that should be simple.

我想我可以通过点击appspot链接并解析它来做一个循环,但是对于应该很简单的东西来说,这似乎是一个很大的麻烦。

Could it be the IIS on the server? Some kind of redirect going on? The ip addresses logged are NOT the servers. The problem is I dont have direct access to it so I have to talk to the guys that admin it and would like to give them some direction before they just start changing things.

是服务器上的IIS吗?某种重定向?记录的ip地址不是服务器。问题是我不能直接访问它,所以我必须和管理它的人谈谈,在他们开始改变事情之前给他们一些指示。

Thanks

谢谢

Ernie

厄尼

2 个解决方案

#1


0  

It depends on your network structure. Simply a firewall or load balancer can change the variables which you are checking.

这取决于你的网络结构。简单地说,防火墙或负载均衡器可以更改您正在检查的变量。

if you are using a load balancer check this: How to get visitor IP on load balancing machine using asp.net

如果您正在使用负载均衡器,请检查以下内容:如何使用asp.net在负载平衡机上获得访问者IP

if your sever is behind a firewall check this: Find if request was forwarded from firewall to IIS

如果您的服务器位于防火墙之后,请检查以下内容:查找是否将请求从防火墙转发到IIS

#2


2  

If the HTTP_X_FORWARDED_FOR header is truly supported, then I think this would not be either forward or reverse proxy server causing this, but more likely Dynamic Network Address Translation or Dynamic Port Address Translation, which is happening below the application layer on the TCP/IP stack and thus would not affect an HTTP request header.

如果HTTP_X_FORWARDED_FOR头确实是支持,我认为这不会向前或反向代理服务器造成,但更有可能的动态网络地址转换或动态端口地址转换,这是发生在应用程序层上的TCP / IP堆栈,因此不会影响一个HTTP请求头。

There are many ways to configure NAT, most of which would not cause these symptoms, but it is certainly possible to configure NAT in a way that would present this problem. Dynamic NAT or Dynamic PAT would be two such examples, and I would suggest this is what you ask your network administrators.

配置NAT的方法有很多,其中大部分不会导致这些症状,但是配置NAT的方式肯定是有可能出现这个问题的。动态NAT或动态PAT就是两个这样的例子,我建议这是你问你的网络管理员的问题。

For more on Dynamic NAT/PAT, with good examples, you could review: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html

有关动态NAT/PAT的更多信息,请参考http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html

In a typical NAT scenario, the request packets reach the NAT device (firewall or router) as: FROM - 5.5.5.5 (public address of the client) TO - 6.6.6.6 (the public address of the server)

在典型的NAT场景中,请求包到达NAT设备(防火墙或路由器)的位置为:从- 5.5.5.5(客户端的公共地址)到- 6.6.6(服务器的公共地址)

The "typical" NAT configuration would rewrite only the destination, as follows: FROM - 5.5.5.5 TO - 192.168.6.6 (the private address of the server)

“典型的”NAT配置将只重写目的地,如下所示:从- 5.5.5到- 192.168.6.6(服务器的私有地址)

In this typical case, the server would still see REMOTE_ADDR as 5.5.5.5, as that is the source address on the incoming request. Then, the packets would be returned to 5.5.5.5, and the response would return to the client successfully.

在这种典型情况下,服务器仍然将REMOTE_ADDR视为5.5.5.5,因为这是传入请求的源地址。然后,数据包返回到5.5.5.5,响应将成功返回到客户端。

Now, in the case of dynamic PAT, for example, the request would reach the NAT device as follows: FROM - 5.5.5.5 TO - 6.6.6.6

例如,在动态PAT的情况下,请求将到达NAT设备如下:从5.5.5.5到- 6.6.6.6。

Then, the NAT device would rewrite both source and destination packets, maintaining this "dynamic" mapping for only the lifetime of the request: FROM - 192.168.1.1:12345 (the dynamic PAT address) TO - 192.168.6.6 (the private address of the server)

然后,NAT设备将重写源和目标信息包,保持这个“动态”映射仅用于请求的生存期:从- 192.168.1.1:12345(动态PAT地址)到- 192.168.6.6(服务器的私有地址)。

Now, when the server sees this request, it appears to be from private address 192.168.1.1. In fact, with a strict PAT all requests will appear to be from this address. In your case, there are 2 or 3 of these addresses, probably because you may have enough traffic that you risk running out of ports if you use only a single dynamic PAT address.

现在,当服务器看到这个请求时,它似乎来自私有地址192.168.1.1。事实上,在严格的提示下,所有的请求都会出现在这个地址。在您的例子中,有2或3个这样的地址,可能是因为您可能有足够的流量,如果您只使用一个动态PAT地址,您可能会有耗尽端口的风险。

So, your REMOTE_ADDR is 192.168.1.1, because that is actually the source address on the request packets. There is no HTTP_X_FORWARDED_FOR, because the Dynamic PAT is occurring at a lower TCP/IP layer (address and not application).

所以,REMOTE_ADDR是192.168.1.1,因为它实际上是请求包上的源地址。没有HTTP_X_FORWARDED_FOR,因为动态PAT发生在较低的TCP/IP层(地址而不是应用程序)。

Finally, the response is sent back to 192.168.1.1:12345, which routs to the NAT device, which for the duration of the request/response (see the Cisco documentation above) maps it back to 5.5.5.5, and then drops the "dynamic" mapping.

最后,响应被发送回192.168.1.1:12345,它将路由到NAT设备,在请求/响应期间(参见上面的Cisco文档),该设备将其映射回5.5.5.5.5,然后删除“动态”映射。

Everything worked perfectly, the client gets the response back, except that you have no idea of the actual client address from the viewpoint of the server. And if it is dynamic NAT in play, I don't see how you could get this information from the server.

所有的工作都很完美,客户端得到了响应,只是您不知道从服务器的角度来看实际的客户机地址。如果它是动态NAT,我不知道如何从服务器上获取这些信息。

Fortunately, you did exactly the right thing to get the information in javascript on the client, so this likely solves your problem as well as it could be solved.

幸运的是,您完全正确地在客户机上获取了javascript的信息,因此这可能解决了您的问题,也可以解决它。

#1


0  

It depends on your network structure. Simply a firewall or load balancer can change the variables which you are checking.

这取决于你的网络结构。简单地说,防火墙或负载均衡器可以更改您正在检查的变量。

if you are using a load balancer check this: How to get visitor IP on load balancing machine using asp.net

如果您正在使用负载均衡器,请检查以下内容:如何使用asp.net在负载平衡机上获得访问者IP

if your sever is behind a firewall check this: Find if request was forwarded from firewall to IIS

如果您的服务器位于防火墙之后,请检查以下内容:查找是否将请求从防火墙转发到IIS

#2


2  

If the HTTP_X_FORWARDED_FOR header is truly supported, then I think this would not be either forward or reverse proxy server causing this, but more likely Dynamic Network Address Translation or Dynamic Port Address Translation, which is happening below the application layer on the TCP/IP stack and thus would not affect an HTTP request header.

如果HTTP_X_FORWARDED_FOR头确实是支持,我认为这不会向前或反向代理服务器造成,但更有可能的动态网络地址转换或动态端口地址转换,这是发生在应用程序层上的TCP / IP堆栈,因此不会影响一个HTTP请求头。

There are many ways to configure NAT, most of which would not cause these symptoms, but it is certainly possible to configure NAT in a way that would present this problem. Dynamic NAT or Dynamic PAT would be two such examples, and I would suggest this is what you ask your network administrators.

配置NAT的方法有很多,其中大部分不会导致这些症状,但是配置NAT的方式肯定是有可能出现这个问题的。动态NAT或动态PAT就是两个这样的例子,我建议这是你问你的网络管理员的问题。

For more on Dynamic NAT/PAT, with good examples, you could review: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html

有关动态NAT/PAT的更多信息,请参考http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html

In a typical NAT scenario, the request packets reach the NAT device (firewall or router) as: FROM - 5.5.5.5 (public address of the client) TO - 6.6.6.6 (the public address of the server)

在典型的NAT场景中,请求包到达NAT设备(防火墙或路由器)的位置为:从- 5.5.5.5(客户端的公共地址)到- 6.6.6(服务器的公共地址)

The "typical" NAT configuration would rewrite only the destination, as follows: FROM - 5.5.5.5 TO - 192.168.6.6 (the private address of the server)

“典型的”NAT配置将只重写目的地,如下所示:从- 5.5.5到- 192.168.6.6(服务器的私有地址)

In this typical case, the server would still see REMOTE_ADDR as 5.5.5.5, as that is the source address on the incoming request. Then, the packets would be returned to 5.5.5.5, and the response would return to the client successfully.

在这种典型情况下,服务器仍然将REMOTE_ADDR视为5.5.5.5,因为这是传入请求的源地址。然后,数据包返回到5.5.5.5,响应将成功返回到客户端。

Now, in the case of dynamic PAT, for example, the request would reach the NAT device as follows: FROM - 5.5.5.5 TO - 6.6.6.6

例如,在动态PAT的情况下,请求将到达NAT设备如下:从5.5.5.5到- 6.6.6.6。

Then, the NAT device would rewrite both source and destination packets, maintaining this "dynamic" mapping for only the lifetime of the request: FROM - 192.168.1.1:12345 (the dynamic PAT address) TO - 192.168.6.6 (the private address of the server)

然后,NAT设备将重写源和目标信息包,保持这个“动态”映射仅用于请求的生存期:从- 192.168.1.1:12345(动态PAT地址)到- 192.168.6.6(服务器的私有地址)。

Now, when the server sees this request, it appears to be from private address 192.168.1.1. In fact, with a strict PAT all requests will appear to be from this address. In your case, there are 2 or 3 of these addresses, probably because you may have enough traffic that you risk running out of ports if you use only a single dynamic PAT address.

现在,当服务器看到这个请求时,它似乎来自私有地址192.168.1.1。事实上,在严格的提示下,所有的请求都会出现在这个地址。在您的例子中,有2或3个这样的地址,可能是因为您可能有足够的流量,如果您只使用一个动态PAT地址,您可能会有耗尽端口的风险。

So, your REMOTE_ADDR is 192.168.1.1, because that is actually the source address on the request packets. There is no HTTP_X_FORWARDED_FOR, because the Dynamic PAT is occurring at a lower TCP/IP layer (address and not application).

所以,REMOTE_ADDR是192.168.1.1,因为它实际上是请求包上的源地址。没有HTTP_X_FORWARDED_FOR,因为动态PAT发生在较低的TCP/IP层(地址而不是应用程序)。

Finally, the response is sent back to 192.168.1.1:12345, which routs to the NAT device, which for the duration of the request/response (see the Cisco documentation above) maps it back to 5.5.5.5, and then drops the "dynamic" mapping.

最后,响应被发送回192.168.1.1:12345,它将路由到NAT设备,在请求/响应期间(参见上面的Cisco文档),该设备将其映射回5.5.5.5.5,然后删除“动态”映射。

Everything worked perfectly, the client gets the response back, except that you have no idea of the actual client address from the viewpoint of the server. And if it is dynamic NAT in play, I don't see how you could get this information from the server.

所有的工作都很完美,客户端得到了响应,只是您不知道从服务器的角度来看实际的客户机地址。如果它是动态NAT,我不知道如何从服务器上获取这些信息。

Fortunately, you did exactly the right thing to get the information in javascript on the client, so this likely solves your problem as well as it could be solved.

幸运的是,您完全正确地在客户机上获取了javascript的信息,因此这可能解决了您的问题,也可以解决它。