Em 28/11/2015 22:46, André Janna escreveu:
I took another network trace this time both at Squid and Windows
client ends.
cache.log:
2015/11/27 11:30:55.610 kid1| SECURITY ALERT: Host header forgery
detected on local=177.43.198.106:443 remote=192.168.64.4:61802 FD 5465
flags=33 (local IP does not match any domain IP)
------------------------------
network trace at Squid side
client connects
11:30:55.604870 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
seq 1701554341, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:30:55.604992 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:55.605766 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
ack 1, win 256, length 0
client sends SSL hello
11:30:55.606242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[P.], seq 1:198, ack 1, win 256, length 197
11:30:55.606306 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, length 0
client OS sends TCP keep-alive packets
11:31:05.607191 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:05.607231 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:15.608966 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:15.609005 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:25.614527 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:25.614589 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
client sends FIN
11:31:29.384280 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[F.], seq 198, ack 1, win 256, length 0
11:31:29.421787 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, length 0
client OS sends TCP keep-alive packets
11:31:39.417426 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:39.417489 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:49.425366 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:49.425443 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:59.426153 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:59.426233 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
.... it continues this way until I powered off Windows client after
three hours ...
------------------------------
network trace at Windows client side
client connects
11:30:34.894242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
seq 1701554341, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:30:34.898234 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:34.898298 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
ack 1, win 256, length 0
client sends SSL hello
11:30:34.898712 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[P.], seq 1:198, ack 1, win 256, length 197
11:30:34.899479 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, length 0
client OS sends TCP keep-alive packets
11:30:44.899271 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:30:44.899986 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:30:54.900495 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:30:54.901323 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:04.905731 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:04.906560 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
client sends FIN
11:31:08.675299 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[F.], seq 198, ack 1, win 256, length 0
11:31:08.713746 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, length 0
client OS sends TCP keep-alive packets
11:31:18.708086 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:18.708917 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:28.715600 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:28.716516 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:38.714887 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:38.716911 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
...
So after less then one minute after connection Windows client sent a
FIN and Linux server acknowledged.
Windows netstat showed that connection changed to FIN_WAIT_2 state
while Linux netstat showed that connection at Squid endpoint changed
to CLOSE_WAIT state.
# date; netstat -tno | grep 192.168.64.4
Fri Nov 27 11:32:13 BRST 2015
tcp6 1 0 172.16.10.22:3126 192.168.64.4:61802
CLOSE_WAIT off (0.00/0/0)
According to
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm in
this state the server IP stack is waiting for Squid to be ready to
close the connection.
After 3 hours from initial connection netstat state on client was
still FIN_WAIT_2 and on server was still CLOSE_WAIT.
So I powered off Windows laptop and waited 3 hours more but nothing
changed, connection remained in CLOSE_WAIT state and Squid didn't
release the file descriptor.
Fri Nov 27 18:22:25 BRST 2015
squid 2708 proxy 5465u IPv6 620209
0t0 TCP 172.16.10.22:3126->192.168.64.4:61802 (CLOSE_WAIT)
Regards,
André
I installed Squid 3.5.12 on another machine and got the same problem as
before.
Squid keeps using file descriptors for connections that have been in
CLOSE_WAIT state for hours.
My guess is that Squid doesn't release the file descriptor when
intercepts an https connection that triggers "local IP does not match
any domain IP" warning in cache.log.
Regards,
André
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
