rproxy Function and Feature Synopsis

Last updated: 2026-05-27

This synopsis is the shared baseline for future user and technical documentation for rproxy.cfts.co.

The goal is to describe what the platform does and what features it already provides before expanding into full manuals, runbooks, or training material.

Short Version

rproxy.cfts.co is the CFTS reverse proxy and secure web front door.

It receives browser traffic for CFTS hostnames, terminates HTTPS, applies access rules, adds safe edge behaviour where appropriate, records access logs, and forwards approved requests to the correct internal service.

For users, it is the thing that makes names like docs.cfts.co, tickets.cfts.co, monitor.cfts.co, and inventory.cfts.co work.

For administrators, it is shared edge infrastructure that controls which services are public, which are LAN-only, which are mixed, and how traffic is logged and inspected.

Primary Functions

User-Visible Features

Users interact with rproxy.cfts.co indirectly through service hostnames.

Current user-facing or admin-facing surfaces include:

For user documentation, the main message is simple: open the correct service URL; if a service is LAN-only, use the LAN or approved access path; if the app asks for login, that login belongs to the upstream application unless the page clearly shows Caddy Basic Auth.

Access Patterns

The platform currently uses four access patterns.

Security Features

The current security posture is practical rather than decorative.

• Public 80/tcp and 443/tcp are the main exposed services.
• SSH runs on 4422/tcp and is intended for LAN access.
• SNMP is limited to PRTG at 172.16.198.50.
• HTTP/3 is disabled; public 443/udp is not part of the intended edge surface.
• HTTPS uses Caddy-managed certificates.
• Unknown plaintext HTTP hostnames are logged separately and aborted.
• Known HTTP hostnames redirect to HTTPS.
• HTTPS uses strict SNI host checking.
• Shared snippets remove common software-identifying response headers where safe.
• Shared snippets remove client-supplied spoofable proxy/IP request headers before proxying where safe.
• Strict CSP, Permissions-Policy, HSTS, and frame controls are used on simple public sites that can tolerate them.
• Compatibility headers are used on legacy apps and dashboards that may break under strict CSP.
• Request bodies are capped on sites where browser uploads are not expected.
• Fail2Ban source configs exist for unknown-host and scanner-path signals.
• Unattended Ubuntu security upgrade configs exist, without automatic reboots.

Observability Features

The observability story is intentionally lightweight.

• Caddy writes JSON access logs under /var/log/caddy.
• Important public and admin routes have dedicated log files.
• rp-logs.cfts.co serves a static GoAccess HTML dashboard for LAN clients.
• The GoAccess report is generated every five minutes by a systemd timer.
• The dashboard helps admins review request volume, status codes, requested paths, failed requests, referrers, and client activity without reading raw Linux logs first.
• PRTG integration is planned for edge health, certificates, Fail2Ban state, listener drift, disk/log growth, and patch cadence.

Operational Features

The repository now carries more than the Caddyfile.

Technical Architecture

At a high level:

User browser
  -> DNS hostname such as docs.cfts.co
  -> Caddy on rproxy.cfts.co / 172.16.198.60
  -> Hostname-specific Caddy route
  -> Access decision, headers, logging, error handling
  -> Internal upstream service or static report files

Key technical components:

• Caddy is the reverse proxy and HTTPS edge.
• Reusable Caddy snippets live under caddy/includes.
• Shared Caddy error pages live under caddy/errors.
• Internal upstream services live on 172.16.198.x hosts.
• GoAccess renders Caddy logs into a static report.
• systemd manages Caddy and the GoAccess report timer.
• Fail2Ban protects SSH today and has source configs for Caddy scanner signals.
• UFW limits exposed services to the expected reverse proxy, SSH, and SNMP surface.

Documentation Bases To Cover

Future user documentation should cover:

• Which URL to use for each service.
• Whether the service is public, LAN-only, or mixed.
• What a 403 means on LAN-only services.
• Which login prompt belongs to Caddy and which belongs to the upstream app.
• Where admins can view the log dashboard.
• When to escalate an issue to a technical admin.

Future technical documentation should cover:

• How to add, change, or remove a hostname.
• How to choose the right Caddy snippet/profile.
• How to create and permission new access logs.
• How to validate and reload Caddy safely.
• How to test public, LAN-only, and mixed access rules.
• How to read logs and GoAccess reports.
• How to deploy Fail2Ban and unattended-upgrades configs.
• How to rebuild the server from the repository.
• How to keep the exposure matrix current.

Open Questions Before Expanding Docs

Before turning this into a full documentation set, confirm:

1. Which hostnames should have user-facing pages versus admin-only technical notes.
2. Whether monitor.cfts.co should remain public long-term, as currently documented.
3. Whether all LAN-only services should also require Caddy Basic Auth when accessed from approved admin networks.
4. Whether every active hostname should get a dedicated Caddy JSON access log.
5. Whether PRTG integration should be documented as planned work or implemented first.
6. Which audience names should be used: end users, admins, sysops, support, or technical owners.
7. Whether the final docs should live only in Markdown or also be published through docs.cfts.co.