Когда squid настроен как TPROXY, на некоторых сайтах возвращает ERR_CONNECT_FAIL. Сервер, на котором работает squid, может открывать эти сайты с помощью lynx, wget, curl и т. Д. Даже если мы вручную настроим прокси в браузере или воспользуемся простым REDIRECT или DST-NAT, эти сайты могут открыться.
С этой страницы http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
Это вызывает сбой пути-MTU (PMTUD), что может некоторые удаленные сайты недоступны. Обычно это не проблема, если ваши клиентские машины подключены через Ethernet или DSL PPPoATM, где MTU всех каналов между кешем и клиентом составляет 1500 или больше. Если ваши клиенты подключаются через DSL PPPoE, это, вероятно, будет проблемой, поскольку ссылки PPPoE часто имеют уменьшенный MTU (1472 - очень распространенное явление).
Но у меня такая же проблема с Ethernet
Вот tcpdump от одного клиента:
Щелкните здесь, чтобы увидеть tcpdump, когда я использую tproxy и появляется проблема
и
GET / HTTP/1.0
Host: 80.75.1.4
Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01
Accept-Encoding: gzip, compress, bzip2
Accept-Language: en
User-Agent: Lynx/2.8.8dev.2 libwww-FM/2.14 SSL-MM/1.4.1
HTTP/1.0 504 Gateway Time-out
Server: squid
Mime-Version: 1.0
Date: Wed, 27 Feb 2013 15:39:03 GMT
Content-Type: text/html
Content-Length: 376353
X-Squid-Error: ERR_CONNECT_FAIL 110
X-Cache: MISS from cache.mysquid.com
X-Cache-Lookup: MISS from cache.mysquid.com:3128
Connection: close
пинг -s 1500 80.75.1.4
PING 80.75.1.4 (80.75.1.4) 1500(1528) bytes of data.
1508 bytes from 80.75.1.4: icmp_req=1 ttl=58 time=5.28 ms
1508 bytes from 80.75.1.4: icmp_req=2 ttl=58 time=3.96 ms
1508 bytes from 80.75.1.4: icmp_req=3 ttl=58 time=4.28 ms
ping -s 1473 80.75.1.4 -M do
PING 80.75.1.4 (80.75.1.4) 1473(1501) bytes of data.
From 109.110.160.171 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 109.110.160.171 icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- 80.75.1.4 ping statistics ---
0 packets transmitted, 0 received, +2 errors
ping -s 1472 80.75.1.4 -M do
PING 80.75.1.4 (80.75.1.4) 1472(1500) bytes of data.
1480 bytes from 80.75.1.4: icmp_req=1 ttl=58 time=4.33 ms
1480 bytes from 80.75.1.4: icmp_req=2 ttl=58 time=4.32 ms
--- 80.75.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.320/4.329/4.338/0.009 ms
traceroute --mtu 80.75.1.4
traceroute to 80.75.1.4 (80.75.1.4), 30 hops max, 65000 byte packets
1 x.x.x.10 (x.x.x.10) 0.820 ms F=1500 0.681 ms 0.243 ms
2 y.y.y.1 (y.y.y.1) 2.969 ms 3.185 ms 2.994 ms
3 217.218.181.193 (217.218.181.193) 2.836 ms 2.381 ms 2.487 ms
4 217.218.185.22 (217.218.185.22) 3.617 ms 2.957 ms 3.176 ms
5 78.38.119.237 (78.38.119.237) 2.050 ms 1.808 ms 2.264 ms
6 217.11.30.250 (217.11.30.250) 3.522 ms 3.962 ms 2.674 ms
7 * 80.75.1.4 (80.75.1.4) 3.507 ms *
трассировка 80.75.1.4
1: cache.mysquid.com 0.092ms pmtu 1500
1: x.x.x.10 0.380ms
1: x.x.x.10 0.309ms
2: y.y.y.1 3.390ms asymm 7
3: 217.218.181.193 2.671ms asymm 5
4: 217.218.185.22 2.944ms asymm 5
5: 78.38.119.237 1.684ms
6: 217.11.30.250 4.020ms
7: 80.75.1.4 3.915ms reached
Resume: pmtu 1500 hops 7 back 58
Также пробовал эти шаги http://wiki.squid-cache.org/SquidFaq/SystemWeirdness#Can.27t_connect_to_some_sites_through_Squid
Не знаю связанных или нет, но у меня также есть следующие конфиги
echo 1025 65000 > /proc/sys/net/ipv4/ip_local_port_range
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
echo 131072 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/p2p1/rp_filter
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
и включен / отключен после
#echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
#echo 0 > /proc/sys/net/ipv4/tcp_ecn
Вот правила маршрута TPROXY
/sbin/iptables -t mangle -N DIVERT
/sbin/iptables -t mangle -A DIVERT -j MARK --set-mark 1
/sbin/iptables -t mangle -A DIVERT -j ACCEPT
/sbin/iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
/sbin/iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
Примечание. Подключение к интернет-провайдерам осуществляется через туннель GRE с MTU 1476.
Из tcpdump предоставленный вами вывод, следующие строки указывают на проблему, то есть ваш хост отправляет SYN в пункт назначения, а затем также отправляет RST в пункт назначения, но, конечно, TTL разные, поэтому кажется, что некоторые TPROXY происходит магия:
12:55:17.255717 IP (tos 0x0, ttl 64, id 11025, offset 0, flags [none], proto TCP (6), length 56)
x.x.x.150.62568 > 80.75.1.4.80: Flags [S], cksum 0x5f7e (incorrect -> 0x3c92), seq 572035649, win 14600, options [mss 1460,sackOK,TS val 66378265 ecr 0], length 0
12:55:17.258877 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
x.x.x.150.62568 > 80.75.1.4.80: Flags [R], cksum 0xa779 (correct), seq 572035650, win 0, length 0
12:55:18.253670 IP (tos 0x0, ttl 64, id 11026, offset 0, flags [none], proto TCP (6), length 56)
x.x.x.150.62568 > 80.75.1.4.80: Flags [S], cksum 0x5f7e (incorrect -> 0x3b98), seq 572035649, win 14600, options [mss 1460,sackOK,TS val 66378515 ecr 0], length 0
12:55:18.257916 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 40)
x.x.x.150.62568 > 80.75.1.4.80: Flags [R], cksum 0xa779 (correct), seq 572035650, win 0, length 0
Это не похоже на проблему с MTU. Для начала устранения неполадок предлагаю удалить TPROXY (при условии, что вы это используете) и переключитесь на REDIRECT основанное на правиле и посмотрите, исчезнет ли проблема. Было бы полезно, если бы вы могли вставить свой REDIRECT или связанных правил iptables.
Ошибка 110 Unix означает «Превышено время ожидания соединения». Удаленный сайт не ответил на запрос.
При попытке достичь 80.75.1.4 у меня тоже не получилось. Похоже из ping и traceroute что после въезда в Иран в сети происходит значительная потеря пакетов. Вероятно, поэтому сайт не отвечает.
$ traceroute 80.75.1.4
traceroute to 80.75.1.4 (80.75.1.4), 30 hops max, 60 byte packets
1 hosted.by.leaseweb.com (198.7.57.254) 1.275 ms 1.227 ms 1.888 ms
2 108.59.15.23 (108.59.15.23) 0.249 ms 0.243 ms 0.216 ms
3 be4.cr2.wdc1.leaseweb.net (108.59.15.108) 0.922 ms be3.cr2.wdc1.leaseweb.net (108.59.15.102) 0.922 ms ae1.cr1.wdc1.leaseweb.net (108.59.15.116) 0.275 ms
4 xe-7-2-0-690.edge1.Washington1.Level3.net (4.28.127.57) 1.258 ms xe-5-3-0-673.edge3.Washington1.Level3.net (4.59.144.161) 1.181 ms 1.247 ms
5 ae-4-90.edge1.Washington4.Level3.net (4.69.149.207) 1.779 ms 1.749 ms ae-3-80.edge1.Washington4.Level3.net (4.69.149.143) 1.670 ms
6 ash-bb1-link.telia.net (213.248.81.117) 1.499 ms ash-bb1-link.telia.net (213.248.89.177) 15.220 ms ash-bb1-link.telia.net (213.248.103.233) 1.505 ms
7 ash-bb4-link.telia.net (213.155.130.58) 1.560 ms 1.637 ms *
8 ldn-bb2-link.telia.net (80.91.246.67) 76.651 ms 76.782 ms 76.761 ms
9 ldn-b1-link.telia.net (80.91.248.93) 77.581 ms 77.552 ms 77.515 ms
10 telecominfra-ic-132493-ldn-b1.c.telia.net (213.248.76.42) 234.204 ms 233.666 ms 233.731 ms
11 * * *
12 * 10.10.53.222 (10.10.53.222) 251.938 ms *
13 217.11.30.246 (217.11.30.246) 250.353 ms 250.725 ms 250.322 ms
14 80.75.1.4 (80.75.1.4) 240.361 ms 240.269 ms 240.327 ms
Что еще хуже, похоже, что кто-то использовал адреса RFC 1918 в общедоступном Интернете на этом пути. Среди прочего, это приводит к сбою определения MTU пути, что означает, что многие TCP-соединения также прерываются.
Цитируя из одного источника, Рекомендации Cisco по IP-адресации (PDF):
Любые каналы между маршрутизаторами, подключенные к областям сети с общедоступной адресацией, следует адресовать с помощью общедоступных IP-адресов. Маршрутизаторы, обслуживающие определенные области сети, использующие и продолжающие использовать только частные адреса, могут использовать частные адреса на каналах связи маршрутизатор-маршрутизатор.
Это требование включает и помогает гарантировать правильную работу определения MTU пути (RFC 1191); маршрутизаторы должны иметь возможность отправлять ошибки «слишком большой пакет» и должны быть уверены, что пакеты, вероятно, будут доставлены на исходный хост-источник. Если ссылки маршрутизатор-маршрутизатор адресованы адресами RFC 1918, сообщения протокола управляющих сообщений Интернета (ICMP), генерируемые маршрутизатором, будут приходить с адреса RFC 1918. Сети, фильтрующие входящие пакеты с исходными IP-адресами RFC 1918 или использующие одноадресную пересылку обратного пути (uRPF), скорее всего, будут отбрасывать эти пакеты, нарушая TCP для этих приложений. Это приведет к тому, что передача больших пакетов по TCP-соединению не будет полностью завершена или будет выполняться неоптимально.
Короче говоря, здесь есть несколько сетевых проблем, из-за которых сайт будет недоступен для многих или большинства пользователей Интернета.
Возможными проблемами могут быть MTU, а также проблемы с маршрутизацией, поскольку вы можете открывать адреса через ссылки или скручивать, проблема может быть связана с MTU.
Чтобы проверить MTU, вам нужно использовать команду ping для проверки правильности Path MTU и вручную установить правильный MTU для вашего сетевого адаптера. также вы можете использовать Change-MSS в своих iptables, чтобы исправить эту проблему, я пытаюсь объяснить оба решения:
для проверки MTU попробуйте пропинговать пункт назначения с помощью следующей команды:
ping -M do -s 1472 <ip address>
аргумент -s устанавливает размер пакета ping, вы можете изменять это значение (обычно уменьшать), пока не обнаружите значение при этом ping, что ваши пакеты начинают фрагментироваться. затем добавьте к этому значению 28 байтов (размер заголовка ping), и это будет ваш размер PMTU. вы также можете использовать tracepath открыть для себя PMTU.
затем вы должны установить правило iptables, чтобы установить размер MSS пакетов изменения в соответствии с размером MTU вашего пути.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss <PMTU size>
вы также можете использовать --clamp-mss-to-pmtu чтобы попросить iptables автоматически проверять PMTU:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Это все, что я могу сказать прямо сейчас, надеюсь, это поможет
P.S. Вы используете TProxy для прозрачного прокси?