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