rays/ipx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 18 Wiki Activity

docs: the three services, their versions and traces (#207, #213)

Browse Source 
architecture.md opens on the three services, how a trace crosses them, and the directory's
modules; sso.md's diagram and config show ipx-web in front, trusting Caddy and passing headers
only from TUNNEL_PEER; configuration.md has ipx-web's variables and the Directory as the
service's; cli.md and users.md stop describing the old local Directory; directory.md has its
traces and version.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Ray Slakinski
2026-10-12 16:40:08 +00:00
parent 38c1abba1d
commit 10a78efcc3
6 changed files with 76 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/sso.md
View File

@@ -18,7 +18,7 @@ real setup and pointed at the wrong address.
```
browser ─► Cloudflare Access, app "ipodderx" ─── sign in ───► Authentik (OpenID Connect)
─► tunnel "rays-unraid" (the cloudflared container on Tower)
─► http://192.168.1.130:8099 ─► ipx
─► http://192.168.1.130:8099, ipx-web (Caddy) ─► ipx
```
Authentik is not in the request path. It is the identity provider Cloudflare Access asks. Access
@@ -38,7 +38,7 @@ request it forwards through the tunnel, and ipx signs that person in.
enabled = true
bind = "0.0.0.0:8099"
trusted_header = "Cf-Access-Authenticated-User-Email"
trusted_proxies = ["127.0.0.1", "::1", "192.168.64.1"]
trusted_proxies = ["127.0.0.1", "::1", "192.168.64.10"] # ipx-web; see "Behind ipx-web"
access_team = "rays-sdf1.cloudflareaccess.com"
access_aud = "8bfe73dfbc8c548d1cb5dc11c6db6887bcaf4f5144840396f83a620a140e1c4f"
auto_create_users = true
@@ -67,7 +67,7 @@ Cloudflare and Authentik were already right. Three things on the ipx side were n
### The address to trust, and why it is 192.168.64.1
`cloudflared` runs in its own container and reaches ipx through the host's published port. Docker
`cloudflared` runs in its own container and reaches ipx-web (before #203, ipx) through the host's published port. Docker
(iptables firewall backend) masquerades traffic between its bridge networks, so the tunnel's
requests arrive from the **gateway of ipx's own network**, `ipx_default`:
@@ -81,8 +81,8 @@ lists them in hex.)
The `ipx` project's compose file pins that network's subnet to `192.168.64.0/20`, so its gateway
stays `192.168.64.1` when the network is recreated. It was `192.168.16.1`, `content_default`'s, while
ipx was part of the `content` project. If the subnet is ever changed, update `trusted_proxies` to
match.
ipx was part of the `content` project. If the subnet is ever changed, update `TUNNEL_PEER` in the
compose file to match (before #203, `trusted_proxies`).
### Behind ipx-web (#203)
@@ -185,10 +185,12 @@ itself, with a **Proxy Provider** and an **outpost** that adds `X-authentik-user
## How this is secured
**The header is only believed from `trusted_proxies`.** Every other source is ignored, and the
request falls through to a session cookie or the shared token. That is the whole security boundary.
**The header is only passed on from `TUNNEL_PEER`, and only believed from `trusted_proxies`.**
Caddy strips `Cf-Access-*` from every request that does not come from `TUNNEL_PEER`, and ipx
ignores the header from anyone but Caddy, its one trusted proxy; such a request falls through to a
session cookie or the shared token. That is the whole security boundary.
With the tunnel reaching ipx through the host's port, `192.168.64.1` means **any container on Tower
With the tunnel reaching ipx-web through the host's port, `192.168.64.1` means **any container on Tower
that connects to `192.168.1.130:8099`**, not only `cloudflared`. Machines on the LAN, and Tower
itself, arrive under their own addresses and cannot set the header; the checks above show both
sides. Never list a LAN address or range: anyone there could then send