IPv6: brackets for addresses, not always for hosts
Working with IPv6 for the first time brought a useful lesson: addresses are often written in square brackets. For example, getting rails to listen on an IPv6 address required running:
CMD ["rails", "server", "-b", "[::]"]
Using CMD ["rails", "server", "-b", "0.0.0.0"] only binds to IPv4, which is easy to overlook.
But brackets aren't universal. I successfully SSH'd to an IPv6 address without them:
ssh fdaa:0:bff:a7b:aa4:4c98:4224:2
The pattern appears to be that brackets are needed when a port is included—fade::5 with port 53 becomes [fade::5]:53—since otherwise the port could be ambiguous with the address itself.
Forcing nginx to re-resolve DNS
A static proxy_pass directive in nginx resolves the hostname only once at startup, which becomes a problem when backend IPs change frequently. The fix is to route proxy_pass through a variable:
location @rails {
resolver [fdaa::3];
set $backend "http://rails.internal:8080";
proxy_pass $backend;
}
When the upstream is specified with a variable, nginx performs DNS resolution per request. One extra requirement: you have to explicitly configure a DNS server in the nginx config—it won't fall back to /etc/resolv.conf.
Even with that setup, the configuration still wasn't working in my case, and the cause remained unclear. That's a puzzle for another day.
Wireguard setup is surprisingly simple
Setting up Wireguard for the first time turned out to be straightforward. Since the remote end was already configured, client setup only involved a few steps:
- Install with
apt-get install wireguard - Place the provided configuration file at
/etc/wireguard/fly.conf - Bring the interface up with
wg-quick up fly
That was it—the tunnel came up without fuss.
