1 |
On Saturday 24 Aug 2013 14:23:26 Grant wrote: |
2 |
> >> I set up squid on a remote system so I can browse the internet from |
3 |
> >> that IP address. It works but it stalls frequently. I had similar |
4 |
> >> results with ziproxy. I went over this with the squid list but we got |
5 |
> >> nowhere as it seems to be some kind of a system or network problem. |
6 |
> >> |
7 |
> >> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the |
8 |
> >> -en tire-system-td4660893.html |
9 |
> >> |
10 |
> >> Can anyone here help me figure out what is wrong? I'm not sure where to |
11 |
> >> start. |
12 |
> >> |
13 |
> >> - Grant |
14 |
> > |
15 |
> > Just a quick pointer in case it applies to you: if you tunnel into the |
16 |
> > proxy machine (using ssh, VPN, proxychains and what not) you would |
17 |
> > suffer from packet fragmentation, which could quickly snowball. In this |
18 |
> > case try reducing your mtu to lower values, than the default ethernet |
19 |
> > 1500 byte packets, to cater for the overhead of the larger tunnelling |
20 |
> > headers. |
21 |
> |
22 |
> I've tried disconnecting from my SSH tunnel and changing the mtu on my |
23 |
> laptop and on the remote proxy server via ifconfig and there is some |
24 |
> kind of an improvement but I can't narrow it down. I've tried mtu |
25 |
> down to 1000 on both systems but the proxy server still stalls |
26 |
> sometimes. Any tips for narrowing this down further? |
27 |
> |
28 |
> - Grant |
29 |
|
30 |
Now that you mentioned using ssh, I don't think that you can improve this. An |
31 |
mtu at 1000 bytes is lower than I thought might have helped. The problem is |
32 |
caused by stacking tcp packets (tcp within tcp) each of which is using its own |
33 |
timeout for failed fragments. |
34 |
|
35 |
The problem is explained here (tcp meltdown): |
36 |
|
37 |
http://sites.inka.de/~W1011/devel/tcp-tcp.html |
38 |
|
39 |
and here (useful relevant references to other works are also made): |
40 |
|
41 |
http://publications.lib.chalmers.se/records/fulltext/123799.pdf |
42 |
|
43 |
|
44 |
There are some suggested solutions like increasing buffer size, but I don't |
45 |
know this might work in a real world use case. You can experiment with |
46 |
different buffer sizes as suggested here and see if it makes a difference: |
47 |
|
48 |
http://www.cyberciti.biz/faq/linux-tcp-tuning/ |
49 |
|
50 |
|
51 |
If the interruptions are not acceptable to you, you could consider using a |
52 |
different tunnel method. A network layer VPN, like IPSec (you can use |
53 |
StrongSwan which also offers IKEv2 and MOBIKE for your laptop, or ipsec-tools |
54 |
with racoon for IKEv1 only) should work without such problems. You will be |
55 |
tunnelling tcp in udp packets. If you tunnel to your home router you will |
56 |
need to configure an IPSec tunnel mode connection, otherwise you would use an |
57 |
IPSec transport mode connection directly to your server after you allow IP |
58 |
protocol 50 packets through your router. |
59 |
|
60 |
HTH. |
61 |
-- |
62 |
Regards, |
63 |
Mick |