Hi David,
I have a setup similar to what you describe.
I'm using wildcard LE cert though, so no way for acme-client.
Single IP, demuxing on relayd based on Host header, client requests to
servers with specified configurations go to appropriate local servers,
otherwise go to default httpd entry.
But not in transparent mode. Regarding X-Forwarded headers: note that
httpd does not log X-Forwarded-* and you'll have to deal with it
somehow. I have a patch for httpd, but since where was no interest in
this, I didn't submit it.
On 04/28, David Higgs wrote:
> On Sat, Apr 28, 2018 at 9:58 AM, Claudio Jeker <cje...@diehard.n-r-g.com>
> wrote:
> > On Sat, Apr 28, 2018 at 09:39:56AM -0400, David Higgs wrote:
> >> I run several services on the same host and would like to consolidate
> >> certificate management with the help of relayd.
> >>
> >> Before:
> >> - acme-client generates certificates via LE
> >> - kibana running https on port 5601
> >> - unifi running https on port 8443
> >> - httpd running http+https on port 80
> >> - daily.local script to install new certs and restart all services
> >> when LE updates
> >>
> >> After:
> >> - register new LE domains for kibana and unifi
> >> - switch kibana and unifi back to running http on localhost
> >> - relayd transparently terminates all https and demuxes to http
> >> service based on Host header
> >> - daily.local has much fewer services to manage
> >>
> >> First off, is this even possible with relayd?
> >
> > More or less. relayd does not do SNI so you need to have per hostname or
> > actually per certificate a different IP. Doing complicated rule based
> > relays is not working all that well. So try to keep it simple one port one
> > service.
>
> Single IP, one hostname per port (and thereby service) at 1:1
> correspondence. Hostnames will all be aliases on the same LE cert, so
> it seems like SNI is not a problem.
>
> >> Second, I am having difficulty grokking how to structure my
> >> relayd.conf. Will I need one relay and protocol block for EACH
> >> service? Do I need a pf.conf anchor if I am only using relay
> >> behavior?
> >
> > Depends. You may be able to just use one 'http protocol' block that is
> > referenced by multiple relays. It depends on the config.
> > I think the pf.conf anchor is required even if you are not using
> > redirects (I assume that relayd would even refuse to start without the
> > anchor).
>
> My pf.conf is a bit complex with tag usage, but I definitely wasn't
> using the pf anchor. (Not sure if this is a bug?)
>
> >> Lastly and perhaps indicative of my difficulties, I am having
> >> difficulty building (or debugging) even a single host as
> >> proof-of-concept using the config below. The relayd daemon starts
> >> just fine, loading symlinked <addr>.crt and <addr>.key files. (Should
> >> I be using the fullchain.pem instead?)
> >
> > Yes, you should use a full chain certificate else there is no trust anchor
> > for the clients.
>
> I was concerned that relayd might not grok PEM files - all the example
> use .crt extensions.
>
> >> Behavior seems to vary based on client / environment - I have seen
> >> both wget and curl complain about certificate verification (relaying
> >> to :80), while curl on a different box reported an empty reply from
> >> the server after timeout (relaying to 127.0.0.1:80).
> >>
> >> Hints or clue sticks would be most appreciated.
> >>
> >> --david
> >>
> >> ### relayd.conf
> >>
> >> http protocol wwwproto {
> >> tcp { nodelay, sack, socket buffer 65536, backlog 128 }
> >
> > Honestly most of this tuning is not helpful. sack and backlog may be OK
> > but esp. changing the socket buffer will disable the automatic socket
> > buffer scaling and leave you with a much smaller buffer then the default.
>
> I'm not concerned about scale or performance; it was just present in
> the example/relayd.conf.
>
> >> # seen in example, not sure of purpose
> >> match request header set "Connection" value "close"
> >
> > This tells the server to close the connection after each request and so no
> > keep-alive is happening. In some cases this is needed. Especially when
> > mutliple backends are used in match or pass rules.
>
> Same as above.
>
> >> # notify client if relay failed
> >> return error
> >> # reject unknown hosts by default
> >> block
> >> # traffic for httpd, forward
> >> pass request header "Host" value "example.com"
> >> pass request header "Host" value "www.example.com"
> >
> > I'm not sure why you do this. In general I leave the Host parsing to the
> > backend servers. Also I think Host may include the port number if it is
> > not a default port.
>
> This was because I want relayd to demux the service/port based on the
> "Host" header. I mainly hope to accomplish something like the
> following, since httpd(8) doesn't support proxying.
>
> tls on port 443 w/ "Host: unifi.example.com" => localhost port 8443, no tls
> tls on port 443 w/ "Host: kibana.example.com" => localhost port 5601, no tls
> tls on port 443 w/ "Host: www.example.com" => localhost port 80, no tls
> anything else => error
>
> >> }
> >>
> >> relay wwwrelay {
> >> listen on em1 port 443 tls
> >> protocol wwwproto
> >> transparent forward to lo port http
> >
> > On hig volume servers I would not use transparent forwading but instead
> > set the X-Forwarded-For header. Also transparent needs help from pf.
>
> I was mainly looking to use default log configuration on my services.
>
> This gives me plenty to work with; will experiment and report back, thanks.
>
> --david
>
--
With best regards,
Pavel Korovin
