[bittorrent] when users are behind a transparent proxy, it is possible to trace their real IP address ?

FYP 2005 hkucsfyp2005 at gmail.com
Wed Mar 22 09:31:41 EST 2006


Thanks Brian.


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
transparent proxy.
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
not .
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
server.
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.
>
> Brian
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20060322/812fa8f4/attachment.html 


More information about the BitTorrent mailing list