Files
serverAppConfigs/serverAppConfigs-docs/Architecture/Network Architecture.md
T
Frank cf2fe4435c docs: topology diagram as-it-stands — two-tier chain Caddy-TLS, Anubis verify, internal listener 8016
Replaces the pre-Anubis direct-routing diagram with the live chain:
Caddy TLS -> Anubis :8923 verify -> accepted traffic back to Caddy's
internal listener :8016, where per-vhost routing resumes and Authentik's
embedded outpost gates wrapped apps via forward_auth. Guarded set
(homepage, search, hermes, prometheus, romm, files) and the
exempt-by-construction set (auth, plex, gitea git paths, grafana) are
listed explicitly. Access Policy bullet updated: basic auth was replaced
by the challenge-then-forward_auth layering.
2026-08-28 11:56:50 -07:00

4.0 KiB

Network Architecture

One Caddy fronts both hosts. It runs as a container on Dankclaw (192.168.0.143) and terminates TLS for every service on the LAN. Pi-hole on Dankclaw answers the service names for LAN clients; Porkbun answers them for the WAN. The G36 router firewall governs external access. SearXNG outbound traffic exits through the Gluetun VPN container.

Topology

As of 2026-08-28 the front door is a two-tier chain: Caddy terminates TLS, Anubis verifies the client (DENY known AI scrapers, CHALLENGE everyone else), and accepted traffic returns to Caddy's internal listener on :8016, where per-vhost routing resumes. Authentik's outpost then gates the wrapped apps with forward_auth. See Anubis and Authentik.

graph TB
    EXT[Internet] -->|port forwards 80/443| CADDY[Caddy TLS :80 :443 — Dankclaw]
    LAN[LAN clients] -->|Pi-hole DNS :53| CADDY

    subgraph Dankclaw[Dankclaw 192.168.0.143]
        CADDY -->|unwrapped vhosts route direct| DIRECT{direct routes}
        CADDY -->|guarded vhosts| ANUBIS[Anubis verify :8923]
        ANUBIS -->|deny AI bots| EXT
        ANUBIS -->|challenge solved or bypassed| INT[Caddy internal listener :8016]
        INT -->|forward_auth outpost| AUTH[Authentik server :9000 loopback]
        INT --> HOME[Homepage file_server]
        INT --> SEARCH[SearXNG via Gluetun netns :8081]
        INT --> HERMES[Hermes :8090]
        INT --> PROM[Prometheus :9090]
        DIRECT -->|3000 + ssh 2222| GITEA[Gitea]
        DIRECT -->|3005| OWEBUI[OpenWebUI]
        DIRECT -->|3002| GRAFANA[Grafana :3000]
        DIRECT -->|8083 web UI| PIHOLE[Pi-hole]
        AUTH -->|login UI + sessions| AUTHDB[(Authentik Postgres :5432)]
        SEARCH -.->|tunnel exit| GLU[Gluetun VPN]
        GLU -.-> EXT
    end

    subgraph Dankserver[Dankserver 192.168.0.235]
        ROMM[RomM :8085]
        COPY[Copyparty :3923]
        CAL[Calibre-Web :8083]
        PLEX[Plex :32400]
        JEL[Jellyfin :8096]
        ARR[*arr stack + qBittorrent]
    end

    INT -->|romm, files guarded paths| ROMM
    DIRECT -->|plex plain-HTTP passthrough| PLEX
    DIRECT --> CAL
    DIRECT --> JEL
    DIRECT --> ARR

Guarded (through Anubis): homepage, search, hermes, prometheus, romm, files. Exempt by construction: auth. (the IdP login itself), plex (plain HTTP), gitea (git smart-HTTP clients cannot solve JS challenges — /info/refs and git-*-pack pass unchallenged), grafana (own auth).

Dankserver runs no proxy of its own. Its services expose published LAN ports, and the Dankclaw Caddy routes the names to those ports.

Hostnames

Scope Convention Resolved by
LAN romm.franksdank.cloud → 192.168.0.143 Pi-hole (addn-hosts)
WAN romm.franksdank.cloud → 71.227.227.172 Porkbun A record

Users type a name and nothing else. Caddy maps the name to the upstream. The split between the two resolvers removes the need for router NAT loopback. See LAN-DNS for the flow and the router hand-off.

TLS

Caddy holds one Let's Encrypt certificate per vhost, issued and renewed through the DNS-01 challenge via the Porkbun module. No inbound port 80/443 is required. Details in Caddy.

Gluetun Path (SearXNG only)

SearXNG attaches to the Gluetun network namespace (network_mode: service:gluetun). Only SearXNG shares the tunnel. Everything else on Dankclaw uses the normal LAN route. This matches KB Pattern 2 in Gluetun.

Access Policy

  • The G36 router firewall governs what the WAN can reach. Port forwards are manual router steps; the repo tracks no router state.
  • Access is layered: Anubis challenges/denies bots at the front door, then Authentik's embedded outpost (forward_auth) gates the wrapped apps. Apps with their own login (Grafana, Gitea, Plex) run unwrapped. See Anubis and Authentik.
  • LAN subnet: 192.168.0.0/24.

See Also