[sdnog] Force client to use HTTP proxy

[Kabantsh Alameen]

Thank you very much, I'll check it out.

On Mon, 14 Jan 2019, 16:36 Nishal Goburdhan <nishal at controlfreak.co.za
wrote:

> On 12 Jan 2019, at 1:08, Kabantsh Alameen wrote:
>
> > i've already done that (having two interfaces one for traffic and the
> > other
> > for management each is separate VLAN ).
> > Why ?? this proxy i am using is supporting both HTTP and HTTPS.
> > in my case i have no other solution.
> >
> > Thank you very much and i will do my research on the tool that you
> > gave to
> > me.
>
> what i meant, was that you want to have one interface for incoming (from
> your network) traffic;  ie.  pre-wccp-inspect, and another for
> post-wccp-inspect.
> sorry, i wrote that badly, so let me try to explain.  it’s been a
> while since i had to do this, but wccp is applied on an interface.  so
> basically, you’d want something like:
> your network  -> internal gateway -> wccp inspect sends this to cache
> farm on a different vlan -> cache-farm sends it to external router
> (using cache’s SRC_IP) -> router to internet … etc.
> and the return packet, which is now destined for your cache’s IP
> address will go:
> internet -> border router -> cache farm -> cache looks up who the
> original request came from -> internal router -> your network
> so, your cache-farm becomes a “service vlan” off onto one side of
> your network.  if something happens to the cache-farm, disable wccp, and
> everything passes straight to the internet.  no mucking around with
> client machines, changing proxies, etc.
>
> on a cisco, it (used to be) best to apply this _inbound_ to an
> interface, because that means that the router will “touch” the
> packet for operations fewer times.  i guess it largely depends on your
> gear.
>
> caching https is trickier.  it’s technically encrypted, so if you want
> to cache this, you’re going to have to decrypt and re-encrypt.
> that’s certainly possible today  :-)  but there’s a larger question
> about whether it’s ethical, or not.
> for example, to cache https://www.example.com, you’d have to pretend
> that your cache is actually www.example.com;  that’s effectively a
> man-in-the-middle attack.  you might get away with this, at a corporate,
> where it’s the policy that “anything done on a work computer is
> liable to be inspected by the IT director”  but at an ISP .. well,
> that’s not something that’s going to cause your customers to trust
> you.
> example.com is innocuous;  what if you tried to cache my internet
> banking?
>
> your choice - either way, whatever you do, make sure you have a policy
> to support it.
>
>
>
> On 12 Jan 2019, at 1:12, Kabantsh Alameen wrote:
>
> > And if i need to scale horizontally i will configure an HTTP/HTTPS
> > load
> > balancer such as HAProxy using my current IP as a virtual IP for the
> > load
> > balancer.
> > Thank you again for your help. 😍
>
> no, there’s no need for a load-balancer.
> the router(s) and cache(s) sets up identifiers between themselves, so
> you can have multiple caches performing with multiple routers (because,
> you want redundancy, right?).  i _think_ the caveat was that they needed
> to be in the same network for each service (ie. web-caches would be in
> one vlan;  ftp-caches in another, etc).  but honestly, it’s been a
> decade since i last had to play with this, so you’re actually better
> off searching for what your hardware can support, and testing this out.
> wccp is an ietf standard, so although there might be some vendor
> uniqueness, it should Just Work.  if you run into problems, feel free to
> ask on-list.
>
> —n.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sdnog.sd/pipermail/sdnog/attachments/20190115/c4d4e60c/attachment.html>