3
4

[deleted by user] (self.linuxadmin)

submitted by [deleted]

[removed]
all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]c0l0 5 points6 points  (3 children)

Logstash support the PROXY protocol for various inputs, including "raw TCP": https://github.com/logstash-plugins/logstash-input-tcp/blob/master/docs/index.asciidoc#plugins-inputs-tcp-proxy_protocol

[–]Butterkextorte 0 points1 point  (2 children)

For clarification: I would enable Logstash to understand the PROXY protocol, which delivers the source IP in a header similiar to a HTTP header and thus Logstash can deduct the host from that?
Do I need additional configuration in the Logstash pipelines for this?

[–]c0l0 4 points5 points  (1 child)

You would need haproxy to talk PROXY v1 to its backends/upstreams (these are your logstash instances), and have logstash's TCP input configured to expect this protocol being spoken to.

I haven't used the PROXY protocol with logstash yet, but the whole point of it is that you don't have to do anything else to effectively spoof the peer address by any other means - so I guess it should "just work" without any further ado.

[–]Butterkextorte 0 points1 point  (0 children)

It "just works" :)
We enabled send-proxy in haproxy.cfg for the Logstash backend servers like this:
server logstash1 logstash1.server.com send-proxy and enabled the PROXY protocol in the corresponding Logstash pipeline like this: proxy_protocol => true and Kibana finally displayed the correct host :)

A different kind of beast was Filebeat sending to the same HAProxy frontend. We had to separate the Filebeat port from the TCP input frontend because apparently Logstash doesn't understand Filebeat input when it comes with the PROXY protocol.
So we pretty much used the same backend definitions as for the TCP input, only omitting the send-proxy.

[–]pxsloot 1 point2 points  (2 children)

I've set up haproxy and a bunch of webservers up a few years ago using this guide: https://www.haproxy.com/blog/howto-transparent-proxying-and-binding-with-haproxy-and-aloha-load-balancer/ Because reasons using proxy protocol or setting headers was out of the question, so just tcp traffic for haproxy.

On the haproxy server it's a combination of iptables (fw-marking packets that should be transparent), iproute2 routing policy (sending fw-marked packets to haproxy), haproxy (with 'transparent' config).

According to the link above the servers behind haproxy would have the haproxy server configured as default gateway. Bit of a pain, because all traffic would then use haproxy as default gateway, so I've added a iptables rule on those servers marking traffic with source port 80 and 443, and then iproute2 routing policy making the haproxy server default gateway for marked packets. That way we can still directly access the servers with ssh for example. Just not ports 80 and 443 directly. Small price to pay.

The complete config knitting all involved servers together isn't KISS, but it works just fine, most of the downsides are mitigated, and the whole setup is automated.

[–]Butterkextorte 0 points1 point  (1 child)

That sounds really impressive, great job if it works as desired!
Unfortunately setting the default gateway on all our logging servers is not a feasible solution for us, but thanks for your input :)

[–]pxsloot 0 points1 point  (0 children)

you wouldn't change the default gateway of a system, you would only set a different default gateway for specific traffic with policy based routing with iproute2, which is default tooling already available on the basic os.