Name: Anonymous 2008-07-21 17:00
TalkTalk (really crappy British ISP I'm on) have broken Rapidshare, and I doubt it's the only one. They're feeding it - but not other web traffic - through a transparent proxy, so everyone shares the same IP address and someone else will always be trying to download something. (How do you tell? It tells you that someone from the same IP is downloading something, the IP isn't yours, and whatismyip.com gives your real IP.) Plus, even if you do get through, the download server isn't proxied, so the IPs won't match and it won't let you download.
Why? Cleanfeed - the same content filter that blocked /b/, and which all UK ISPs are supposed to have now. The way it works is by sending all traffic to the server hosting the blocked content via a transparent proxy, and I'm going to show you how to spot it in action.
First, get nmap from http://nmap.org/download.html and install it. It's a really powerful network probing tool, and we'll need it later. Also, make sure you have a decent version of either traceroute, tracepath or tracert installed. (If you're using Windows, you should have this already).
Now, run "nmap --traceroute -p 80 megaupload.com" (as admin/root). You'll get something like:
TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
[ ... snip ... ]
5 39.73 gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10)
6 37.61 gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50)
7 36.31 gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235)
8 123.30 mega038.carpathiahost.net (209.222.148.135)
What you'd normally get is the traffic passing through your ISP's network, across a few intermediate systems, and through the destination network. opaltelecom.net is TalkTalk, so the request is being answered from within their network. (There can be valid reasons for this, like if it's one of their sites or a CDN like Akamai, but they should be obvious). Now let's use "tracepath 209.222.148.135" to find the path the traffic should be taking:
[ ... cut for privacy ... ]
5: gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10) 63.474ms asymm 8
6: gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50) 64.322ms
7: gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235) 63.444ms
8: 62.24.251.41 (62.24.251.41) 63.412ms
9: gig-14-1-rtr001.thn.as13285.net (62.24.254.81) 72.232ms asymm 10
10: xe-11-2-0-scr001.thn.as13285.net (78.144.1.4) 71.208ms asymm 12
11: host-78-144-0-119.as13285.net (78.144.0.119) 71.210ms asymm 13
12: cr02.ldn01.pccwbtn.net (195.66.224.167) 73.080ms asymm 14
13: carpathia.ge12-1.br02.ash01.pccwbtn.net (63.218.94.166) 150.612ms asymm 16
14: mega038.carpathiahost.net (209.222.148.135) 153.695ms reached
Resume: pmtu 1432 hops 14 back 46
Notice the much longer path that actually leaves the TalkTalk network and passes through intermediate routers. So some server within TalkTalk, and not the proper destination, was replying to the previous requests. Some cheap providers do this sort of transparent proxying with all sites, but that's easy enough to spot by doing the same test on other sites. TalkTalk is just doing this for selected sites, and Cleanfeed is the only reason I can think of.
Why? Cleanfeed - the same content filter that blocked /b/, and which all UK ISPs are supposed to have now. The way it works is by sending all traffic to the server hosting the blocked content via a transparent proxy, and I'm going to show you how to spot it in action.
First, get nmap from http://nmap.org/download.html and install it. It's a really powerful network probing tool, and we'll need it later. Also, make sure you have a decent version of either traceroute, tracepath or tracert installed. (If you're using Windows, you should have this already).
Now, run "nmap --traceroute -p 80 megaupload.com" (as admin/root). You'll get something like:
TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
[ ... snip ... ]
5 39.73 gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10)
6 37.61 gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50)
7 36.31 gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235)
8 123.30 mega038.carpathiahost.net (209.222.148.135)
What you'd normally get is the traffic passing through your ISP's network, across a few intermediate systems, and through the destination network. opaltelecom.net is TalkTalk, so the request is being answered from within their network. (There can be valid reasons for this, like if it's one of their sites or a CDN like Akamai, but they should be obvious). Now let's use "tracepath 209.222.148.135" to find the path the traffic should be taking:
[ ... cut for privacy ... ]
5: gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10) 63.474ms asymm 8
6: gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50) 64.322ms
7: gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235) 63.444ms
8: 62.24.251.41 (62.24.251.41) 63.412ms
9: gig-14-1-rtr001.thn.as13285.net (62.24.254.81) 72.232ms asymm 10
10: xe-11-2-0-scr001.thn.as13285.net (78.144.1.4) 71.208ms asymm 12
11: host-78-144-0-119.as13285.net (78.144.0.119) 71.210ms asymm 13
12: cr02.ldn01.pccwbtn.net (195.66.224.167) 73.080ms asymm 14
13: carpathia.ge12-1.br02.ash01.pccwbtn.net (63.218.94.166) 150.612ms asymm 16
14: mega038.carpathiahost.net (209.222.148.135) 153.695ms reached
Resume: pmtu 1432 hops 14 back 46
Notice the much longer path that actually leaves the TalkTalk network and passes through intermediate routers. So some server within TalkTalk, and not the proper destination, was replying to the previous requests. Some cheap providers do this sort of transparent proxying with all sites, but that's easy enough to spot by doing the same test on other sites. TalkTalk is just doing this for selected sites, and Cleanfeed is the only reason I can think of.