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.
> 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).
> 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.
> 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.
> # 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.
> # 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.
> }
>
> 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.
> }
>
--
:wq Claudio
No comments:
Post a Comment