0

I have two segments of enterprise network - green (with access to the Internet) and red (internal network). So, it works like this: Internet ↔ Green ↔ Red.

Each of two segments has it's own pack of Red Hat Fuse, Red Hat AMQ (or ActiveMQ), Apache Camel - let's call this pack 'Suite' for simplicity. This suite is the same in both segments and used for integration. All traffic between Green and Red is passed through Suite-Suite pair. Suite on one end receives traffic, packs it somehow, sends through the message broker (AMQ), and then suite on the other side unpacks it and sends it to the desired node. So, Suite-Suite is used like some kind of firewall and isolation/inspection software.

Sadly for general traffic transfer case, Suite-Suite transfer is a requirement. I know it hurts performance and it's not not elegant.

The question is: how can general-purpose TCP traffic (i.e., http and gRPC traffic) be wrapped by AMQ/ActiveMQ and be carried transparently between segments?

How can this communication be organized? For example, I think about putting traffic in something like SOCKS5 tunnel, and then wrapping SOCKS5 traffic for AMQ (by converting it to AMQP or alike).

I also know that one can write connectors for AMQ with Apache Camel, so it can be done like this: Traffic ↔ Interceptor ↔ Suite ↔ AMQP or other AMQ-AMQ protocol ↔ Suite ↔ Decoder & Sender ↔ Traffic.

Mixo123
  • 71
  • 1
  • 8
  • 1
    Since you have Red Hat AMQ and given that [Red Hat AMQ is not synonymous with ActiveMQ](https://stackoverflow.com/questions/52858270/what-is-the-difference-between-red-hat-amq-and-apache-activemq) could you use AMQ Interconnect in your solution? If so, maybe you could leverage this [AMQP-HTTP bridge](https://github.com/alanconway/envoy-amqp). – Justin Bertram Oct 21 '19 at 22:21
  • @JustinBertram, thanks for answering! I think we can use Interconnect, but it seems that aforementioned bridge doesn't support http/2 yet. – Mixo123 Oct 22 '19 at 09:32
  • 1
    I'm not sure if it supports HTTP/2 or not. However, it represents are large chunk of work that you'd likely have to reproduce in one form or another. You could very well just implement HTTP/2 support for the bridge rather that completely reinventing the solution. In any case, I think that something like Interconnect will be your best bet as I can't really imagine that turning HTTP frames into messages and mediating the sending/responding through a brokered queue will be straight-forward to implement or provide reasonable enough performance so as to be functionally viable. – Justin Bertram Oct 22 '19 at 16:09
  • 1
    I think Skupper (https://skupper.io/) is worth checking out. It's geared toward Kubernetes, but the components it uses could be adapted to work without it. Skupper uses Interconnect (Qpid Dispatch Router) to form a network between sites, and then proxies at each site convert HTTP (including HTTP/2) or TCP to AMQP and back. – Justin Ross Oct 23 '19 at 23:35
  • @JustinRoss, wow, that looks promising! May you please point to the relevant component in Skupper? I've come across https://github.com/skupperproject/skupper-proxy -- are you referring to it? – Mixo123 Oct 24 '19 at 05:35
  • 1
    Yes, I'd start looking at skupper-proxy. I haven't tried to use Skupper without Kubernetes, so I'm not sure what hurdles you'll find there, but architecturally, I think the proxy is the interesting component for you (plus an Interconnect network). Alternatively, you could try it out using Kubernetes first just to get a sense of what it does. – Justin Ross Oct 24 '19 at 11:31

0 Answers0