MarioNovelles/linux-selfhosted-infrastructure-lab

# Linux 自托管基础设施实验室 专注于 Linux 管理、网络、虚拟化、基于 Docker 的服务、防火墙、DNS、VPN 访问、反向代理、备份、监控和故障排除的实用自托管基础设施实验室。 ## 概述 本仓库记录了一个私有的、自行管理的基础设施环境，我利用它来培养与 IT 支持、Linux 系统管理、网络、基础设施运维以及自托管服务管理相关的实操技能。 该实验室围绕实际的基础设施工作而建，而不仅仅是运行应用程序。我利用它在真实的家庭和小型企业级环境中，练习安装、维护、记录和故障排除基于 Linux 的服务。 目前的实验室包含 Linux 服务器、Proxmox 虚拟化、TrueNAS 存储、Proxmox Backup Server、Docker Compose 服务、Cloudflare DNS、Tailscale 类 VPN 访问、监控、VoIP、本地 AI 实验以及作为核心边缘平台的 pfSense。目前，pfSense 负责处理防火墙、pfBlockerNG DNS/IP 过滤、Suricata IDS/IPS 可见性、ACME/TLS 证书管理以及 HAProxy 反向代理路由。 有些组件已经实施，有些曾进行过测试，还有一些正在计划或改进中。本仓库的目标是展示实践学习、结构化故障排除、安全意识和文档编写习惯，同时不会发布敏感的配置细节。 ## 展示的技能 本项目展示了对以下方面的实际操作经验： - 安装和维护 Linux 服务器环境 - 使用 Docker Compose 运行自托管服务 - 使用 HAProxy 管理反向代理访问 - 管理 DNS 和 ACME/TLS 证书工作流 - 使用 VPN 工具进行安全的远程访问 - 运行基于 pfSense 的防火墙、使用 pfBlockerNG 进行 DNS/IP 过滤、利用 Suricata 实现可见性、ACME 证书工作流以及 HAProxy 反向代理路由 - 使用 Proxmox VE、Proxmox Backup Server 和 TrueNAS - 排查 Linux 服务、容器、DNS、防火墙和连接性问题 - 规划备份和恢复工作流 - 清晰地记录基础设施决策 ## 仓库状态 本仓库是一个作品集和文档项目。 | 状态 | 含义 | |---|---| | 已实施 | 目前正在我的实验室中运行，或之前已构建/测试过 | | 进行中 | 正在配置、记录或改进中 | | 计划中 | 已经研究或计划，但尚未完全实施 | | 已省略 | 未包含在本仓库中，或与当前版本无关 | ## 高级架构概览 该实验室围绕不同的基础设施角色进行组织：路由/防火墙、虚拟化、存储、备份、应用服务、监控、VoIP 和实验环境。  上面的图表是一个经过脱敏处理的公开概览。它避免了暴露真实的域名、IP 地址、凭据、确切的防火墙规则以及敏感的内部细节。 有关详细的拓扑结构、服务部署、存储设计和架构权衡，请参阅[架构](./docs/architecture.md)。

Internet

   |

   v

Firewall / Router

(pfSense)

   |

   +-- OpenWrt access point

   |     - Main Wi-Fi

   |     - Separate guest Wi-Fi

   |

   v

Home / lab network

   |

   v

Planned managed VLAN switch

(not currently deployed)

   |

   +-- Virtualization host

   |     - Linux VMs

   |     - Docker services

   |     - Monitoring services

   |

   +-- Storage server

   |     - File storage

   |     - Snapshots

   |     - Backup targets

   |

   +-- Backup server

   |     - VM/container backups

   |     - Restore points

   |

   +-- VoIP server

   |

   +-- AI / experimentation node

   |

   +-- Lightweight nodes

         - DNS filtering / fallback services

         - Sensors / testing



## 仓库导航

本仓库已发展为几个部分。以下结构有助于更快地找到文档、脚本和脱敏示例。

- [`README.md`](./README.md) — 实验室主概览
- [`dns-filtering/`](./dns-filtering/README.md) — DNS 过滤笔记、黑名单、白名单、正则表达式规则和 DNS 强制实施说明
- [`blocklists.md`](./dns-filtering/blocklists.md)
- [`allowlists.md`](./dns-filtering/allowlists.md)
- [`regex.txt`](./dns-filtering/regex.txt)
- [`encrypted-dns-providers.txt`](./dns-filtering/encrypted-dns-providers.txt)
- [`ip-blocklists.md`](./dns-filtering/ip-blocklists.md)
- [`dns-redirect.md`](./dns-filtering/dns-redirect.md)
- [`docs/`](./docs/README.md) — 通用文档、架构说明、操作手册和案例研究
- [`architecture.md`](./docs/architecture.md)
- [`docker-compose-architecture.md`](./docs/docker-compose-architecture.md)
- [`firewall-policy.md`](./docs/firewall-policy.md)
- [`case-studies/`](./docs/case-studies/)
- [`runbooks/`](./docs/runbooks/)
- [`scripts/`](./scripts/README.md) — 维护和管理脚本
- [`update-laptop.sh`](./scripts/update-laptop.sh)
- [`update-ubuntu-server.sh`](./scripts/update-ubuntu-server.sh)
- [`start-jellyfin.sh`](./scripts/start-jellyfin.sh)
- [`examples/`](./examples/README.md) — 脱敏的配置示例和服务示例
- [`.gitignore`](./.gitignore) — 防止提交密钥和敏感文件



## 基础设施组件与平台

本节列出了基础设施的构建模块：平台、网络/安全组件、部署工具、存储、备份和边缘服务。应用工作负载将在下文中单独列出。表格大致按从网络边缘和接入层到虚拟化、存储、部署工具以及计划中的解耦实验的顺序排列。

| 组件 | 状态 | 用途 | 备注 |

|---|---|---|---|

| pfSense | 已实施 | 边缘防火墙/路由器和安全平台 | 用于防火墙、路由、pfBlockerNG、Suricata、ACME 证书和 HAProxy 反向代理的核心平台 |

| pfBlockerNG | 已实施 | DNS/IP 过滤 | 通过 pfSense 管理 DNS 过滤和 IP 黑名单 |

| Suricata | 已实施 | IDS/IPS 可见性 | 通过 pfSense 管理流量告警和安全监控 |

| HAProxy | 已实施 | 反向代理 | 通过 pfSense HAProxy 插件管理；未来的改进方向是评估在 pfSense 之外的专用反向代理 |

| ACME / Let's Encrypt | 已实施 | TLS 证书 | 通过 pfSense ACME 插件管理；未来的改进方向是评估在 pfSense 之外的专用 ACME 工作流 |

| OpenWrt | 已实施 | 无线接入点角色 | 作为简单的 WAP 使用，提供主 Wi-Fi 和独立的访客 Wi-Fi |

| Cloudflare DNS | 已实施 | DNS 和域名管理 | 用于 DNS/域名路由 |

| Tailscale | 已实施 | VPN 式远程访问 | 之所以使用它，是因为当前连接位于 CGNAT 之后 |

| WireGuard | 曾实施过 | VPN 访问 | 过去曾使用；由于 CGNAT 的存在，目前较少作为核心使用 |

| Proxmox VE | 已实施 | 虚拟化平台 | 用于虚拟化服务和实验室系统 |

| TrueNAS | 已实施 | 存储平台 | 用于存储和快照 |

| Proxmox Backup Server | 已实施 | 备份和恢复平台 | 用于 VM/容器备份工作流 |

| Docker | 已实施 | 容器运行时 | 用于自托管服务 |

| Docker Compose | 已实施 | 服务部署 | 用于定义和操作多容器服务 |

| Pi-hole | 曾实施过 / 再次计划中 | DNS 过滤 | 计划作为 pfSense 之外可能的专用 DNS 过滤层 |

| Traefik | 计划中 | 反向代理探索 | 计划用于比较和评估 pfSense 之外的反向代理/证书管理 |

| Headscale | 计划中 | 自托管 Tailscale 控制服务器 | 为未来的实验做计划 |



## 自托管应用与工作负载

本节列出了运行在上述基础设施组件之上的应用程序和类服务工作负载。表格按用途分组：生产力/数据、Web/信息服务、监控、媒体、通信、AI/自动化实验以及计划中的应用程序。

| 工作负载 | 状态 | 用途 |

|---|---|---|

| Nextcloud | 已实施 | 文件访问和协作 |

| Syncthing | 已实施 | 文件同步 |

| Vaultwarden | 已实施 | 密码管理器服务 |

| Joplin | 已实施 | 笔记/文档工作流 |

| WordPress | 已实施 | Web 托管实践 |

| SearXNG | 已实施 | 自托管搜索 |

| Uptime Kuma | 已实施 | 运行时间和可用性监控 |

| Grafana | 已实施 | 监控仪表板和指标可视化 |

| Prometheus | 已实施 | 指标收集 |

| Jellyfin | 已实施 | 媒体服务 |

| Jellyseerr | 已实施 | 媒体请求工作流 |

| Navidrome | 已实施 | 音乐流媒体 |

| Audiobookshelf | 已实施 | 有声读物管理 |

| Calibre-Web | 已实施 | 电子书库 |

| 媒体相关服务 | 已实施 | 用于练习容器管理、存储路径、权限、服务依赖关系和故障排除 |

| FreePBX | 已实施 | VoIP 服务器和电话系统实验 |

| Ollama | 已实施 | 本地 AI 实验 |

| Open WebUI | 已实施 | Ollama 的本地 AI Web 界面 |

| OpenClaw | 曾实施过 | Agentic AI 实验 |

| Hermes Agent | 已实施 | 本地 Agentic 自动化实验 |

| Immich | 计划中 | 照片管理 |

| Home Assistant | 计划中 | 智能家居自动化 |



## 网络设计

当前的网络使用基于 pfSense 和 OpenWrt 的组件。OpenWrt 提供无线接入点功能，而 pfSense 负责防火墙/路由器职责。

在此设置中，pfSense 还通过软件包管理几个边缘和安全服务：用于 DNS/IP 过滤的 pfBlockerNG、用于 IDS/IPS 可见性的 Suricata、用于 Let's Encrypt 证书工作流的 ACME，以及用于反向代理路由的 HAProxy。

作为未来的改进方向，我希望减少与 pfSense 紧密耦合的支持性服务的数量。目标是让 pfSense 专注于路由、防火墙和边缘安全，同时在适当的情况下将某些服务级别的功能移动到专用的主机或 VM 上。这包括评估使用 Pi-hole 进行 DNS 过滤，以及评估专用的反向代理/证书工作流，例如使用 Traefik 或基于 Linux 的 HAProxy 和 ACME 设置。

在添加可管理交换机后，下一阶段将计划基于 VLAN 的网络分段。该计划将不同类型的系统划分为不同的逻辑区域，而不是将整个网络视为一个扁平的环境。

计划或设计的网络区域：

| 区域 | 用途 | 状态 |

|---|---|---|

| 管理 | 基础设施管理界面 | 计划中 |

| 可信 LAN | 个人可信设备 | 计划中 |

| 服务器 | 自托管应用服务 | 计划中 |

| 存储 | NAS/存储和备份流量 | 计划中 |

| IoT | 信任度较低的智能设备 | 计划中 |

| 摄像头 | 摄像头/安防设备 | 计划中 |

| VoIP | FreePBX 和电话相关流量 | 计划中 |

| AI / 实验区 | AI 和实验室/测试工作负载 | 计划中 |

| 访客 | 访客访问 | 计划中 |

| 备份 | 备份和恢复流量 | 计划中 |

预期的设计遵循最小权限原则：管理界面不应当被公开暴露，且仅在需要时才允许区域之间的访问。

允许的流量模式示例（以通用方式表示）：

- 管理工作站到基础设施管理界面
- 虚拟化主机到存储/备份服务
- VPN 客户端到特定的内部服务
- 监控系统到服务健康状态端点
- VoIP 设备到 VoIP 服务器

确切的防火墙规则、内部地址和真实的网络细节被刻意不公开。

为了避免 VPN 路由冲突，家庭网络避开了诸如 `192.168.1.0/24` 等极其常见的私有范围，迁移到了一个不太常见的私有子网。确切的子网被刻意不公开。

### Wi-Fi 和访客网络

无线访问是通过配置为简单的无线接入点的 OpenWrt 路由器提供的。

该接入点提供：

- 用于可信设备的主 Wi-Fi
- 用于访客的独立访客 Wi-Fi
- 旨在减少可信设备和内部服务暴露的访客访问
- 通过 pfSense 处理的核心路由/防火墙

访客 Wi-Fi 仅在较高级别进行了记录。真实的 SSID、密码、MAC 地址、内部寻址以及确切的访问规则被刻意不公开。

### 客户端和终端设备

该实验室还包含不同类型的客户端和终端设备，因为故障排除和网络设计不仅仅是服务器端的。

终端类型包括：

| 终端类型 | 用途 | 备注 |

|---|---|---|

| 台式工作站 | 主要管理和日常使用系统 | 用于 SSH 访问、文档编写、Git 工作流、测试和服务管理 |

| 笔记本电脑 | 移动客户端和备用管理设备 | 用于测试从其他客户端的访问，以及在不同网络位置进行工作 |

| 智能手机 | 移动访问和用户设备测试 | 用于检查 VPN 访问、移动 Web 访问、通知和真实用户行为 |

| 远程访问设备 | 可信的远程笔记本电脑、智能手机或平板电脑访问 | 由于 CGNAT 的存在，目前主要使用 Tailscale 通过 VPN 式访问连接回特定的内部服务 |

| IoT / 智能设备 | 信任度较低的终端类别 | 旨在通过未来基于 VLAN 的分段实现更清晰的隔离 |

| 访客设备 | 访客访问 | 旨在与可信设备和内部服务保持隔离 |

| VoIP 客户端 / 电话 | 电话终端类别 | 与 FreePBX 和计划的 VoIP 网络隔离相关 |

Road warrior 设备（在此实验室中也称为远程访问设备）是可信的远程客户端，如笔记本电脑、智能手机或平板电脑，它们通过 VPN 式访问连接回选定的内部服务。在当前的设置中，由于 Internet 连接位于 CGNAT 之后，因此使用 Tailscale 进行此操作，而以前使用的是 WireGuard。这些设备区别于本地可信 LAN 客户端，因为它们可能是从外部或不太受信任的网络进行连接的。

目标是根据设备的信任级别区别对待它们。管理系统、可信个人设备、访客客户端、IoT 设备和 VoIP 设备不应当对内部服务拥有相同的访问级别。

目前，这仅在较高级别进行了记录。真实的设备名称、MAC 地址、SSID、用户信息、内部地址以及确切的访问规则被刻意不公开。



## 主要技术

### Linux 和平台

- Debian
- Ubuntu Server
- Proxmox VE
- Proxmox Backup Server
- TrueNAS
- Raspberry Pi OS

### 网络和安全

- 作为边缘防火墙/路由器平台的 pfSense
- pfSense 软件包：pfBlockerNG、Suricata、ACME 和 HAProxy
- OpenWrt
- DHCP
- DNS
- pfBlockerNG
- Tailscale
- WireGuard
- 防火墙策略设计
- SSH 安全加固
- TLS 证书
- Cloudflare DNS
- ACME / Let's Encrypt
- HAProxy
- Suricata
- 使用 Kali Linux、nmap、Wireshark 和授权的网络/服务暴露检查进行的基础防御性安全实验室实践

### 容器和服务

- Docker
- Docker Compose
- Uptime Kuma
- Grafana
- Prometheus
- Nextcloud
- Syncthing
- Vaultwarden
- Joplin
- Jellyfin
- SearXNG
- Ollama
- Open WebUI
- FreePBX

### 管理和故障排除工具

- systemd
- journalctl
- cron
- 基于 SSH 密钥的管理 / scp / rsync
- Bash 脚本编写
- ping
- dig
- nslookup
- traceroute
- nmap
- tcpdump
- Wireshark



## 我的构建工作

- 安装和维护 Linux 服务器环境
- 使用 Docker Compose 部署自托管应用程序
- 使用 pfSense HAProxy 软件包为多个服务配置反向代理访问
- 通过 Cloudflare 管理 DNS 记录和域名路由
- 使用 pfSense ACME 软件包 / Let's Encrypt 工作流管理 TLS 证书
- 使用 Tailscale 以及之前的 WireGuard 配置 VPN 式远程访问
- 使用 pfSense 配置路由、DHCP/DNS、pfBlockerNG DNS/IP 过滤、Suricata 可见性、防火墙概念和服务访问规则
- 使用 OpenWrt 作为无线接入点
- 使用 TrueNAS 和快照构建并操作存储工作流
- 使用 Proxmox VE 进行虚拟化，使用 Proxmox Backup Server 进行备份工作流
- 使用 Uptime Kuma、Grafana 和 Prometheus 进行监控和状态可视化
- 使用日志、服务状态检查和网络工具排除故障
- 为维护任务创建简单的 Bash 脚本
- 记录服务角色、架构决策和恢复规划



## 备份与恢复策略

备份设计将服务恢复、文件恢复、配置恢复和灾难恢复分离开来。

| 备份层 | 用途 | 状态 |

|---|---|---|

| Proxmox Backup Server | VM/容器备份和恢复工作流 | 已实施 |

| TrueNAS 快照 | 存储数据集的本地回滚 | 已实施 |

| 导出的配置备份 | 恢复 pfSense、TrueNAS、Docker 和应用程序配置 | 已实施 |

| 异地加密备份 | 保护重要的小文件和配置数据 | 已针对选定的关键数据实施 |

| 离线备份介质 | 防范勒索软件或意外删除 | 计划中 |

| 恢复测试 | 验证备份是否确实可以恢复 | 计划中 |

### 数据优先级

| 数据类型 | 备份优先级 |

|---|---|

| 密码库、文档、照片、配置文件 | 关键 |

| 服务数据库和应用程序配置 | 高 |

| 媒体元数据和应用程序状态 | 中 |

| 临时文件、缓存、转码、生成的数据 | 低 / 一次性 |

长期目标不仅是创建备份，还要测试恢复过程并记录恢复步骤。



## 安全实践

在这个自行管理的实验室中，安全被视为核心设计目标。

已实施的做法包括：

- 针对内部和管理服务的 VPN 优先访问模型
- 不公开暴露防火墙、NAS、Hypervisor 或备份管理界面
- 在适当的情况下使用基于 SSH 密钥的管理进行服务器访问
- 在受管理的 Linux 主机上禁用或减少基于密码的 SSH 登录，持续进行安全加固
- 为 Web 服务提供 TLS 证书
- 通过 pfSense 中的 pfBlockerNG 管理 DNS/IP 过滤
- 使用密码管理器
- 通过 pfSense 实现 Suricata IDS/IPS 可见性
- 定期审查暴露的端口和服务访问
- 从公开文档中排除敏感值

计划或正在改进的做法：

- 在添加可管理交换机硬件后，通过 VLAN 实现更强大的分段
- 更系统化的防火墙区域文档
- 离线备份介质
- 正式的备份恢复测试
- 更多脱敏的配置示例
- 通过评估将 Pi-hole 用于 DNS 过滤，以及在 pfSense 之外使用专用的反向代理/ACME 工作流来减少服务耦合



## 监控与故障排除

监控和故障排除通过服务检查、日志、仪表板和网络工具进行处理。

典型的检查包括：

- 防火墙/路由器可达性
- Proxmox 主机可达性
- TrueNAS 可用性
- DNS 健康
- Internet 连接
- 备份服务器可用性
- 服务运行时间
- 反向代理状态
- TLS 证书状态
- VoIP 服务可用性

典型的故障排除命令：


systemctl status <service>

journalctl -u <service>

docker ps

docker compose logs

dig example.com

ping 1.1.1.1

traceroute example.com

nmap -sV <host>

tcpdump -i <interface>

### 故障排除示例

这些示例都是通用化且经过脱敏处理的。

#### DNS 过滤/解析问题

当 DNS 过滤或名称解析表现不符合预期时，我会检查客户端 DNS 设置、pfSense/pfBlockerNG 配置、上游解析器行为，以及来自 `dig` 和 `nslookup` 等工具的命令行输出。这有助于将客户端问题与防火墙/DNS 解析器问题区分开来。

#### 反向代理或 TLS 问题

当无法通过域名访问自托管服务时，我会检查 DNS 记录、Cloudflare 设置、HAProxy 前端/后端路由、证书状态、服务可用性和防火墙暴露情况。这使得确定故障是由 DNS、TLS、反向代理配置还是后端服务本身引起成为可能。

#### Docker 服务故障

当容器化服务失败或变得不可用时，我会检查 `docker ps`、`docker compose logs`、暴露的端口、数据卷、环境配置、重启策略以及底层主机资源。我还会验证是服务本身故障，还是反向代理或网络路径出现了实际问题。

#### VPN / CGNAT 访问变更

在迁移到 CGNAT 之后，直接的入站访问变得不再那么实际。我调整了远程访问方法，使用 Tailscale 对内部服务进行 VPN 式访问，而不是仅仅依赖直接的端口转发。

#### 备份和恢复规划

对于重要的服务和配置数据，我将 VM/容器备份、存储快照、导出的配置备份以及选定的异地加密备份分离开来。下一个改进方向是正式的恢复测试和已记录的恢复步骤。



## 文档实践

本仓库旨在以清晰专业的方式记录基础设施决策。

已包含或计划中的文档：

- 架构概览
- 网络分段计划
- 服务部署表
- 备份策略
- 恢复检查清单
- 脱敏的 Docker Compose 示例
- 脱敏的反向代理示例
- 故障排除说明
- 主要基础设施变更的变更日志

计划中的文档文件：


docs/

  architecture.md

  services.md

  backup-strategy.md

  troubleshooting.md

  security.md



## 脱敏示例

本仓库可能包含配置模式的脱敏示例，但不包含实际的生产环境配置。

计划中的示例：


examples/

  docker-compose-redacted.yml

  reverse-proxy-redacted.cfg

  backup-checklist.md

所有示例都应当移除或替换：

- 真实的域名
- 凭据
- Token
- 公网 IP 地址
- 私钥
- 确切的内部地址
- 确切的生产环境防火墙规则
- 未经脱敏处理的 `.env` 文件



## 我学到了什么

该项目帮助我积累了以下方面的实践经验：

- Linux 服务器管理
- 使用 Proxmox 进行虚拟化
- Docker Compose 服务部署
- 反向代理和 TLS 管理
- DNS、DHCP、VPN、防火墙和路由概念
- 使用 TrueNAS 和 Proxmox Backup Server 进行存储和备份规划
- 监控和运行时间检查
- 具备安全意识的自托管
- 技术文档编写
- 系统化地排查服务故障
- 向非技术用户解释技术基础设施

具体经验教训：

- 每次只检查一层，故障排除就会更容易：DNS、防火墙、反向代理、后端服务、日志和主机资源。
- 只有在规划并测试了恢复过程时，备份才具有价值。
- 公开暴露管理界面不值得冒这个险；对于内部服务而言，VPN 优先的访问方式更安全。
- 编写文档有助于避免在问题再次出现时重复相同的调查过程。
- 将已实施、计划中和实验性的组件区分开来，可以避免夸大其词，并使项目更容易解释。



## 当前重心

- 准备 LPIC-1 认证
- 改进基础设施文档
- 扩展备份和恢复测试
- 发布脱敏的配置示例
- 改进监控和告警
- 保持内部服务位于 VPN 式访问之后，并对刻意暴露的服务进行安全加固
- 计划使用可管理的交换机硬件实现基于 VLAN 的网络分段
- 通过评估将 Pi-hole 用于 DNS 过滤以及在 pfSense 之外采用专用的反向代理/ACME 工作流，以减少 pfSense 的服务耦合
- 构建一个由实用的 Linux 和网络项目组成的干净作品集

标签：AI风险缓解, Docker 部署, Linux系统管理, pfSense防火墙, Proxmox虚拟化, 容器化部署, 版权保护, 网络运维, 自定义请求头, 自托管基础设施