On 7/03/2013 7:22 p.m., Amm wrote:
----- Original Message -----
From: Amos Jeffries
On 7/03/2013 5:30 p.m., Amm wrote:
----- Original Message -----
From: Amos Jeffries
On 7/03/2013 2:03 a.m., Amm wrote:
I just tried 443 port interception with sslbump and is working
perfectly.
If sslbump none applies for request then it passes requests as
is:
Log shows something like this:
1362574305.069 90590 192.168.1.1 TCP_MISS/200 3600 CONNECT
23.63.101.48:443 - HIER_DIRECT/23.63.101.48 -
if sslbump server-first applied for request then log shows:
1362574001.569 294 192.168.1.1 TCP_MISS/200 515 GET
https://mail.google.com/mail/images/c.gif? -
PINNED/2404:6800:4009:801::1015
image/gif
(Note: URL may not be same in both cases, these are just example)
I dont have IPv6, why is it showing IPv6 address, in 2nd case?
Because you *do* have IPv6, or at least the Squid box does. And Squid
is
using it successfully to contact the upstream web server.
Amos
Nope I do not have IPv6. I have been begging my ISP to give IPv6.
I hear what you are saying. Yet your logs are showing successful IPv6 traffic.
Maybe they enabled it on the router without informing you. Or maybe someone else
on the network setup a IPv6 gateway router (PC running 6to4 and emitting RAs?).
I don't know.
Somehow Squid detected that global IPv6 connectivity was available and is doing
full TCP connection setup and HTTP transactions resulting in over 28KB of data
transferred over IPv6 so far.
Try these three tests:
ping6 mail.google.com
netstat -antup
mtr -n6 mail.google.com
Please trust me. I am a network engineer since about 15 years now. (Not trying to brag).
I also appreciate your efforts a lot for always replying.
But I do not have IPv6. The squid is running on my standalone laptop.(there is no LAN network)
# ping6 mail.google.com
connect: Network is unreachable
# mtr -n6 mail.google.com
gives EMPTY screen i.e shows nothing except headers.
# list IPv6 addresses
# ip -f inet6 addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
Hence, no interface has IPv6 except lo (loopback)
# list IPv4 addresses
# ip -f inet addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
7: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc htb state UNKNOWN qlen 3
inet 1.2.3.4 peer 1.2.3.4/32 scope global ppp1
PPP interface is ADSL connection and just has IPv4 address. ADSL router is in bridge mode.
Okay.
<snip>
NAT happening *into* Squid does not require IPv4 outbound. In cases like these
where the HTTP Host: header can be 100% validated as belonging to the
destination IP address Squid will use DNS to locate the upstream server. In this
case it locates the AAAA and uses it.
You can enable debug_options 11,2 to see the client and server HTTP transaction
IP addressing details.
I enabled debug.
For testing, URL was accessed with curl (curl -k https://www.google.com/)
Here is debug output: (Google IP has changed but in same subnet, 1.2.3.4 is my public IP replaced)
2013/03/07 11:40:46.326 kid1| client_side.cc(2325) parseHttpRequest: HTTP Client local=173.194.36.18:443 remote=1.2.3.4:50145 FD 21 flags=33
2013/03/07 11:40:46.326 kid1| client_side.cc(2326) parseHttpRequest: HTTP Client REQUEST:
---------
GET / HTTP/1.1
User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.5.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
Host: www.google.com
Accept: */*
----------
2013/03/07 11:40:46.326 kid1| http.cc(2177) sendRequest: HTTP Server local=1.2.3.4:50146 remote=173.194.36.18:443 FD 23 flags=1
2013/03/07 11:40:46.326 kid1| http.cc(2178) sendRequest: HTTP Server REQUEST:
---------
GET / HTTP/1.1
User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.5.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
Host: www.google.com
Accept: */*
Via: 1.1 a.b.c (squid/3.3.2)
X-Forwarded-For: 1.2.3.4
Cache-Control: max-age=259200
Connection: keep-alive
HTTP server REQUEST shows 173.194.36.18, but access.logs show IPv6 address:
1362636646.416 90 1.2.3.4 TCP_MISS/302 1138 GET https://www.google.com/ - PINNED/2404:6800:4009:802::1011 text/html
This is a really *really* strange outcome. It is indeed looking like a
code bug somewhere.
The cache.log showed the TCP level details being apparently correct. So
I think we can ignore everyting up to the point of logging.
Just to cofirm that can you add the server response trace from that
server request? It will be a short while later with identical local=
remote= and FD values.
If there is anything else on that FD 23 it would be useful to know as well.
If we assume there is someting terribly broken with where the access.log
data is being generate from.
Can you create a custom log format please which outputs:
logformat test %>A/%>a:%>p -> %>la:%>lp (%la:%lp) %<la:%<lp ->
%<A/%<a:%<p [%h{Host}]
and use it for a secondary access_log line. Lets see what gets logged by
that.
If it is still logging the IPv6. I have an experimental patch here:
http://master.squid-cache.org/~amosjeffries/patches/pinning_hier_note.patch
If you could apply that and see what the above log changes to it would
be great.
Cheers
Amos
