PROXY protocol is a convenient way to carry information about the
originating address/port of a TCP connection across multiple layers of
proxies/NAT, etc.
Currently, it is possible to make use of it in NGINX's NixOS module, but
is painful when we want to enable it "globally".
Technically, this is achieved by reworking the defaultListen options and
the objective is to have a coherent way to specify default listeners in
the current API design.
See `mkDefaultListenVhost` and `defaultListen` for the details.
It adds a safeguard against running a NGINX with no HTTP listeners (e.g.
only PROXY listeners) while asking for ACME certificates over HTTP-01.
An interesting usecase of PROXY protocol is to enable seamless IPv4 to
IPv6 proxy with origin IPv4 address for IPv6-only NGINX servers, it is
demonstrated how to achieve this in the tests, using sniproxy.
Finally, the tests covers:
- NGINX `defaultListen` mechanisms are not broken by these changes;
- NGINX PROXY protocol listeners are working in a final usecase
(sniproxy);
- uses snakeoil TLS certs from ACME setup with wildcard certificates;
In the future, it is desirable to spoof-attack NGINX in this scenario to
ascertain that `set_real_ip_from` and all the layers are working as
intended and preventing any user from setting their origin IP address to
any arbitrary, opening up the NixOS module to bad™ vulnerabilities.
For now, it is quite hard to achieve while being minimalistic about the
tests dependencies.
The status page is inaccessible by default, unless a virtual host is
added with a `server_name` that's not `localhost`.
This commit moves the status page configuration, so that
it's matched before the main server blocks.
This reverts commit a768871934.
This is too fragile, it breaks at least on:
* ssl dh params
* hostnames in proxypass and upstreams are resolved in the sandbox
In most places in NixOS defining an option multiple places just merges the result together. This is particularly useful if you have two modules that both need an option, you don't want to have problems when they both set it. This makes the nginx `additionalModules` option follow this pattern.
Currently, this is using a "URI prefix match", but per nginx docs,
```
[...] the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.
```
which means a config like this (from wordpress service) will override that
```
locations = {
"~ /\\." = {
priority = 800;
extraConfig = "deny all;";
};
};
```
😱
Luckily, from nginx docs:
```
If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.
```
Whew!
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
mostly no rendering changes. some lists (like simplelist) don't have an
exact translation to markdown, so we use a comma-separated list of
literals instead.
