Differences

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

--- automation:vpn [2025/12/20 17:37] – created - external edit 127.0.0.1
+++ automation:vpn [2025/12/20 17:47] (current) – privacyl0st
@@ Line 1: / Line 1: @@
+====== VPN Importance for Automation & Acquisition Servers ======
+Any server responsible for **media acquisition or automation control** should be treated as **internet-facing infrastructure**, even if it is not directly exposed via open ports.
+A VPN is not optional hardening — it is a **baseline requirement** for protecting identity, reducing exposure, and enforcing predictable traffic flow.
+This page explains **why a VPN is required**, how it fits into the Trash Panda Guides architecture, and outlines **best-practice VPN behavior**, with NordVPN recommended as a known-good provider.
+Configuration steps are intentionally covered on separate pages.
+===== Why a VPN Is Required =====
+Automation and acquisition servers routinely:
+  * Communicate with external services
+  * Query indexers and metadata providers
+  * Download content from untrusted or variable sources
+  * Maintain long-lived outbound connections
+Without a VPN, this traffic:
+  * Exposes your public IP address
+  * Is directly attributable to your ISP account
+  * Can be logged, throttled, or flagged
+  * Breaks the assumption of isolation used elsewhere in the architecture
+A VPN establishes a **controlled, encrypted egress path** that decouples acquisition traffic from your physical location and ISP identity.
+===== Risk Reduction, Not Anonymity =====
+This is not about absolute anonymity.
+A VPN provides:
+  * IP abstraction
+  * Traffic encryption in transit
+  * Reduced ISP visibility
+  * Consistent routing behavior
+It does **not**:
+  * Make a system immune to misconfiguration
+  * Replace firewall rules
+  * Protect exposed services
+Think of the VPN as a **network boundary**, not a magic shield.
+===== Architectural Role of the VPN Server =====
+In the Trash Panda Guides environment:
+  * The automation/acquisition server is isolated
+  * Internet-bound traffic is forced through the VPN
+  * LAN traffic remains local and unrestricted
+This creates a clear separation:
+  * WAN traffic = encrypted, tunneled
+  * LAN traffic = direct, low-latency
+This balance is critical — especially for:
+  * NFS mounts
+  * Plex communication
+  * Reverse proxy access
+  * Management UIs
+===== Mandatory VPN Behavior =====
+Any acceptable VPN configuration **must** meet the following requirements:
+  * All internet-bound traffic traverses the VPN
+  * Local subnet traffic bypasses the VPN
+  * VPN failure does not leak traffic
+  * The VPN starts automatically at boot
+  * No application-level VPN exceptions
+If the VPN drops, traffic should **fail closed**, not silently fall back to the WAN.
+===== Why NordVPN Is Recommended =====
+Any reputable VPN provider can work, but NordVPN is recommended because it:
+  * Supports Linux natively
+  * Provides a mature CLI
+  * Allows fine-grained routing control
+  * Supports kill-switch enforcement
+  * Is widely documented and well-tested
+NordVPN is not required — but using it minimizes unknowns.
+===== NordVPN Best-Practice Settings =====
+When using NordVPN on an automation or acquisition server, the following **behavioral settings** are considered best practice.
+==== Core Settings ====
+  * VPN protocol: **NordLynx**
+  * Auto-connect: **Enabled**
+  * Start on boot: **Enabled**
+  * Kill switch: **Enabled (system-wide)**
+These ensure the VPN is always active and traffic never escapes unintentionally.
+==== Traffic Routing Behavior ====
+  * Route **all external traffic** through VPN
+  * Exclude **local subnets** from the tunnel
+  * Do not rely on application-level split tunneling
+Local resources (examples):
+  * NAS / NFS servers
+  * Plex Media Server
+  * Reverse proxy
+  * Management workstations
+These must remain reachable even if the VPN is active.
+==== DNS Handling ====
+  * Use VPN-provided DNS
+  * Do not use ISP DNS
+  * Avoid custom DNS unless required
+DNS leaks defeat the purpose of tunneling traffic.
+==== Server Selection ====
+  * Use geographically stable regions
+  * Avoid frequent region hopping
+  * Avoid specialty servers unless required
+Consistency improves reliability and reduces unexpected failures.
+===== VPN + Automation: Why This Matters =====
+Automation tools assume:
+  * Reliable connectivity
+  * Predictable routing
+  * Stable IP behavior
+A misconfigured VPN can:
+  * Break indexer access
+  * Prevent downloads
+  * Disrupt local mounts
+  * Cause silent failures
+A properly configured VPN becomes invisible — exactly as intended.
+===== What This Page Does NOT Cover =====
+This page intentionally avoids:
+  * CLI command syntax
+  * OS-specific setup steps
+  * Firewall rule definitions
+  * Tool-level binding
+Those topics are covered in:
+  * VPN installation guides
+  * Automation server configuration pages
+  * Download client binding guides
+===== Summary =====
+A VPN on the automation/acquisition server is:
+  * A security boundary
+  * A routing policy
+  * A reliability requirement
+When implemented correctly:
+  * Internet traffic is controlled and encrypted
+  * Local services remain fast and accessible
+  * Automation runs uninterrupted
+  * Failures are obvious, not silent
+This is foundational infrastructure — not an optional add-on.