# VPS Infrastructure Management - Oracle Japan

Multi-server infrastructure configuration and deployment rules for Tokyo VPS instances.

---

## 🖥️ Server Registry

### 1. `server2` (Tokyo Region)
*   **Public IP**: `158.101.140.85`
*   **Tailscale IP**: `100.70.115.1` (`oracle-tokyo`)
*   **Role**: Fast Outbound Network Proxy & Network-level AdGuard DNS resolver.
*   **SSH Access**: `ssh server2` (uses user `jimmyg`, key `~/.ssh/id_ed25519_vps`)
*   **Running Services**:
    *   **Xray**: VLESS+Reality protocol on port `443`.
    *   **Tailscale**: Active exit node to route external mesh network traffic.
    *   **WireGuard**: Client tunnel on port `51820`.
    *   **AdGuard Home**: Network-wide ad blocker and local resolver on DNS port `53` and Web UI port `3000` (Tailscale bound).
    *   **fail2ban**: Brute-force mitigation active for SSH.

### 2. `caddy-vps` (Tokyo Region)
*   **Public IP**: `161.33.182.109`
*   **Tailscale IP**: `100.109.198.126` (`caddy-proxy`)
*   **Role**: Public edge reverse proxy with HTTPS (Let's Encrypt TLS) and Authelia forward-auth integration.
*   **SSH Access**: `ssh caddy-vps` (uses user `ubuntu`, key `~/.ssh/id_ed25519_vps`)
*   **Running Services**:
    *   **Caddy**: Edge web server listening on ports `80` and `443` to route traffic to local Synology NAS services.
    *   **Tailscale**: Node agent to connect to local NAS services on the mesh network.

---

## 📁 Repository Structure
```text
vps-oracle-jp/
├── server2/                     # Configurations & tools for server2
│   ├── xray-config.json         # VLESS+Reality server proxy config
│   ├── clash-meta.yaml          # Clash Meta mobile configuration
│   ├── japan-vps-qr.png         # Shadowrocket client setup QR
│   ├── clash-meta-qr.png        # Clash Meta client setup QR
│   ├── harden.sh                # Server security hardening script
│   ├── setup-tailscale-exit-node.sh  # Exit node router config script
│   └── uptime-check.sh          # Server service health check utility
├── caddy-vps/                   # Configurations for caddy-vps
│   └── Caddyfile                # Active reverse proxy routing rules
└── .gitea/
    └── workflows/deploy.yml     # Automated multi-server CI/CD pipeline
```

---

## 🚀 CI/CD Automated Deployment
Deployments are managed automatically on Gitea via Gitea Actions whenever changes are pushed to the `main` branch:

1.  **Validation & Linting**:
    *   Tests `server2/xray-config.json` for proper JSON syntax.
    *   Tests `server2/clash-meta.yaml` for correct YAML structural formatting.
    *   Downloads a static Caddy binary to format check (`caddy fmt --check`) and syntax validate (`caddy validate --adapter caddyfile`) the `caddy-vps/Caddyfile`.
2.  **Security Scan**:
    *   Verifies that no private keys or high-risk credentials have been accidentally committed to any text files in the repository.
3.  **SSH Deployments**:
    *   Deploys `xray-config.json` to `/usr/local/etc/xray/config.json` on `server2`, sets strict permissions (`600`), and restarts Xray.
    *   Deploys `Caddyfile` to `/etc/caddy/Caddyfile` on `caddy-vps`, sets safe permissions (`644`), and performs a zero-downtime `systemctl reload caddy`.