V2: Equivalent of v1 realip plugin

Help
1

1. My Caddy version (caddy version): v2

2. How I run Caddy:

official docker image

a. System environment:

Ubuntu 19.10

I’m just wondering if there is a v2 equivalent for the realip plugin. In v1 I used to use realip cloudflare in my caddyfile and I’d like to keep that functionality in v2.

2

Caddy v2 doesn’t have many modules (new name for plugins) created for it yet. The v1 realip plugin is from here: GitHub - captncraig/caddy-realip: Real-IP middleware for caddy

If you want to give a shot at porting it yourself, read this: Extending Caddy — Caddy Documentation

3

Or, should we just make it possible to modify req.RemoteAddr from the rewrite handler?

4

Feels like it should be like rewrite_header or something, rewrite is really a path thing.

@uchagani what we’re talking about is the possibility of obsoleting the realip plugin with something like:

@whitelistSources {
    remote_ip 1.2.3.4/32
}
rewrite_headers @whitelistSources {
    RemoteAddr {http.request.header.x-forwarded-for}
}

This is completely pseudo-caddyfile, not a thing yet.

5

honestly i’m okay with anything that accomplishes the below purpose. I’m not familiar with caddy v2 well enough to say yay or nay to any particular way to do things.

This plugin allows you to see the actual client IP from X-Forwarded-For headers if you are running behind a CDN or Proxy. It will make it so logs and other downstream directives will see the actual client IP, not the proxy’s. Implements security measures so that X-Forwarded-For cannot be spoofed from unauthorized IP ranges.

6

Do we think it’s a common enough occurrence for us to have a directive in the v2 Caddyfile specifically for this, like strip_suffix et al?

Could be something like realip [header...] where it by default pulls from X-Real-IP, else X-Forwarded-For, or you can override it with a header list to check sequentially and use the first one with an IP.

7

I guess. It’s super simple, but it’s up to @matt if he’s willing to have it in core.

Probably the most controversial thing in the v1 plugin from having it in core I’d say is the provider placeholders like cloudflare. I don’t think it’s a huge ask to just let users manage that themselves in their Caddyfile with a snippet or something for the matcher.

1 Like
8

Yeah, once we talk provider specific IP whitelists and such it really doesn’t seem worth it, just different syntax over maybe one or two lines fewer. So maybe not a directive. Your pseudo Caddyfile looks good.

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.