On 26/11/2022 11:49 pm, N wrote:
Hi,
I'm trying to use tcp_outgoing_address to forward traffic from
specific users to a specific interface.
running squid 5.7 (on openwrt).
have a few interfaces on my machine, two of which are VPN interfaces
with IPs (internal) 10.200.0.70 and10.102.237.50.
trying to forward user "uk" to the interface with IP 10.200.0.70 is
"ignored" - I can see that the default WAN interface is used. I see it
by using a simple "what is my ip" test when using the proxy, and
checking the traffic of the interfaces when sending requests.
the relevant excerpt from the squid conf:
acl auth_users proxy_auth REQUIRED
First possibility:
Authentication is a VERY slow process. It is definitely not reliable
to trigger during a 'fast' type ACL check like tcp_outgoing_* directives.
To fix this you need to ensure authentication is performed in
http_access or similar early 'slow' access control directive. eg.
http_access deny !auth_users
Squid can then access the username with a 'note' type ACL check like so:
acl wg_uk note user uk
acl wg_uk proxy_auth uk
tcp_outgoing_address 10.200.0.70 wg_uk
I can see that the IP and config are not wrong because the requests
don't get 503 errors (if I change the IP to a non existing one, e.g.
10.200.0.71 I do get 503 errors).
The log snippet looks like Squid is correctly obeying your configuration:
small excerpt from the squid_cache.log (proxy server is 192.168.1.1,
proxy client is 192.168.1.149)
2022/11/26 11:28:48.286| 17,3| FwdState.cc(394) Start:
'http://detectportal.firefox.com/canonical.html'
2022/11/26 11:28:48.286| 17,2| FwdState.cc(157) FwdState: Forwarding
client request conn157 local=192.168.1.1:3128
<http://192.168.1.1:3128> remote=192.168.1.149:64723
<http://192.168.1.149:64723> FD 13 flags=1,
url=http://detectportal.firefox.com/canonical.html
To be clear, the above are about the client<->Squid connection which
triggered this outbound request.
...
2022/11/26 11:28:48.287| 14,4| ipcache.cc(647)
ipcache_nbgethostbyname_: ipcache_nbgethostbyname: HIT for
'detectportal.firefox.com <http://detectportal.firefox.com>'
2022/11/26 11:28:48.287| 14,7| ipcache.cc(250) forwardIp: 34.107.221.82
2022/11/26 11:28:48.287| 28,5| Acl.cc(124) matches: checking wg_uk
2022/11/26 11:28:48.287| 28,3| Acl.cc(151) matches: checked:
tcp_outgoing_address 10.200.0.70 = 1
2022/11/26 11:28:48.287| 28,3| Checklist.cc(63) markFinished:
0x7ffd71e3d440 answer ALLOWED for match
2022/11/26 11:28:48.287| 44,2| peer_select.cc(1171) handlePath:
PeerSelector27 found conn167 local=10.200.0.70 remote=34.107.221.82:80
<http://34.107.221.82:80> HIER_DIRECT flags=1, destination #1 for
http://detectportal.firefox.com/canonical.html
As you can see Squid MAY select to use a connection where the local= IP
is your configured tcp_outgoing_address ...
...
2022/11/26 11:28:48.288| 14,7| ipcache.cc(250) forwardIp:
[2600:1901:0:38d7::]
2022/11/26 11:28:48.288| 44,7| peer_select.cc(1149)
interestedInitiator: PeerSelector27
2022/11/26 11:28:48.288| 44,2| peer_select.cc(1171) handlePath:
PeerSelector27 found conn168 local=[::] remote=[2600:1901:0:38d7::]:80
HIER_DIRECT flags=1, destination #2 for
http://detectportal.firefox.com/canonical.html
... or it also MAY select IPv6 which you did not configure any
particular address for.
In accordance with with BCP 177 specifications Squid prefers IPv6 when
possible setting up new connections.
This can also be impacted by "happy eyeballs" timing and whether there
is an existing open connection on either of those two routes to the server.
So it is most likely that the IPv6 was chosen when you see the "not
working" behaviour with 10.200.0.70 address, and the IPv4 is chosen when
you saw the 503 errors in the 10.200.0.71 tests.
Try adding tcp_outgoing_address for IPv6 first and see if the problems
disappear completely.
The log shown stops before showing which of the two connections were
actually used, so there may be additional problems later. If they remain
we will need more log info to tell what is going on. Including the debug
11,2 trace of a non-working transaction would help.
Cheers
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
