[bittorrent] when users are behind a transparent proxy, it is possible to trace their real IP address ?
hkucsfyp2005 at gmail.com
Wed Mar 22 09:31:41 EST 2006
I am talking about the most navie way.
I think I want to know the true IP address of the client who is behind a
I agree with you . From an end user view , it is pointless to determine the
ip address of other clients.
However, I want to know where other clients come from(coz i am working in a
computer project for final year). Therefore, I want to find out their IP
address but not the proxy ip adderss.
In fact, I have some ideas on that. But i am not sure if it is feasible or
As you metioned before, I can look for the X-Forwarded-For header .
However, X-Forwarded-For header can only be used when a client visit a web
Then the X-Forwarded-For header will be included in the http request.
Now on my hand, I only have a torrent.
Can I still able to find out the true ip address of the clients ?
P.S. I am working on trackers not only running on port 80.
On 3/18/06, Brian Dessent <brian at dessent.net> wrote:
> FYP 2005 wrote:
> > a number of BT client can be configured to use proxy.
> > However, it is possible to write a program to trace the real ip when
> > user is behind a transparent proxy ?
> I don't really understand the context of this question. Are you asking
> how a tracker should deal with clients behind transparent proxies? If
> that is the case then the solution is simple. A transparent HTTP proxy
> by definition will only intercept packets on port 80, so if the tracker
> is being run on a port that is not 80 (which is a recommended best
> practice) then there is nothing that needs to be done - the transparent
> proxy will be oblivious. Never run a tracker on port 80.
> You can also try looking for the X-Forwarded-For header but this is
> controversial because this is user-supplied data that cannot be trusted,
> so blindly accepting it as the user's true IP address is not a good
> idea. If you combine it with the typical tracker NAT-check then it is
> usually reliable, however there is still an argument that you could
> potentially be taking part in a (mild) DDOS attack by using this field
> to launch the NAT check. I'm not sure how valid that logic is though.
> If that was not what you were asking then I fail to understand the
> question. From the client side the IP address of the client is not
> necessary to know, so it's pointless to try to determine it. If you do
> the naive way of just querying the operating system you will fail if the
> user has NAT, as you'll get the RFC1918 address. If you use an external
> web service on port 80 then you will fail if the user is behind a
> transparent proxy, because you will retrieve the proxy's address. But
> again, this is not necessary for the BT protocol because the tracker
> will always get the client's true IP address (assuming it's not
> listening on port 80) and it should never have to be specified.
> The worst case scenario is when the client is behind NAT *and* the ISP
> has a transparent proxy that does not inject the X-Forwarded-For: or
> Via: headers *and* the tracker is on port 80. In this case the tracker
> will get the incorrect IP address for the client, and the client will
> have no reliable way of getting its true IP address. The only
> reasonable ways for the client to get the correct IP address is to query
> an external server on a port other than 80, or to have some other peer
> tell it its real address. The distributed peer database used by modern
> clients has this feature -- a client will report to another client when
> it is reporting a wrong address. You can see this in the console log of
> Azureus occasionally.
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent