A conexão do Squid TPROXY falha em sites específicos?

Question

Quando a configuração do squid como TPROXY, retorna ERR_CONNECT_FAIL em alguns sites. O servidor que o squid executa nele é capaz de abrir esses sites por lynx, wget, curl etc. Mesmo se definirmos manualmente o proxy no navegador ou usarmos REDIRECT simples ou DST-NAT, esses sites poderão ser abertos.

A partir desta página link

It causes path-MTU (PMTUD) to fail, possibly making some remote sites inaccessible. This is not usually a problem if your client machines are connected via Ethernet or DSL PPPoATM where the MTU of all links between the cache and client is 1500 or more. If your clients are connecting via DSL PPPoE then this is likely to be a problem as PPPoE links often have a reduced MTU (1472 is very common).

Mas eu tenho o mesmo problema com o ethernet

Aqui está o tcpdump de um cliente:

Clique aqui para ver o tcpdump quando eu uso o tproxy e o problema aparece

e

Clique aqui para ver o tcpdump quando eu definir manualmente o proxy no meu navegador e tudo funciona bem

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

ping -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 fazer

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 fazer

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 *

tracepata 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

Também experimentamos estes passos link

Eu não sei relacionado ou não, mas também tenho as seguintes configurações

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

e ativado / desativado após

#echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
#echo 0 > /proc/sys/net/ipv4/tcp_ecn

Aqui estão as regras de rota 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

Observação: a conexão com provedores de internet é feita através do GRE Tunnel com o MTU 1476.

    

Answer 1

Da saída tcpdump que você forneceu, as linhas a seguir indicam um problema, ou seja, seu host envia um SYN para o destino e envia um RST para o destino também, mas TTLs ofcourse são diferentes, então parece que alguns TPROXY mágica acontecendo:

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

Não parece um problema de MTU. Para começar com a solução de problemas, sugiro remover TPROXY (supondo que você esteja usando isso) e alternar para a regra baseada em REDIRECT e ver se o problema desaparece. Seria útil se você pudesse colar suas regras REDIRECT ou iptables relacionadas.

    

Answer 2

O erro 110 do Unix significa "Tempo limite da conexão esgotado". O site remoto nunca respondeu à solicitação.

Quando tentei alcançar o 80.75.1.4, também não consegui alcançá-lo. Aparece de ping e traceroute que há uma perda significativa de pacotes na rede depois que ela entra no estado do Irã. Provavelmente é por isso que o site não está respondendo.

$ 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

O que é pior, parece que alguém usou endereços da RFC 1918 na Internet pública nesse caminho. Entre outras coisas, isso faz com que a descoberta do Path MTU seja interrompida, o que significa que muitas conexões TCP também serão interrompidas.

Para citar uma fonte, Práticas recomendadas de endereçamento IP da Cisco (PDF) :

Any router-to-router links connecting to areas of the network with public addressing should be addressed with public IP addresses. Routers serving specific areas of the network using and continuing to use only private addresses may use private addresses on the router-to-router links.

This requirement enables and helps ensure that path MTU discovery (RFC 1191) works properly; routers must be able to send "packet-too-big" errors and must be assured that the packets are likely to arrive at the original source host. If router-to-router links are addressed with RFC 1918 addresses, the Internet Control Message Protocol (ICMP) messages generated by the router will come from an RFC 1918 address. Networks filtering out incoming packets with RFC 1918 source IP addresses, or using unicast reverse path forwarding (uRPF), will likely drop these packets, breaking TCP for those applications. This will cause large packet transfer across a TCP connection to fail completely or perform suboptimally.

Em suma, há vários problemas de rede aqui que farão com que o site fique inacessível para muitos ou a maioria dos usuários da Internet.

    

Answer 3

Os problemas persistentes podem ser MTU e também problemas de roteamento, pois você pode abrir endereços via enlaces ou enrolar o problema relacionado a MTU.

Para verificar a MTU, você precisa usar o ping para verificar a MTU de caminho correta e definir manualmente a MTU correta para o seu adaptador de rede. você também pode usar o Change-MSS no seu iptables para corrigir este problema. Eu tento explicar as duas soluções:

para checagem de MTU tente pingar o destino com o seguinte comando:

ping -M do -s 1472 <ip address>

o -s argeument configura o tamanho do pacote ping você pode alterar este valor (normalmente diminuir) até você achar que o valor naquele ping seus pacotes começam a ser fragmentados. em seguida, adicione 28 bytes (tamanho do cabeçalho de ping) a esse valor e esse é o tamanho de seu PMTU. você também pode usar tracepath para descobrir o PMTU.

então você deve definir uma regra iptables para definir o tamanho do MSS dos pacotes de mudança de acordo com o tamanho do MTU do seu caminho.

 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss <PMTU size>

você também pode usar --clamp-mss-to-pmtu para pedir que o iptables verifique automaticamente a PMTU:

 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Isso é tudo que posso dizer agora, espero que ajude

P.S. Você usa o TProxy para proxy transparente?