Squid TPROXY接続が特定のサイトで失敗しますか？
SquidをTPROXYとして設定すると、一部のサイトでERR_CONNECT_FAILが返されます。 squidが実行されているサーバーは、lynx、wget、curlなどでこれらのサイトを開くことができます。ブラウザで手動でプロキシを設定したり、単純なREDIRECTまたはDST-NATを使用したりしても、これらのサイトが開く可能性があります。
このページから http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
パスMTU（PMTUD）が失敗し、一部のリモートサイトにアクセスできなくなる可能性があります。クライアントマシンがイーサネットまたはDSLPPPoATMを介して接続されていて、キャッシュとクライアント間のすべてのリンクのMTUが1500以上の場合、これは通常問題にはなりません。クライアントがDSL PPPoEを介して接続している場合、PPPoEリンクのMTUが低下することが多いため、これは問題になる可能性があります（1472が非常に一般的です）。
しかし、私はイーサネットで同じ問題を抱えています
1つのクライアントからのtcpdumpは次のとおりです。
tproxyを使用して問題が発生した場合、tcpdumpを表示するにはここをクリックしてください
そして
ブラウザでプロキシを手動で設定し、すべてが正常に機能する場合のtcpdumpを表示するには、ここをクリックしてください
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 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/SystemWeirdnesses#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
注：インターネットプロバイダーへの接続は、MTU1476のGREトンネルを介して行われます。
指定した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ルールを貼り付けることができれば便利です。
Unixエラー110は、「接続がタイムアウトした」ことを意味します。リモートサイトは要求に応答しませんでした。
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
さらに悪いことに、誰かがこのパスでパブリックインターネット上のRFC1918アドレスを使用したように見えます。特に、これによりパスMTUディスカバリーが切断されます。つまり、多くのTCP接続も切断されます。
1つのソースから引用すると、 CiscoのIPアドレス指定のベストプラクティス（PDF） ：
パブリックアドレスを使用してネットワークのエリアに接続するルーター間リンクは、パブリックIPアドレスでアドレス指定する必要があります。プライベートアドレスのみを使用し、引き続き使用するネットワークの特定の領域にサービスを提供するルーターは、ルーター間リンクでプライベートアドレスを使用できます。
この要件により、パスMTUディスカバリー（RFC 1191）が正しく機能することが可能になります。ルーターは「packet-too-big」エラーを送信できる必要があり、パケットが元の送信元ホストに到着する可能性が高いことを確認する必要があります。ルータ間のリンクがRFC1918アドレスでアドレス指定されている場合、ルータによって生成されるインターネット制御メッセージプロトコル（ICMP）メッセージはRFC1918アドレスから送信されます。 RFC 1918送信元IPアドレスを使用して、またはユニキャストリバースパス転送（uRPF）を使用して着信パケットをフィルタリングするネットワークは、これらのパケットをドロップし、これらのアプリケーションのTCPを壊します。これにより、大きなパケット転送が発生します。 a TCP接続が完全に失敗するか、最適に実行されない。
要するに、ここには複数のネットワークの問題があり、多くのまたはほとんどのインターネットユーザーがサイトにアクセスできなくなります。
リンクを介してアドレスを開いたり、MTUに関連する問題をカールしたりする可能性があるため、考えられる問題はMTUおよびルーティングの問題である可能性があります。
MTUを確認するには、pingを使用して正しいパスMTUを確認し、ネットワークアダプターに正しいMTUを手動で設定する必要があります。また、iptablesでChange-MSSを使用して、この問題を修正することもできます。両方の解決策を説明してみます。
mTUチェックの場合は、次のコマンドを使用して宛先にpingを実行してみてください。
ping -M do -s 1472 <ip address>
-s引数は、pingパッケージのサイズを設定します。pingの値がパッケージの断片化を開始するまで、この値を変更（通常は減少）できます。次に、この値に28バイト（pingヘッダーサイズ）を追加します。これがPMTUサイズです。 tracepathを使用してPMTUを検出することもできます。
次に、iptablesルールを設定して、パスMTUサイズに応じたMSSサイズの変更パケットを設定する必要があります。
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を使用していますか？