diff options
| -rw-r--r-- | 20250324-web-proxy-with-relayd.md | 96 | ||||
| -rw-r--r-- | static/passthrough/20250324-network-diagram.png | bin | 0 -> 80391 bytes |
2 files changed, 96 insertions, 0 deletions
diff --git a/20250324-web-proxy-with-relayd.md b/20250324-web-proxy-with-relayd.md new file mode 100644 index 0000000..dbfe106 --- /dev/null +++ b/20250324-web-proxy-with-relayd.md @@ -0,0 +1,96 @@ +# Web proxy with OpenBSD and relayd
+
+March 24, 2025
+
+## But why?
+
+Recently I needed to setup a proxy for three websites. The proxy and the sites are distributed among two servers. One of the servers hosts the proxy itself as well as two of the sites. The other server hosts the remaining site. The two machines are connected through the internet so the forwarded traffic to the remote server needs to be encrypted. A picture is worth a thousand words as they say:
+
+[](/static/20250324-network-diagram.png)
+
+Both servers are running OpenBSD, so we're going to rely on [`relayd(8)`](https://man.openbsd.org/relayd.8) as the proxy and [`httpd(8)`](https://man.openbsd.org/httpd.8) as the web server.
+
+## relayd setup
+
+In the `relayd(8)` configuration file `/etc/relayd.conf` we must first define two tables, one for the local server running `relayd(8)` and another for the remote server `server2.com `:
+
+ table <local> { 127.0.0.1 }
+ table <remote> { server2.com }
+
+Then we have to define a `www` protocol to setup the proxy behavior for regular HTTP connections. It will forward the request to the right server based on the `Host` header. We also add special headers to the forwarded request so that the services running behind the proxy can use the information provided with these headers to adjust their behavior, should they need to. Finally, a request that doesn't match any of the expected hostnames is simply blocked.
+
+ http protocol www {
+ match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
+ match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
+
+ pass request quick header "Host" value "site3.com" forward to <remote>
+ pass request quick forward to <local>
+
+ block
+ }
+
+We also define a `wwwtls` protocol that is configured almost the same, it just has the certificates for each host we are proxying.
+
+ http protocol wwwtls {
+ tls keypair site1.com
+ tls keypair site2.com
+ tls keypair site3.com
+ match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
+ match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
+
+ pass request quick header "Host" value "site3.com" forward to <remote>
+ pass request quick forward to <local>
+
+ block
+ }
+
+The line `tls keypair site1.com` means that `relayd(8)` will look for a certificate file named `/etc/ssl/site1.com.crt` and a private key named `/etc/ssl/private/site1.com.key`. If your certificates are signed through a chain (like the ones provided by Let's Encrypt), the `.crt` file needs to contain the intermediate certificates, not just your final one. I use [`acme-client(1)`](https://man.openbsd.org/acme-client.1) to manage my certificates, which does not write the intermediate certificates with the default configuration. Thus we need to set this up in `/etc/acme-client.conf`:
+
+ domain site1.com {
+ domain key "/etc/ssl/private/site1.com.key"
+ domain full chain certificate "/etc/ssl/site1.com.crt"
+ sign with letsencrypt
+ }
+
+After editing the file, you should of course run `acme-client` to update the certificates. Next come the relays. They define which protocol to use for a request as well as where it can be forwarded. There's one for `http` and another for `https`. Nothing special here except that you may have noticed the ports for the local web server are set to 8080 and 4443. That's because `relayd(8)` is already listening on ports 80 and 443 on the proxy.
+
+ relay www {
+ listen on egress port 80
+ protocol www
+ forward to <local> port 8080
+ forward to <remote> port 80
+ }
+
+ relay wwwtls {
+ listen on egress port 443 tls
+ protocol wwwtls
+ forward with tls to <local> port 4443
+ forward with tls to <remote> port 443
+ }
+
+Ideally, we would not need to use TLS for the local forwarding. But somehow `relayd(8)` would not work with TLS enabled only on the remote forward rule. I don't know whether it's a configuration mistake on my end or whether it's a `relayd(8)` quirk. If you know more about this, I'd be glad to hear about it.
+
+Finally, at the very top of the file, we can ask `relayd(8)` to log all connections.
+
+ log connection
+
+## httpd setup
+
+There's not much to do on the `httpd(8)` side of things, except setting the ports to 8080 and 4443 on the local server, and also setting the log style to `forwarded`. This allows the IP address of the client which made the request to be logged instead of just the proxy. Please note that this information is read from the `X-Forwarded-For` and `X-Forwarded-Port` request headers, so the proxy has to set those on the forwarded request. We set this up in the previous section. An example site could be configured as such in `/etc/httpd.conf`:
+
+ server "site1.com" {
+ listen on * port 8080
+ listen on * port 4443
+ log style forwarded
+ tls {
+ certificate "/etc/ssl/site1.com.crt"
+ key "/etc/ssl/private/site1.com.key"
+ }
+ root "/htdocs/site1"
+ }
+
+If any of the services you're proxying requires its configuration to be updated, please make sure to do so.
+
+## Why not a VPN to secure traffic over the internet?
+
+I don't know how to setup a VPN. It could be the topic of a future article, but I don't know that it would provide many benefits? If you can think of any, please get in touch!
diff --git a/static/passthrough/20250324-network-diagram.png b/static/passthrough/20250324-network-diagram.png Binary files differnew file mode 100644 index 0000000..d7a4683 --- /dev/null +++ b/static/passthrough/20250324-network-diagram.png |
