On 08/06/11 22:53, Ali Majdzadeh wrote:
Amos,
Hi
Thanks for your reply. The Squid box has only one NIC and it is
connected to the internet via it's default gateway, I think I should
have corrected our network diagram as follows:
Internet<-> Gateway<-> Squid<-> Clients
Does this configuration make any difference?
That diagram is no different, but a 1-NIC squid box would be:
Internet<->Gateway<->Clients.
\<->Squid
or:
Internet<->Gateway<--switch-->Clients.
\<->Squid
That makes a difference.
If you bump cache.log up to ALL,5 during a test connection. You may see
traffic arrive but then hang while connecting out.
If you do see that behaviour in cache.log, the problems is at the
gateway end. It MUST be able to detect and bypass the Squid outward
traffic by MAC address or tcp_outgoing_tos instead of IP address.
Amos
Thanks again for your reply. I will try to reconfigure the whole
solution from scratch to find out where I go wrong.
Warm Regards,
Ali Majdzadeh Kohbanani
2011/6/8 Amos Jeffries<squ...@treenet.co.nz>:
On 08/06/11 01:15, Ali Majdzadeh wrote:
Amos,
The configuration is as follows:
Internet<-> Squid<-> Clients
Would you please clarify what you mean by declaring "routing packets
to the squid box"?
That the packets actually do get passed/routed through the squid box and not
via some other possible route.
Does the above configuration conform to the
so-called declaration?
If those are physical wires or even just logical routing table entries, yes
it does.
If it is so, what should be done to solve the
issue?
Your packet counter incrementing is a good sign that the ruting layer is
okay.
Thanks again.
By the way, we have compiled libcap from source and it is the latest
version of the library.
Okay. That should do :).
2011/6/6 Ali Majdzadeh<ali.majdza...@gmail.com>
Amos,
Sorry, the packet counter increments, I made a mistake, but still no
logs either in access.log nor in cache.log.
Given that you have a recent libcap. That means we must suspect the kernel
handling once TPROXY marks the packets.
The "table 100" bit of the config has given a lot of people trouble. AFAIK
"normally" you only have one such table entry and for TPROXY its internal to
the kernel with the "lo" interface. BUT, some people have had to configure
other interfaces to get it working.
Try to add a table 100 (or whatever you called it) entry for each NIC the
box has. If your kernel accepts them check access.log again.
If your kernel denies multiple tables, erase the existing one and try
creating one for each NIC. Repeating until you find one that works.
OR, if that still fails. We have to get help from Balabit and/or Netfilter
and figure WTF is happening.
Amos
Warm Regards,
Ali Majdzadeh Kohbanani
2011/6/6 Ali Majdzadeh<ali.majdza...@gmail.com>:
Amos,
Hi
The packet counter on -j TPROXY does not increment. So, why clients
are able to surf the web?
Warm Regards,
Ali Majdzadeh Kohbanani
2011/6/6 Ali Majdzadeh<ali.majdza...@gmail.com>
Amos,
Hi
Thanks for your reply. Ragarding the documentation, I have inserted
the following routing rules:
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
Now, access.log is populated with proper logs, but clients can not
surf the web, I mean the proxy server is unable to forward http
responses to clients' browsers. When the client enters for example
www.google.com, the connection to the http server is established but
the process halts at Waiting for www.google.com and after a while
Squid reports the unablility to retreive the requested URL.
By the way, we have disabled selinux.
Any ideas?
Warm Regards,
Ali Majdzadeh Kohbanani
2011/6/6 Amos Jeffries<squ...@treenet.co.nz>:
On 06/06/11 06:32, Ali Majdzadeh wrote:
Hello All,
I have setup the following configuration:
Squid (3.1.12) (--enable-linux-netfilter passed as the one and only
configure option)
Kernel (2.6.38.3)
iptables (1.4.11)
I have added the following two directives in squid.conf:
http_port 3128
http_port 3129 tproxy
Also, I have configured iptables with the following rules:
iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
--tproxy-mark 0x1/0x1 --on-port 3129
Everything work as expected, I mean, the users can surf the web and
the proxy server is transparent. The problem is that actually there
is
no caching. I mean, both cache.log and access.log files are empty. On
That would be transparency to the point of not going through the
proxy.
access.log should have entries for each request.
the other hand, if I manually set the proxy configuration in clients'
browsers (the IP address of the squid server and port number 3128)
everything is OK; the log files are incremented and objects are
cached.
Have anyone faced the same issue?
Some. Its usually boiled down to missing out some details omitted.
building
against libcap2 or routing packets to the squid box for example.
Are the packet counters on that -j TPROXY rule showing captures?
Did you follow the rest of the feature config?
ie the special sub-routing table? OS packet filtering toggles?
selinux
updated to allow tproxy?
Is this box even routing or bridging port 80 traffic for the network?
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
