Differences

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

--- automation:vpn [2025/12/20 17:47] – privacyl0st
+++ automation:vpn [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ 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.