slackwaree(slackwa...@protonmail.com) on 2019.06.26 13:11:19 +0000: > 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
just run ifconfig lo3 inet 127.0.0.1/8 rdomain 3 route -T3 add 127/8 127.0.0.1 and you will get # route -T3 -n show Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface 127/8 127.0.0.1 UGS 0 0 32768 8 lo3 127.0.0.1 127.0.0.1 UHhl 1 2 32768 1 lo3 Internet6: Destination Gateway Flags Refs Use Mtu Prio Iface ::1 ::1 UHl 0 0 32768 1 lo3 fe80::1%lo3 fe80::1%lo3 UHl 0 0 32768 1 lo3 ff01::%lo3/32 fe80::1%lo3 Um 0 1 32768 4 lo3 ff02::%lo3/32 fe80::1%lo3 Um 0 1 32768 4 lo3 > 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 <cje...@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.brombac...@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 cje...@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 > > --
