Hello,
Well this is not so simple as it looks but I have made success with traceroute.
route -T1 exec '/usr/sbin/traceroute' -n
route -T2 exec '/usr/sbin/traceroute' -n
route -T3 exec '/usr/sbin/traceroute' -n
Goes out on proper gateways so it works.
For Squid things gets a little bit more complicated.
For example I use squidguard which is spawned by squid so I don't know if the alternative routing table applied to this as well.
|-+= 03951 root /usr/local/sbin/squid
| \--- 06369 _squid (squid-1) --kid squid-1 (squid)
When I start squid I get:
route -T3 exec '/usr/local/sbin/squid'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
2019/06/26 14:50:35| ERROR: Directive 'url_rewrite_concurrency' is obsolete.
2019/06/26 14:50:35| WARNING: url_rewrite_concurrency upgrade overriding url_rewrite_children settings.
I see that this might be an issue of the loopback not being present on that table so I have added:
route -T3 add -net 127.0.0.0/8 127.0.0.1
route -T3 add -host localhost localhost
route -T3 show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 192.168.10.252 UGS 0 5 - 8 vio0
127/8 localhost UGS 0 1 32768 8 lo0
localhost localhost UGHS 0 0 32768 8 lo0
IPV4 I don't need.
Maybe I did not add the localhost correctly?! since if I compare this with the main routing table I see different flags:
127/8 localhost UGRS 0 0 32768 8 lo0
localhost localhost UHhl 3 98 32768 1 lo0
Anyway Squid starts with the mentioned warnings but any request I try to make through it hangs.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, June 24, 2019 11:07 AM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> On Mon, Jun 24, 2019 at 08:47:38AM +0000, slackwaree wrote:
>
> > Hello,
> > Could you maybe provide a full case study for this as it is fairly
> > uncommon task?
> > Do you mean that I will also need +2 ip aliases next to the boxes main ip?
>
> No. You can use either option. The question is how are the proxy users
> talking to those 3 different proxies? If you want to use port 8080 for all
> of them you want 3 different IPs.
>
> > Eg instead of
> > 192.168.10.1: 3128 3129 3130
> > 192.168.10.1:3128 using gateway 192.168.10.250
> > 192.168.10.2:3128 using gateway 192.168.10.251
> > 192.168.10.3:3128 using gateway 192.168.10.252
>
> Try it out yourself. Create an extra table and run a proxy in it.
> Use tools like tcpdump, nc, etc to check if it works.
>
> Start with:
> route -T1 add default 192.168.10.250
> route -T1 exec "squid command to run ideal with debugging on"
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> :wq Claudio
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, June 21, 2019 8:27 PM, Brian Brombacher brian.brombacher@planetunix.net wrote:
> >
> > > You'll also need PF rules to allow incoming traffic from your squid clients to go to the routing table where your squid process is running.
> > >
> > > > On Jun 21, 2019, at 10:28 AM, Claudio Jeker cjeker@diehard.n-r-g.com wrote:
> > > >
> > > > > On Fri, Jun 21, 2019 at 02:11:53PM +0000, slackwaree wrote:
> > > > > Hello,
> > > > > I wonder if the following scenario can be solved with OpenBSD on 1 single machine or with VMM:
> > > > > I got 3 OpenBSD vms, all of them are exactly the same running squid except they use different default routers to route their traffic out.
> > > > > I would like to merge these to one VM if it is possible somehow to tell OpenBSD to use different gateway depending on the squid process.
> > > > > If not would the same thing be possible with VMMs? All the gateways are in the same IP range.
> > > >
> > > > A simple way to solve this is with multiple routing tables.
> > > > Create multiple routing tables with:
> > > > route -T1 add default <gw1>
> > > > route -T2 add default <gw2>
> > > > route -T3 add default <gw3>
> > > > And start the 3 squid processes with route -T1 exec, route -T2 exec.
> > > > You can also use the the *_rtable variable in rc.d(8) to do that
> > > > automatically.
> > > > This requires that the 3 squids listen on different IPs or ports.
> > > >
> > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > > >
> > > > :wq Claudio
No comments:
Post a Comment