User Tools

Site Tools


foundation:reverseproxy

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
foundation:reverseproxy [2025/12/20 15:25] privacyl0stfoundation:reverseproxy [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
Line 1: Line 1:
-====== Reverse Proxy VM (NGINX) ====== 
-This virtual machine is the **gateway** of the Trash Panda ecosystem. It manages external access to internal services, handles SSL termination, and enforces secure routing policies. While it is **internet-facing**, its sole function is to run a reverse proxy and manage certificates. Proper VM design ensures **reliable access and minimal exposure risk**.\\   
- 
-This page covers **only the VM setup and deployment**. NGINX configuration, CERTBOT setup, and site routing are covered in their own guide.\\   
- 
-===== Role of This VM in the Ecosystem ===== 
-The Reverse Proxy VM:\\   
-  * Routes inbound traffic to internal services   
-  * Terminates SSL/TLS via CERTBOT   
-  * Acts as the single point of entry for web-facing services   
-  * Lives in the DMZ to isolate external access   
- 
-By isolating this service into a dedicated VM, we:\\   
-  * Reduce attack surface for exposed services   
-  * Simplify troubleshooting and maintenance   
-  * Ensure predictable performance for all proxy and certificate operations   
- 
-This VM should operate quietly and **securely mediate traffic** between the internet and internal services.   
- 
-===== Base Operating System ===== 
-  * **Ubuntu Server 24.04 LTS**   
-  * Minimal installation (no desktop environment)   
-  * Automatic security updates enabled   
- 
-Ubuntu LTS provides:\\   
-  * Long-term security support   
-  * Strong community documentation   
-  * Stability for long-running, internet-facing services   
- 
-This VM should run **headless** and be administered via SSH.   
- 
-===== Virtual Hardware Allocation ===== 
- 
-==== Memory (RAM) ==== 
-  * **2 GB RAM (fixed allocation)**   
- 
-Why 2 GB?\\   
-  * NGINX and CERTBOT are lightweight applications   
-  * Memory headroom ensures stable operation under traffic bursts   
- 
-Avoid memory overcommit to maintain responsiveness for web requests.   
- 
-==== CPU Allocation ==== 
-  * **2 vCPUs**   
- 
-Traffic handling is:\\   
-  * Burst-oriented rather than sustained   
-  * Light on raw compute   
-  * Sensitive to latency   
- 
-Two vCPUs provide sufficient parallelism for proxy and certificate tasks.   
- 
-==== Storage Allocation ==== 
-  * **30 GB virtual disk**   
-  * Thin provisioned (recommended)   
- 
-This storage is used for:\\   
-  * OS and system packages   
-  * NGINX installation and configuration   
-  * SSL certificates, logs, and temporary files   
- 
-**No media or user data is stored here.** This VM’s sole purpose is proxying and certificate management.   
- 
-===== Network Configuration ===== 
-This VM requires **one network interface**, optimized for controlled exposure.\\   
- 
-==== NIC 1 — DMZ VLAN ==== 
-Purpose:\\   
-  * Serve as the entry point for inbound web traffic   
-  * Outbound access for CERTBOT and updates   
-  * Communicate with internal services behind the proxy   
- 
-Characteristics:\\   
-  * Standard MTU (1500)   
-  * Routed through firewall   
-  * Static IP recommended   
- 
-Placing the VM in the DMZ ensures:\\   
-  * Isolation from internal LAN services   
-  * Minimal attack surface   
-  * Controlled, secure access to exposed services   
- 
-===== VMware Workstation Pro Configuration Notes ===== 
-Assuming VMware Workstation Pro 17:\\   
-  * Attach a single virtual network adapter   
-  * Bind to the physical NIC connected to the DMZ VLAN   
-  * Disable unnecessary virtual hardware (sound, USB, etc.)   
-  * Use VMXNET3 adapters for best performance   
- 
-Do **not** connect this VM to the Primary LAN VLAN.   
- 
-===== Design Philosophy Recap ===== 
-This VM is designed to be:\\   
-  * Quiet   
-  * Predictable   
-  * Disposable if needed   
-  * Easy to rebuild   
- 
-If it ever fails, you should be able to:\\   
-1. Recreate the VM\\   
-2. Restore NGINX configuration and SSL certificates\\   
-3. Resume secure proxy operations   
- 
-No irreplaceable data should live on the VM itself.   
- 
-===== What Comes Next ===== 
-Once the VM is deployed and reachable:\\   
-  * Install and configure NGINX (native to OS)   
-  * Configure CERTBOT and SSL certificate automation   
-  * Integrate with internal services and firewall rules   
-  * Configure backups and monitoring   
- 
-Each of these topics is covered in their respective guides.\\   
- 
-A well-configured Reverse Proxy VM **keeps services accessible and secure** without fuss. 
  
foundation/reverseproxy.1766244357.txt.gz · Last modified: by privacyl0st