Jun 30 2011, 01:05 PM
QUOTE(RAMChYLD @ Jun 30 2011, 10:22 AM)
Same. The block seems to be back up 
I figured out a bypass, but it is confirmed that it's a routing block. All signs point to a linux iptables-style blockage. Also, since these blockages are likely logged (I am quite well versed with the way IPTables worked), it is possible that the log will be scruntinized and the workaround be fixed soon.
Here's how to do it. No point keeping it a secret since it's logged on their effing server. You'll need to be already on GoogleDNS first:
1. Open a tab and point it to a nonexistant page on Megaupload's site to get a 404 (ie. www.megaupload.com/\)
2. Open another tab and load Megaupload again. It will work.
3. After a while the connection will fail again. Go back to the tab with the 404 and refresh.
4. You'll earn yourself another few minutes
5. Rinse and repeat.
This is definitely a no-go for large files when using a free account or having no account at all, since you cannot resume.
For once Linux is a villain here
The best way is to just cut off Yes and let them pokai and die.
From what you describe, it doesn't look like an iptables block. If they wanted to just block destination IP ranges, they would just drop the routes for it. Less CPU usage, no need to read into TCP/IP headers so much. Anyway if opening a tab twice works, it means they could be using DPI which fails on pipelined HTTP requests. If you can open a non-existant page on megaupload.com, it means :I figured out a bypass, but it is confirmed that it's a routing block. All signs point to a linux iptables-style blockage. Also, since these blockages are likely logged (I am quite well versed with the way IPTables worked), it is possible that the log will be scruntinized and the workaround be fixed soon.
Here's how to do it. No point keeping it a secret since it's logged on their effing server. You'll need to be already on GoogleDNS first:
1. Open a tab and point it to a nonexistant page on Megaupload's site to get a 404 (ie. www.megaupload.com/\)
2. Open another tab and load Megaupload again. It will work.
3. After a while the connection will fail again. Go back to the tab with the 404 and refresh.
4. You'll earn yourself another few minutes
5. Rinse and repeat.
This is definitely a no-go for large files when using a free account or having no account at all, since you cannot resume.
For once Linux is a villain here
The best way is to just cut off Yes and let them pokai and die.
1) Using another DNS works -- they're not touching DNS queries. You can still resolve *.megaupload.com to whatever IP.
2) There is no route block, you can still reach megaupload's subnet.
3) When you first 404 on megaupload, your browser has opened 1 TCP connection to megaupload.com. The second *valid* request is then pipelined through that same TCP connection (as per the HTTP/1.1 RFC spec) and their DPI doesn't pick up on it because it's only logging the first few bytes of the TCP stream. I've seen this behavior on TM's Streamyx DPI last year which I believe was a Sandvine box.
So basically, to bypass this without a VPN you could open a TCP connection with megaupload.com on TCP port 80, send a fake invalid HTTP request such as :
CODE
GET /\ HTTP/1.1\r\n
Host: blah.com\r\n
\r\n\r\n
Host: blah.com\r\n
\r\n\r\n
.. then follow up with a :
CODE
GET /your_valid_sub_url_here HTTP/1.1\r\n
Host: megaupload.com\r\n
\r\n\r\n
Host: megaupload.com\r\n
\r\n\r\n
That's what your browser is probably doing anyway
Of course, you would need to program a tool to automate this behavior (unless you like piping binary data out manually from netcat) but it works.
Quote
0.0165sec
0.38
6 queries
GZIP Disabled