z3bra @ wgs @lemmy.sdf.org

[z3bra.org](https://z3bra.org/)

---

Read more

Posts

17

Comments

214

Joined

2 yr. ago

This matrix is for features supported via ANSI escape codes.

I use Quake 3 characters names: doom, crash, sorlag, razor, bitterman, xaero, ...

Aussi intéressant qu'effrayant je dirais :)

For TCP/UDP traffic, you'd just move the problem on another box. The application logs would report connections from 127.0.0.1 (the local proxy), and not the client IP.

Depends on the service. What application are you running on the backend server ?

This is only true if the proxy can understand the application layer of the backend (eg. HTTP). For TCP/UDP based proxy, you only get "X connected to Y" type of logs, which isn't very useful to debug an application.

I think you meant to reply to another comment. I never talked about setting up NAT rules, neither source, nor destination.

The proxy is responsible for responding with the correct IP address as it terminates the connection. Setting up NAT rules is not needed.

Yeah it's definitely young and not for everyone. But you gotta start somewhere ! I do agree that the "shortcomings" are not explicitly defined, but rather implied in the FAQ.

Arguing over licences to judge how much a piece of software is worth is sterile IMO.

If you personally cannot use software that's not GPL'd, then it's fine. But there's no need to sound condescending like this, it brings absolutely nothing to the table. This could only result in a flame war (and it already is unfortunately, seeing the comments below), which is kind of sad.

So yeah, no prob mate, this is not for you, we get it. See you on the next thread 🫡

I already used alpine for a few years, before containers were a thing. I heard about it exactly because it was advertised as a distro without GNU components, which was revolutionary at the time.

You sound weary with that kind of comment, I wonder what bother you so much about seeing a new distro pop up ?

Spam Gourmet. The main feature is that for each alias you set the maximum number of emails to be forwarded before dumping them to /dev/null.

It's not about GNU being wrong or not, it's about having the choice.

Setting the default gateway to the VPN has many implications that you must take into account before doing it:

• you need to allow ALL traffic through the VPN ACL, which nullify the concept of ACL as a security measure.
• it breaks the VPN as the encapsulated packets cannot reach the other site. You need a /32 route to the other site to keep the VPN up.
• it will route ALL the internet traffic from this host through the VPN, and the internet access of the other site.
• it could break access to LAN of the server, so you might need to set your local routes manually.
• it can let your server access the LAN of the remote server, this leaking local networks.

A better option would be to use VRFs to route back traffic coming through the VPN back to it.

Short answer: Don't bother, it's too complex to setup (unless your app is HTTP or supports the PROXY protocol). You better read your proxy logs instead.

Long answer: What you want is called "IP transparency" and require your proxy to "spoof" the IP address of the client when forwarding packets to the remote server. Some proxies do it (Nginx plus, Avi Vantage, Fortinet) but are paid services. I don't know for free solutions as I only ever implemented it with those listed above.

This require a fairly complex setup though:

0. IP address spoofing

The proxy must rewrite all downstream request to spoof the client IP address, making it look like the traffic originates from the client at the TCP layer.

1. Backend server routing

As the packet will most likely originate from random IP on the internet, your backend server must have a way to route back the traffic to the proxy, instead of it's default gateway. Otherwise you'd implement what is called "Direct Server Return*, which won't work in your case (packet will be dropped by the client as originating from your backend server directly, and not from the proxy).

You have two solutions here:

• set your default gateway to the proxy over its VPN interface (don't do that unless you truly understand all the implications of such a setup)
• use packet tagging and VRF on the backend server to route back all traffic coming from the VPN, back to the VPN interface (I'm not even sure this would work with an IPsec VPN though because of ACL...)

3. Intercept and route back return traffic

The proxy must be aware that it must intercept this traffic targeted at the destination IP of the client as part of a proxied request. This require a proxy that can bind on an IP that is not configured on the system.

So yeah, don't do that unless you NEED to do that (trust me as I had to do it, and hated setting it up).

Edit: apparently haproxy supports this feature, which they call transparent mode

That's kind of the point though, as it's now used as a base for many containers ;)

I only learnt about it today, so I couldn't check it. I have this project of building my own distro using musl and a non GNU userland, and it is a very annoying process, so I felt like I should share this one.

That's right ! It uses BusyBox as its userland which was my main problem with it (though you can easily install GNU coreutils).

tl;dr: attackers use open recursive DNS resolvers to amplify DDoS attacks.

Thanks for the link, I didn't know about this technique. It only applies to recursive DNS though, not authoritative ones.

Your first link doesn't return a single result :(

Windows does DNS cache by default, so it could be that many domains are still in your local cache. First change your DNS settings, then clear the cache with ipconfig /flushdns.