Linux on 亂筆

Terraform IaC 初體驗

Thu, 09 Apr 2026 07:13:35 +0000

Terraform 是一款 IaC 工具，所謂 IaC 就是「基礎設施即代碼」，將我們的基礎設施以聲明式的代碼寫出來，隨後使用terraform apply即可完成基礎設施的部署，同一份配置，部署出來的一定是一模一樣的基礎設施（Nix OS 用戶狂喜）。

為什麼要用 Terraform

傳統的基礎設施管理絕大部分基於人力和各種雲服務商的 Dashboard，這就帶來了下面這些痛點：

痛點	說明
難以重現	通過 Dashboard 點點點進行配置，容易改錯或者改漏，而且難以復現
環境漂移	手動操作導致生產和測試環境配置逐漸偏離，導致極端情況下測試沒問題生產直接崩
難以擴展	新增一套環境需要重複大量手工操作，耗時且容易出錯
難以審計	沒有變更記錄，~~出了事不好甩鍋~~
難以協作	基礎設施由少數「懂的人」掌控，誰想要改都得去找這些人，效率低

為了解決這些問題，「基礎設施即代碼」¹的概念被提了出來，Terraform 就是其中一個著名的解決方案。

假設一個現實的使用場景，例如你每年都會購買新的 GCP 的 $300 試用金賬號，雖然便宜，但是每年都要重新跑到 GCP 的面板裡開機器。而有了 Terraform，想要部署同樣配置的機器，只要在每次更換賬號之後，將 API Token 替換成新的，隨後terraform apply，只需要幾分鐘就能開出和你上個賬號一模一樣的機器、VPC、S3、防火牆配置等等。

再比如 Cloudflare DNS 和 Tunnel 的管理和遷移，也只需要將原 Tunnel 的 Ingress Rule 複製到新 Tunnel 的 Ingress Rule。即使將來要遷移到 AliDNS、Route 53 等其他服務商，我們也可以原封不動的將數據複製過去²。

尤其是到了多人協作的時候，配合 Git，每次更改都有跡可循，更不需要擔心合併衝突，PR 可以自動生成更改預覽，出現問題可以立刻回滾到上一個版本，這些都是傳統依賴人力去直接操作服務提供商 Dashboard 的做法完全無法做到的。

Terraform 的安裝

Terraform 是用 Go 寫的，編譯出來的產物自然也是單個可執行文件，所以安裝起來也非常容易，Windows 下可以直接使用 Winget 安裝：

winget install Hashicorp.Terraform

如果不想使用 Winget，也可以使用 Scoop 等其他包管理器，或者將預編譯的二進制文件放入$PATH，即可完成安裝。

如果你在 Linux 環境下，則使用對應的包管理器安裝即可，如果使用將二進制文件放入$PATH的安裝方法，則要記得sudo chmod +x terraform賦予文件的執行權限。

Terraform 的兩個基本概念

Provider(s)

我們前面已經提到，Terraform 是一個款礎設施即代碼工具，作為一個工具本身，他並不綁定某個平臺，而是通過 Provider(s) 與各個平臺對接，要查看有哪些 Provider(s)，可以瀏覽 Terraform 的 Registry。

狀態管理

Terraform 將每次執行基礎設施變更操作時的狀態信息保存在一個狀態文件中，默認情況下會保存在當前工作目錄下的terraform.tfstate文件裡³，我們也可以修改配置文件自行指定其他的存儲後端，例如 S3、Postgres。每次我們執行terraform apply時，Terraform 都會將目前配置文件聲明的狀態同現有的狀態文件進行比對，從而計算變動的部分，自動確定調整順序之後操作 Provider 落實狀態變動。

Terraform 的資源導入難題

現有資源的導入一直是 Terraform 為人詬病的難題，Hashi Corp. 似乎一直在堅持著一個固執且愚蠢的觀點：你所有的基礎設施從一開始就應當是用我們的 Terraform 創建的，所以也不存在什麼資源導入的問題。

時間	版本	進展	問題
2014–2022	v0.x–v1.4	只有 `terraform import`，一次一條，而且完全不生成配置	導入完還得自己手寫 HCL⁴
2023.06	v1.5	引入 `import` 塊和 `-generate-config-out`參數，可以生成配置了	然而還是得一條一條寫，而且還得自己提供現有資源的 ID
2024.01	v1.7	`import` 塊支持 `for_each`	批量了，但 ID 還得自己搞
2024 下半年	v1.12	引入了 `terraform query` 和 `list` 塊，終於實現了自動發現資源的功能	然而這個功能要 Provider 要自己實現，大量 Provider 根本沒跟上

這麼多年的時間，社區一直在罵，然而，「我有一堆現有資源，怎麼導入 Terraform」這個問題一直沒有被認真對待。Terraform 作為「基礎設施即代碼」工具，設計哲學就是聲明式和冪等性⁵，Hashi Corp. 他們篤信「一切以代碼聲明的狀態為準，就應該用 Terraform 從零開始創建資源」。但現實是絕大多數公司都有大量歷史存量資源，先有資源、後有代碼才是常態。這個矛盾 Hashi Corp. 承認得很晚，v1.12 的 terraform query 才算是官方第一次認真面對這個問題——但 Provider 生態的跟進嘛……真的是一言難盡。

Terraform 的文件結構

Terraform 的文件結構很簡單，其主程序運行時會無腦讀取工作目錄下所有的.tf文件，只要信息齊全，想給文件取什麼名字都可以，比如我的文件結構就長這樣：

❯ tree -a -I .git
.
├── .editorconfig
├── .github
│   ├── dependabot.yml
│   └── workflows
│       ├── terraform-apply.yml
│       ├── terraform-plan.yml
│       └── your-fork.yml
├── .gitignore
├── .terraform.lock.hcl
├── cf_dns_zones.tf
├── cf_tunnel.tf
├── dns_example_com.tf
├── dns_example_net.tf
├── dns_example_top.tf
├── dns_example_cn.tf
├── main.tf                 # 基礎配置（terraform 塊）
├── moved.tf                # 移動過的資源
├── provider.tf             # 每個 Provider 的配置
├── README.md
├── rename_resources.ps1
└── variables.tf            # 自定義的變量

main.tf用於存放基礎配置:

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5"
    }

    tencentcloud = {
      source  = "tencentcloudstack/tencentcloud"
      version = ">= 1.81.43"
    }
  }
}

provider.tf用於存放每個 Provider 的配置：

provider "cloudflare" {}
provider "tencentcloud" {}

這裡留空是因為我們可以通過環境變量來傳遞 Credentials，而不是直接將 Credentials 寫在配置文件中，例如 Cloudflare 的 Provider 就接受CLOUDFLARE_API_TOKEN作為api_token這個變量的替代。

variables.tf用於聲明自定義的變量：

variable "cloudflare_zone_example_com" {
  description = "Cloudflare zone ID for example.com"
  type        = string
}

variable "cloudflare_zone_example_top" {
  description = "Cloudflare zone ID for example.top"
  type        = string
}

這些變量可以通過前綴為TF_VAR_的環境變量傳入，Terraform 也會自動讀取terraform.tfvars文件中的變量，變量的主要用途是在別的配置文件中調用，例如：

resource "cloudflare_dns_record" "example_cname" {
  content = "${cloudflare_zero_trust_tunnel_cloudflared.Production_Tunnel.id}.cfargotunnel.com"
  name    = "example.example.com"
  proxied = true
  tags    = []
  ttl     = 1
  type    = "CNAME"
  zone_id = var.cloudflare_zone_id_example_com  #這裡調用了cloudflare_zone_example_com這個變量
  settings = {
    flatten_cname = false
  }
}

有了這些基礎配置，我們就可以運行terraform init初始化 Terraform 環境並鎖定依賴版本，剩下的就都是我們資源的聲明瞭。

將現有資源導入 Terraform

前文提到過 Terraform 的狀態管理這個概念，狀態管理雖好，但在我們初始化時也帶來了一個問題——在默認狀態下，Terraform 的狀態文件顯然是空的。

此時我們需要做的是將雲服務提供商上現有資源的狀態導入 Terraform，這樣 Terraform 才能無縫接手並管理我們的基礎設施。相信大家也都看到了前文對 Terraform 資源導入問題的吐槽。以導入 Cloudflare 上託管的 DNS 記錄為例，前文提到過，如果 Provider 支持，可以使用 Terraform 在 1.12 版本之後引入的terraform query，然而大多數情況下，Providers 都是沒有跟進這個新功能的，Cloudflare 就屬於不支持的那一類。

好在雖然 Hashi Corp. 不認真解決問題，各路高強度使用 Terraform 管理基礎設施的公司就各顯神通。Cloudflare 就維護了名為 cf-terraforming 的導入工具，免去了很多手動導入的麻煩。首先安裝cf-terraforming，這個工具是用 Go 語言編寫的，需要在有 Go 語言環境的情況下安裝，或者將官方編譯好的二進制文件其放入$PATH並賦予其執行權限。

go install github.com/cloudflare/cf-terraforming/cmd/cf-terraforming@latest

這個工具的用法還是比較簡單的，首先你需要以下環境變量：

# 如果你使用 API Token
export CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

# 如果你使用 API Key
export CLOUDFLARE_EMAIL='user@example.com'
export CLOUDFLARE_API_KEY='1150bed3f45247b99f7db9696fffa17cbx9'

# 指定需要導入的域名的區域 ID，如果導入的是賬戶資源（例如 Cloudflare Tunnel）則不需要
export CLOUDFLARE_ZONE_ID='81b06ss3228f488fh84e5e993c2dc17'

💡 提示
此處的命令假設你正在使用 Bash，如果使用的是與 Bash 語法不兼容的 Shell，則需要做出調整，例如對於 Windows 上的 PowerShell，導入環境變量的語法如下：
$env:CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

通常我們只需要設置CLOUDFLARE_API_TOKEN和CLOUDFLARE_ZONE_ID就可以了，在控制檯創建 API Token 時，記得賦予這個 Token 必要的權限，本次我們只是導入 DNS 記錄，所以只賦予編輯區域 DNS 的權限即可。

好了，準備工作全部完成，現在可以開始生成配置文件：

首先導入賬戶中域名的配置，也就是cloudflare_zone：

cf-terraforming generate \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_zone" > zone.tf

這一步會在當前目錄下生成一個名為zone.tf的文件，裡面會有如下格式的內容：

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

現在域名資源已經導入了，但是裡面的配置並沒有。接下來，導入域名下的 DNS 記錄：

cf-terraforming generate \
  --zone $CLOUDFLARE_ZONE_ID \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_dns_record" >> dns.tf

這一步會在當前目錄下生成一個名為dns.tf的配置文件，裡面會有如下格式的內容：

resource "cloudflare_dns_record" "terraform_managed_resource_5deb14xxxxxb629bf123xxxxxxxc8f_0" {
  content  = "67.24.33.108"
  name     = "example.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "81c7f2de8dfxxxxxx52629xxxxxxfc"
  settings = {}
}

resource "cloudflare_dns_record" "terraform_managed_resource_89xxxxx0bf9cxxxxxx9a_1" {
  content  = "35.27.108.33"
  name     = "terraform.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "8xxxxxx7644e428526xxxxxx"
  settings = {}
}

如果有多個域名需要導入，則多次分別設置環境變量CLOUDFLARE_ZONE_ID再重複運行命令即可。

這裡生成的配置文件可以直接使用，也就是我們之後需要的 Terraform 配置文件。然而，此時我們僅僅只是生成了配置文件，但是目前 Terraform 的狀態依然是空的，這時要是直接terraform apply，Terraform 會不管三七二十一將我們剛剛導入的聲明一律視為新增資源，然後甩出一大堆「Alredy Exists」報錯。所以接下來，我們需要將生成的配置文件導入 Terraform 的terraform.tfstate狀態。

Terraform 在 1.5 版本引入了import塊，相比以往一行一行輸入命令的方式更加現代。其導入流程是先生成一個包含import塊的.tf文件，下次進行terraform apply時，Terraform 就會自動為我們執行導入操作。

生成cloudflare_zone的import塊：

cf-terraforming import \
  --resource-type "cloudflare_zone" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

生成cloudflare_dns_record的import塊：

cf-terraforming import \
  --resource-type "cloudflare_dns_record" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

這一步會在當前目錄下生成import.tf，它包含了所需要的導入信息，作用就是告訴 Terraform 上一步生成的每個resource塊到底對應的是哪一個雲服務提供商的資源 ID。這個 ID 是雲服務提供商內部標記資源的代碼，平常是不會在控制面板上顯示的，只有在用 API 特別請求時才會知道。Terraform 在導入過程中需要用到這個 ID 以確認本地的定義對應的雲端資源，以實現嚴格的冪等性。

好了，現在我們運行terraform plan：

$ terraform plan
cloudflare_dns_record.minio_a: Refreshing state... [id=xxxxxxxxxxx53]
cloudflare_zero_trust_tunnel_cloudflared_config.raspberrypi: Refreshing state...
......

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "5deb14c21xxxxxxx20f1c8f"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_89c149exxxxxxxxxxxba13xxxxxa_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "89cxxxxxxxxxxxxxxxxxx09a"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "81xxxxxxxxxxxxxxxxxxxxxfc"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.

────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly
these actions if you run "terraform apply" now.

如果需要 Add、Change 和 Destroy 的資源數量都是 0，說明我們的導入操作沒有問題，直接terraform apply --auto-approve，資源就導入完成了。

$ terraform apply --auto-approve
cloudflare_dns_record.push_a: Refreshing state... [id=REDACTED]

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Import complete [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Import complete [id=REDACTED/REDACTED]

Apply complete! Resources: 2 imported, 0 added, 0 changed, 0 destroyed.

狀態存儲和持續集成

IaC 的核心價值之一就在於可以輕易實現基於 Git 的多人協作，以及 CI 的持續集成，但是在此之前，又有一個新的問題需要解決——terraform.tfstate到底放哪裡：沒人想要換一次環境辛辛苦苦導入的狀態就丟一次。

Terraform 目前支持以下幾種保存狀態的後端：

local
remote
azurerm
consul
cos
gcs
http
Kubernetes
oci
oss
pg
s3

沒有特殊需求可以像我一樣選擇s3，畢竟 Cloudflare R2 有免費額度，不用白不用。

terraform {
  backend "s3" {
    bucket = "terraform"
    key    = "terraform.tfstate"
    region = "auto"
    endpoints = {
      s3 = "https://REDACTED.r2.cloudflarestorage.com"
    }

    # R2 不需要這些 AWS 的驗證
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    use_path_style              = true
  }
}

對於 S3 的後端，建議用AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY兩個環境變量來存儲 Credentials：

export AWS_ACCESS_KEY_ID='REDACTED'
export AWS_SECRET_ACCESS_KEY='REDACTED'

配置完成，運行terraform init -migrate-state，配置就成功存儲到雲上了，以後不論在何處修改配置、運行terraform apply都無須擔心 Terraform 的 State 不同步的問題。

接下來就是 Github CI 的配置，其實很簡單，無非就是每次git push時觸發一次terraform init、terraform fmt和terraform apply，以下是我的.github/workflows/apply.yml：

name: "Terraform Apply"

on:
  push:
    branches:
      - main

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: "${{ secrets.CLOUDFLARE_API_TOKEN }}"
  AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
  AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  terraform:
    name: "Terraform Apply"
    runs-on: ubuntu-latest
    permissions:
      contents: read
    concurrency:
      group: terraform-apply
      cancel-in-progress: false
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v4

      - name: Terraform Init
        run: terraform init -input=false

      - name: Terraform Apply
        run: terraform apply -input=false -auto-approve

對於 PR 則應當讓 CI 自動為每次 PR 附上terraform plan的輸出：

name: Terraform Plan

on:
  pull_request:
    paths:
      - "**/*.tf"
      - ".github/workflows/terraform-plan.yml"

permissions:
  contents: read
  pull-requests: write

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  plan:
    name: Terraform Plan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: hashicorp/setup-terraform@v4

      - name: Terraform fmt
        id: fmt
        run: terraform fmt -check -recursive
        continue-on-error: true

      - name: Terraform Init
        id: init
        run: terraform init -input=false

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        run: terraform plan -input=false -no-color
        continue-on-error: true

      - name: Post Plan to PR
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            const botComment = comments.find(c =>
              c.user.type === 'Bot' && c.body.includes('')
            );

            const planOutput = `${{ steps.plan.outputs.stdout }}`.substring(0, 65000);

            const body = `
            #### Terraform Plan

            | Step     | Result                            |
            | -------- | --------------------------------- |
            | fmt      | \`${{ steps.fmt.outcome }}\`      |
            | init     | \`${{ steps.init.outcome }}\`     |
            | validate | \`${{ steps.validate.outcome }}\` |
            | plan     | \`${{ steps.plan.outcome }}\`     |

            展開 Plan 詳情

            \`\`\`terraform
            ${planOutput}
            \`\`\`
            `;

            if (botComment) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: botComment.id,
                body
              });
            } else {
              await github.rest.issues.createComment({
                issue_number: context.issue.number,
                owner: context.repo.owner,
                repo: context.repo.repo,
                body
              });
            }

      - name: Fail if plan failed
        if: steps.plan.outcome == 'failure'
        run: exit 1

後續的工作流程

到這一步，Terraform 的「接管初始化」已經結束了，後面就進入了日常維護階段。這個階段其實就三件事：

創建新資源
修改現有的資源
刪除不再需要的資源

常用的操作就兩個：terraform plan和terraform apply，如果是個人使用，小的改動直接提交就算了；如果是團隊協作，每次修改則應當遵循能 PR 就不直接 Commit 的原則。

創建基礎設施

假設你現在要新增一條 DNS 記錄，或者新建一個 Tunnel、一個對象存儲桶，流程如下：

flowchart TD
  C1[新建分支
如 feat/add-minio-record] --> C2[新增 resource 塊]
  C2 --> C3[terraform fmt + validate]
  C3 --> C4[terraform plan]
  C4 --> C5{僅新增預期資源?}
  C5 -- 否 --> C6[修正配置後重跑 plan]
  C6 --> C4
  C5 -- 是 --> C7[提交 PR]
  C7 --> C8[合併後 CI apply]

最理想的plan輸出是：

X to add
0 to change
0 to destroy

如果你只是想加東西，結果出現了to destroy，那就先別衝動，通常是引用寫錯、變量搞錯，或者不小心改了資源地址，仔細檢查是什麼地方出了問題。

修改與刪除基礎設施

修改流程和創建類似，但要多一步——評估變更是否會觸發重建。

因為很多 Provider 字段是ForceNew，你以為只是改個字段，Terraform 看完說：「好的，刪了重建。」這在我們修改 DNS 的這個場景並不是什麼很大的問題，但是到了雲實例這種資源，如果刪除重建勢必會造成損失。

建議按下面這個順序來：

flowchart TD
  M1[修改 .tf] --> M2[terraform plan]
  M2 --> M3{出現 replace/destroy?}
  M3 -- 否 --> M7[確認影響範圍]
  M7 --> M8[terraform apply]
  M3 -- 是 --> M4[暫停並複核變更]
  M4 --> M5[必要時加 lifecycle 保護]
  M5 --> M6[安排變更窗口]
  M6 --> M8

對生產環境來說，創建、修改得慢一點並不是什麼很大的問題，最應當看重的是操作的正確性，慢一點，不要出錯。IaC 不是比手速，IaC 比的是可預期性。

如果是刪除資源（比如下線某個 DNS 記錄、清理廢棄 Tunnel），走下面這個流程⁶：

flowchart TD
  D1[確認資源已廢棄
  檢查業務/監控/腳本依賴] --> D2[刪除 resource 塊或調整 count/for_each]
  D2 --> D3[terraform plan]
  D3 --> D4{to destroy 是否符合預期?}
  D4 -- 否 --> D5[回滾修改並繼續排查依賴]
  D5 --> D1
  D4 -- 是 --> D6[準備回滾方案並選低峰窗口]
  D6 --> D7[PR 審核通過]
  D7 --> D8[terraform apply]
  D8 --> D9[刪除資源後的可用性檢查]

日常協作建議

把 Credentials 放環境變量或 CI Secret，別寫進.tf和倉庫
對關鍵資源開啟保護策略，防止誤刪
將目錄按資源類型拆分
定期執行terraform plan做基礎設施漂移檢查⁷和校正，避免在面板誤操作手動修改

雖然這套流程看起來很麻煩，但每一次變更都有記錄、可審計、可回滾，最重要的是可復現，這才是 IaC 最有價值的地方。

參考

Infrastructure as Code，是指採用機器可讀的配置文件定義所需要的基礎設施的部署方法。 ↩︎
每個供應商的配置文件字段命名和格式都有區別，但這可以很容易的編寫腳本進行轉換。 ↩︎
需要特別注意的是，狀態文件中可能包含數據庫密碼、API 密鑰等明文存儲的敏感信息，因此絕對不要將 .tfstate 文件提交到公開的代碼倉庫中。 ↩︎
HashiCorp Configuration Language，HashiCorp 自家開發的一種聲明式配置語言，旨在兼顧機器可讀性與人類可讀性。 ↩︎
冪等性（Idempotence）指計算機系統或接口在接收到同一請求的多次操作時，產生的影響與一次執行的結果相同，不論執行多少次，系統的最終狀態始終保持一致。 ↩︎
如果你僅僅是想讓 Terraform 不再管理某個資源，而不是真正在雲端銷燬它，應該使用 terraform state rm 命令，而不是在代碼中刪掉資源塊然後 apply，否則雲環境上的真實資源也會被一併銷燬。 ↩︎
基礎設施漂移（Infrastructure Drift）是指現實中通過控制檯點按等非 IaC 途徑修改了基礎設施，導致其實際狀態與代碼中聲明的狀態不一致的情況。 ↩︎

從入門到進階：Tailscale + ShellCrash 異地組網和科學上網

Mon, 14 Apr 2025 10:10:25 +0000

在幾次旅途中，我試圖將新拍的照片上傳到長沙家中的 Immich 服務器。過去我用 Cloudflare Tunnel 做反代，但由於國內特殊的網絡環境，連接慢速、頻繁中斷、上傳失敗幾乎成了常態。後來我開始嘗試 Tailscale —— 一個基於 WireGuard 的內網穿透工具，它終於讓我在全國各地都能穩定、高速地訪問家中的 NAS 和照片庫。

但新的問題也隨之而來：Tailscale 在 Android 手機上運行時，需要作為 VPN 服務接管系統流量，而我平時使用的 Clash 同樣依賴 VPN 接口進行分流。由於 Android 系統限制（只能啟用一個 VPN 服務），兩者無法共存，導致我必須在「訪問家中服務」和「科學上網」之間二選一。

這篇文章從 Tailscale 的原理講起，到自建 DERP 服務器優化連接質量，再到如何用 iptables 劫持 Tailscale Exit Node 的流量並轉發給 ShellCrash，實現流量的靈活轉發與安全穿透。無論你是想訪問家庭局域網上的 NAS、照片庫，還是希望在陌生網絡中保護自己的數據安全，這篇文章都能為你提供一套實用、穩定的解決方案。

什麼是 Tailscale

Tailscale 是一款基於 WireGuard 協議的零配置虛擬局域網工具，它能夠讓分佈在不同網絡環境中的設備像處於同一個安全內網中一樣互聯互通。通過自動穿透 NAT、防火牆等網絡障礙，Tailscale 讓你無需公網 IP、無需端口轉發，也能輕鬆訪問家中的 NAS、個人服務器、開發環境等內網資源。它的核心優勢在於簡單、安全、穩定，啟動即用，數據傳輸全程加密，適合個人開發者、遠程辦公者、家庭用戶等多種場景使用。

Tailscale 的技術實現非常巧妙：其構建在 WireGuard 加密協議之上，卻顛覆了傳統 VPN 的 IP 分配邏輯。每個設備通過 SSO/OAuth2 完成身份認證後，會獲得一個終身綁定的節點密鑰。這種基於身份的組網模式，讓「長沙的 NAS」和「香港的手機」在虛擬網絡中如同辦公室同事般直接對話。

Tailscale 的連接過程原理

中心控制服務器（Control Server）

每個 Tailscale 客戶端在啟動後，首先會連接控制服務器（controlplane），進行身份驗證，並拉取整個網絡中其他節點的信息，包括每臺設備的公網 IP、端口、NAT 類型等。這一步相當於是「認識朋友」。

Tailscale 的控制服務器不會轉發任何數據，只負責協調連接 —— 類似一個調度中心。

DERP 服務器

說到 Tailscale 能保持高連接成功率的關鍵，就不得不提到 Tailscale 自研的中轉協議 DERP，在 Tailscale 的網絡架構裡，DERP（Designated Encrypted Relay for Packets）是一個很重要但通常只在必要時介入的組件。簡單來說，它就是一個基於 HTTP 的加密中繼服務器，用來在兩臺設備無法直接通信時，作為它們之間的「中轉站」。

所有客戶端之間的連接都是先選擇 DERP 模式（中繼模式），這意味著連接立即就能建立，用戶無需等待。然後連接雙方開始並行地進行路徑發現，通常幾秒鐘之後，Tailscale 就能發現一條更優路徑，然後將現有連接透明升級（upgrade）過去，變成點對點連接（直連）。¹

需要注意的是：

所有通過 DERP 的數據都是端到端加密的，DERP 服務器無法查看內容；
Tailscale 會盡可能少地使用 DERP，一旦直連建立成功，就會自動切換過去；
官方部署了多個分佈式 DERP 節點，客戶端會自動選擇延遲最低的那個；
你也可以自建 DERP 節點（比如在國內），來解決延遲高或連接不穩定的問題。

可以把 DERP 理解為一個兜底機制，雖然性能不如直連，但確保了即便不能打洞成功，設備之間也始終能保持連接。

NAT 穿透（NAT Traversal）

拿到對端的地址信息後，Tailscale 會嘗試通過 NAT 穿透來建立點對點（P2P）連接。這個過程使用了 STUN 協議，雙方互相發送探測包，嘗試在 NAT 路由器上打出一條直連的通道。如果雙方的網絡條件允許，就可以成功建立起一個 UDP 的直連隧道，數據走直連，速度快、延遲低。

受制於篇幅，我無法完整細緻的講述 NAT 穿透的原理，若對這部分感興趣，可以閱讀 Tailscale 官方的「How NAT traversal works」一文。

完整連接流程圖示

flowchart TD
    A[設備 A 啟動 Tailscale] --> B[通過 DERP 服務器建立初始連接]
    B --> C[交換網絡信息和 WireGuard 密鑰]
    C --> D[雙方並行進行 NAT 類型探測]
    D --> E{能否直連？}
    E -- 是 --> F[建立 P2P 直連隧道]
    F --> G[定期檢測連接質量]
    G --> H{直連優於 DERP？}
    H -- 是 --> I[切換大部分流量至直連通道]
    H -- 否 --> J[繼續通過 DERP 轉發部分或全部流量]
    E -- 否 --> J

    style B fill:#e3f2fd,stroke:#2196f3,color:#000
    style F fill:#e8f5e9,stroke:#4caf50,color:#000
    style J fill:#fff3e0,stroke:#ff9800,color:#000

自建 DERP

Tailscale 的安裝在各個平臺上都相對簡單，官方文檔已經提供了詳細的操作指南。本文將不再贅述安裝過程，以下內容默認你已經在相關設備上成功安裝並登錄了 Tailscale。

為什麼要自建 DERP？

Tailscale 在全球部署了眾多 DERP ²中繼服務器，用於在打洞失敗時接管流量中轉。但由於眾所周知的原因，中國大陸並沒有官方部署的 DERP 節點。這意味著：

一旦 NAT 打洞失敗，所有流量都必須繞行海外的 DERP 節點，延遲高、速度慢，體驗極差；
某些官方 DERP 節點容易被 GFW 干擾，可能出現連接中斷、握手失敗等問題；
即使打洞成功，Tailscale 仍需通過 DERP 交換路由信息和 WireGuard 密鑰，如果 DERP 不可達，連接質量也會受到影響。

因此，在國內網絡環境下，自建一個本地 DERP 節點，不僅可以顯著提高連接穩定性和傳輸性能，還能規避部分網絡封鎖所帶來的不可預期問題，是一個非常值得做的優化。

準備工作

前面提到，DERP 是基於 HTTP 的，所以你需要準備好一個 HTTP 反代服務，並自行解決 SSL 證書的簽發等基礎問題。本文使用 Docker 部署，在部署開始之前，你需要在你的服務器上裝好 Docker 以及 Docker Compose 等附加組件。為了編輯配置文件，你當然也得知道如何使用 nano 之類的編輯器。為了最好的效果，你的服務器最好擁有靜態公網 IPv4+IPv6 雙棧地址。

如果以上條件都具備，就可以開始部署了。

mkdir tailscale-derp && cd tailscale-derp
nano docker-compose.yml

docker-compose.yml

services:
  derper:
    name: tailscale-derp
    image: fredliang/derper
    environment:
      - DERP_DOMAIN=derp.nightcity.pub
      - DERP_VERIFY_CLIENTS=true
      - DERP_ADDR=:4433
    network_mode: host
    restart: unless-stopped
    volumes:
      - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

network_mode: host是一個關鍵配置，表示容器將共享宿主機的網絡棧。如果使用 Docker 默認的 bridge 網絡模式，容器的網絡會經過 Docker 內網轉發，會造成 DERP 的 STUN 服務識別到 Docker 172.17.0.0/16網段下的地址，而無法識別到客戶端正確的外網地址，導致 Tailscale 客戶端無法正確連接。

volumes:
  - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

前面提到所有通過 DERP 的數據都是端到端加密的，DERP 並不知道是誰在使用，這意味著如果不採取措施，任何知道你 DERP 服務器地址和端口號的人都可以使用它。這條配置的作用是掛載宿主機的 Tailscale 套接字文件到容器內，目的是允許 derper 服務通過 Tailscale 的 tailscaled 服務進行身份驗證。配合DERP_VERIFY_CLIENTS=true，可以防止你的 DERP 節點被他人白嫖。

需要注意的是：

宿主機必須已經安裝並登陸 Tailscale 客戶端（tailscaled），否則這個文件不存在，容器會報錯；
tailscaled 必須以 root 權限運行，才能創建這個 sock 文件。

反向代理

以 Caddy 為例，需要反向代理 4433 端口，併為其部署 SSL 證書。

{
        email webmaster@l3zc.com
}

*.l3zc.com {
        encode gzip

        tls {
                dns dnspod APP_ID,APP_KEY
                resolvers 119.29.29.29 223.5.5.5
        }

        @derp host derp.l3zc.com
        reverse_proxy @derp :4433
}

需要注意的是，如果你和我一樣使用 Caddy 配合 dnsproviders 申請泛域名證書，Tailscale 的 MagicDNS 可能會導致 Caddy 本地證書驗證失敗而報錯，需要手動指定resolvers參數解決。

訪問剛剛反代的節點，如果出現以下頁面，說明配置正確。

配置 ACL 策略

打開 Tailscale 控制檯的「Access Controls」頁面配置 ACL 策略，將配置好的 DERP 加上。

Tailscale 的 ACL 策略是用 HuJSON³ 寫的，想要在 VSCode 中編輯，選擇語言為「JSON with Comments（jsonc）」即可。以下是一個配置示例：

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],

  // 自建 DERP 配置
  "derpMap": {
    "OmitDefaultRegions": false, // 改為 true 以排除官方 DERP
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale 保留RegionID中的 1-899 作為官方節點，自建節點的 RegionID 必須大於等於 900。

測試連接

配置好 ACL 並保存，Tailscale 會自動為所有客戶端同步配置，稍等片刻在客戶端用tailscale netcheck測試連接。

需要注意返回的 IP 是否是自己真實的公網 IP，若返回了172.17.0.0/16網段的地址，說明你 Docker 部分配置錯了。

與科學上網並存：在 Exit Node 劫持流量到 Clash 內核

聲明 Exit Node

在家中準備一個 24 小時開機的設備，可以是樹莓派，可以是 MacMini。在上面安裝 Tailscale 並將其聲明為 Exit Node，並根據需要在 Tailscale 內網聲明家庭內網網段，隨後在控制檯啟用這個設備作為 Exit Node，你就獲得了一個免費的 VPN，可以讓你在陌生的網絡環境中保持安全。

sudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24

廣播完成後，無論身處何地，只要能連上 Tailscale 網絡，就能訪問家中所有的內網設備。

啟用 IP 轉發和禁用 UDP GRO⁴

啟用 IP 轉發是樹莓派等設備作為 Exit Node 所必須的配置，這裡以樹莓派為例，如果你使用其他設備，請自行查閱 Tailscale 官網教程。

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

根據 Tailscale 官方的說法⁵，禁用 UDP GRO⁶ 可以提升轉發性能，但官方的持久化教程似乎在樹莓派上無效，好在我們可以手動配置。

# 安裝 ethtool
sudo apt update && sudo apt install ethtool -y

# 關閉 UDP GRO
sudo ethtool -K eth0 gro off

針對持久化的問題手動編寫 systemd 配置文件：

# 創建服務文件
sudo nano /etc/systemd/system/ethtool.service

文件內容如下：

[Unit]
Description=Configure eth0 GRO
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off

[Install]
WantedBy=multi-user.target

隨後啟動服務：

sudo systemctl daemon-reload
sudo systemctl enable ethtool
sudo systemctl start ethtool

在 Exit Node 劫持流量

我的 Exit Node 是一臺樹莓派，在樹莓派上配置好 Exit Node 之後就來到了最後一步，也就是劫持手機發送到 Exit Node 上的流量，實現科學上網。出於穩定性原因，我不希望在家庭主路由上直接運行代理軟件，為了實現這一點，直接在樹莓派上劫持流量是唯一的選擇。

首先安裝 ShellCrash，請自行根據你的需要導入配置文件、配置自動任務等：

export url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' && wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh  && bash /tmp/install.sh && source /etc/profile &> /dev/null

隨後啟動服務，修改修改防火牆運行模式為純淨模式，我個人建議將 SNI 嗅探打開，並將 DNS 模式從fake-ip切換為redir-host⁷，同時啟用 IPv6 透明代理。

設置純淨模式的目的是手動配置 iptables 以實現更精準的流量劫持。我們直接用 iptables 劫持所有 tailscale 網卡作為 Exit Node 轉發的流量，首先用ifconfig查看 tailscale 網卡的名稱，默認情況下一般為 Tailscale 0：

root@raspberrypi:~# ifconfig
eth0: ......

tailscale0: flags=4305  mtu 1280
        inet 100.111.19.50  netmask 255.255.255.255  destination 100.111.19.50
        inet6 fd7a:115c:a1e0::3d01:1332  prefixlen 128  scopeid 0x0
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 6780155  bytes 958732442 (914.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4811113  bytes 10858316472 (10.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

劫持tailscale0網卡的所有流量到本地 Clash 內核監聽端口7892，這個設置在 ShellCrash 中叫做「靜態路由端口」。以及，如果你不想和我一樣遇到莫名其妙的網絡問題，就一定不要忘記劫持 IPv6。

# IPv4 劫持 tailscale0
iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 tailscale0
ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

進階：用 TProxy 劫持 UDP 流量

iptables 的 REDIRECT 只能重定向 TCP 流量，UDP 沒有連接狀態（無連接協議），所以 REDIRECT 無法保留目標地址，導致透明代理無法知道原始目標地址。

所以，如果你用如下方式劫持 UDP 流量：

iptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892

則這個規則不會生效或代理行為不正常。

那麼，有辦法代理 UDP 流量嗎？有的兄弟，有的。但前提是：

核心支持 UDP 透明代理（Clash Premium 和 Mihomo 都支持）；
使用 TProxy 模式，而不是 REDIRECT；
正確配置了 iptables mangle 表和 policy routing；
代理配置文件中啟用了 UDP 代理（如 mode: rule + udp: true）。

假設你已經滿足第一條、第二條和最後一條，則以下是一個示例⁸：

# 創建自定義鏈
sudo iptables -t mangle -N SHELLCRASH

# 根據自己的需要忽略本地流量
sudo iptables -t mangle -A SHELLCRASH -d 127.0.0.1/8 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 100.64.0.0/10 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 192.168.1.0/24 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 172.17.0.0/16 -j RETURN

# mark UDP 和 TCP 到代理
sudo iptables -t mangle -A SHELLCRASH -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
sudo iptables -t mangle -A SHELLCRASH -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

# 路由表配置
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip rule add fwmark 233 lookup shellcrash
sudo ip route add local 0.0.0.0/0 dev lo table shellcrash

當然，不要忘記 IPv6：

# 創建鏈
sudo ip6tables -t mangle -N SHELLCRASH6

# 跳過本地地址
sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN
sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN

# 標記 TCP/UDP
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

# 路由表配置
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip -6 rule add fwmark 233 lookup shellcrash
sudo ip -6 route add local ::/0 dev lo table shellcrash

路由規則持久化

ip rule和ip route創建的規則在重啟後會丟失，所以需要我們手動持久化，最簡單直接的方法就是創建一個腳本，並將其添加至 crontab。

創建一個腳本：

sudo nano /usr/local/bin/policy-route.sh

編輯為如下內容：

#!/bin/bash

# IPv4 策略路由
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 策略路由
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

授予執行權限後編輯 Crontab：

sudo chmod +x /usr/local/bin/policy-route.sh
sudo crontab -e

在 crontab 文件底部加上如下內容：

@reboot /usr/local/bin/policy-route.sh

原理解釋：TProxy 到底是怎麼轉發 UDP 流量的？

如果你看到這裡，也許會產生疑惑：為什麼整個流程中，我們沒有在 iptables 裡寫--to-ports，也沒看到目標地址被改寫，UDP 流量就莫名其妙地被代理了？這是怎麼做到的？

要解釋這個問題，我們先來看 TProxy 和 REDIRECT 的根本區別：

REDIRECT 模式：

使用 iptables nat 表；
將目標地址改寫為本地地址（比如 127.0.0.1:7892）；
通常用於 TCP 流量；
不能保留真實目標地址；
需要指定--to-ports。

flowchart TB
    A[客戶端設備
通過 Tailscale 發起 TCP 請求]
    B[tailscale0 接口接收流量]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash 本地監聽
127.0.0.1:7892]
    E[ShellCrash 發起新 TCP 請求
→ 目標服務器]
    F[響應從網絡返回
ShellCrash 轉發響應]
    G[響應回到客戶端設備]

    A --> B --> C --> D --> E --> F --> G

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TPROXY 模式：

使用 iptables mangle 表；
不修改目標 IP，而是保留原始目標地址；
通過 fwmark 和 policy routing 將報文路由到 lo；
代理程序監聽一個特殊端口（例如 7893），並啟用 IP_TRANSPARENT；
支持 UDP 和 TCP；
不需要 iptables 內指定 --to-ports，因為不是 NAT，而是標記 + 路由。

flowchart TB
    A[客戶端設備
通過 Tailscale 發起 TCP/UDP 請求]
    B[tailscale0 接口接收流量]
    C[iptables MANGLE PREROUTING
打上 fwmark 233]
    D[ip rule: fwmark 233
使用 routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash 在 lo:7893 監聽
IP_TRANSPARENT 模式]
    G[ShellCrash 獲取原始目標地址
發起代理連接]
    H[響應從網絡返回
ShellCrash 轉發響應]
    I[響應回到客戶端設備]

    A --> B --> C --> D --> E --> F --> G --> H --> I

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TProxy 不使用 DNAT/REDIRECT，而是通過 mangle 表給數據包打上 mark，然後通過 policy routing（ip rule + ip route）將這些數據包送到 lo 接口。代理程序（如 Clash / ShellCrash）監聽在 lo⁹ 上的端口（例如 7893），通過啟用 IP_TRANSPARENT 選項，可以讀取數據包的原始目標 IP 和端口並進行代理轉發。

簡而言之，TProxy 模式只需要：

iptables 給數據包打上 mark；
ip rule + ip route 將這些包送到 lo；
程序監聽 lo 上的端口並開啟 IP_TRANSPARENT。

所以不需要在 iptables 中指定 --to-ports，因為目標 IP 和端口保持不變，代理程序自己可以感知並處理。

iptables 規則持久化

安裝iptables-persistent：

sudo apt update
sudo apt install iptables-persistent

安裝過程中會提示你是否保存當前的 IPv4 和 IPv6 配置，選擇「是」即可。之後如果你添加了新的規則，記得執行保存命令：

# 保存當前 IPv4/IPv6 規則
sudo netfilter-persistent save

保存後的規則文件路徑：

IPv4：/etc/iptables/rules.v4
IPv6：/etc/iptables/rules.v6

你也可以直接編輯上面的rules.v4/rules.v6文件，按需修改。

最終效果

這套方案的使用體驗取決於你家的上行帶寬，我家的網絡是下行 500M 上行 60M，目前沒有遇到一次打洞失敗的情況，所以基本都能跑滿，延遲也尚可接受，並且可以在外地隨時隨地端到端加密訪問家中的 Immich 和 OpenWRT 路由器等設備以及實現科學上網，總體來看，我還算比較滿意。

參考: https://icloudnative.io/posts/custom-derp-servers/ ↩︎
參考: https://tailscale.com/kb/1232/derp-servers ↩︎
有關 HuJSON: https://github.com/tailscale/hujson ↩︎
參考： https://tailscale.com/kb/1408/quick-guide-exit-nodes ↩︎
參考: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes ↩︎
UDP GRO（Generic Receive Offload）是 Linux 內核中的一種網絡優化技術，主要用於合併多個小數據包以提高處理效率。但在設備作為網絡轉發節點的使用場景下，這可能會導致轉發延遲增加和高丟包率環境下的吞吐量下降。 ↩︎
相較於fake-ip，redir-host兼容性更好，出現問題的概率更低，也不會出現開關代理之後短時間內因為fake-ip殘留而斷網的情況，所以一般情況下我建議使用redir-host搭配 GeoSite 分流規則使用。我這臺樹莓派的 DNS 上游是已經配置好的 SmartDNS，不存在 DNS 汙染的問題，體驗良好。 ↩︎
參考: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo 是 Linux 系統中默認的「迴環接口（Loopback Interface）」，在透明代理中，它不僅處理 localhost 流量，還被用來接收原本屬於外部世界的網絡連接，實現對外部流量的本地劫持和轉發。 ↩︎

OBS 多路推流折騰記：那些本不必要的麻煩

Wed, 18 Sep 2024 06:16:51 +0000

長話短說，最近我開始直播我的遊戲實況，我並不指望有多少人看，Just, Why not? 再者每個直播平臺都會有直播回放。相當於免費保存我每一次遊戲的錄像，何樂而不為？

扯遠了，如你所見，近期我有了多平臺同時直播的需求，然而 OBS 本身顯然不支持同時推流，同時也因為不支持設置代理的特點和眾所周知的原因，無法推流到 twitch.tv，於是我開始尋找解決方案。

明確需求

多路平臺同時直播
最好對性能影響小
其中一路需要推流需要代理

多路推流

多路推流有現成的插件可用：Github

在 Release 頁面下載.exe安裝包，安裝完成後記得在「停靠窗口」菜單裡勾選「多路推流」。這時候默認會彈出一個獨立窗口，可以趁這個機會順便調整一下 OBS 的佈局。

插件的設置也沒什麼好說的，用在原版 OBS 的填法在這個插件裡如法炮製即可。

Bilibili 直播姬

莫名其妙，B 站小於 50 粉絲的 Up 主只能使用直播姬開播，其他國內平臺做出類似規定者大概也不在少數，啟用第三方推流模式之後，直播面板會顯示推流的配置。此時的不需要按照直播姬給出的推流地址進行配置，因為直播姬莫名其妙的給了一個每次都會變的內網 IP，直接以127.0.0.1或者localhost替換即可。

推流到 Twitch

推流到 Twitch 則會因為 GFW 多出很多不必要的麻煩。

OBS 本身並不支持設置代理，起初我打算用 Clash 的 TAP 模式強制代理 OBS 的流量，而 Clash 的 TAP 並不監聽 rtmp 流量，宣告失敗。我決定直接架設一個轉發服務器，這個服務器需要既可以與 Twitch 通信，又可以不受 GFW 的干擾。

在網上查到一些信息，Caddy 似乎不支持 RTMP 協議，而 nginx-rtmp 插件則專門為 RTMP 協議設計。這幾乎是唯一的選擇。

部署的前提：

熟悉基本的 Linux 命令行操作。
服務器已經安裝好docker和docker compose插件。
有合適的命令行文本編輯器，比如nvim或者絕大部分 distro 自帶的nano。

新建目錄：

mkdir nginx-rtmp && cd nginx-rtmp

創建docker-compose.yml：

services:
  nginx-rtmp:
    image: tiangolo/nginx-rtmp:latest
    container_name: nginx_rtmp
    ports:
      - "1935:1935" # RTMP port
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    restart: unless-stopped

創建nginx.conf：

worker_processes  auto;

events {
    worker_connections  1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            push rtmp://live.twitch.tv/app/{Twitch 主直播密鑰};
        }
    }
}

啟動編排：

docker compose up -d
# 老版本 compose 插件則是 docker-compose up

當然，別忘了開放防火牆端口。我的防火牆參考了 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置，相應地，開放端口的命令如下：

ufw route allow proto tcp from any to any port 1935

配置完成後，OBS 內的推流目標地址填入rtmp://服務器ip/live，推流碼填寫任意值均可。設置完成後即可開始推流。

Netch

如果沒有服務器，亦可以使用 Netch 代理 OBS 進程進行推流。

首先下載 Netch 1.9.2 版本，注意一定要是 1.9.2 版本。添加一個進程模式，將 OBS 文件夾加入，隨後啟用該進程模式的代理即可。

尾聲

這次為了在同時在 Twitch 和 B 站上推流，遇到了很多原本不必要的麻煩。我可以怪 OBS 沒有內置代理功能，也可以怪 Clash Verge 等代理工具不支持 RTMP，轉來轉去，最終要怪的，還得是 GFW。雖然最後的結果還算令人滿意，僅僅為了推流而折騰這些東西的體驗實在是稱不上良好。也許我今後我應該去研究修改 Mihomo 內核，讓其支持 RTMP 協議，亦或是自己寫一套獨立的實現單獨轉發 OBS 的流量，不論如何，在這片土地上，想要暢快的直播，道阻且長。

最後，歡迎關注我的 Twitch 頻道: https://www.twitch.tv/powerfullz233

docker-mailserver 郵件服務器搭建記錄

Fri, 06 Sep 2024 03:57:18 +0000

某天早上醒來，發現收件箱裡多了封郵件，通知我的郵箱在韓國登錄，當時認為只是偶爾的 IP 誤判，也就沒有多想。可接下來幾天，時不時又有新的郵件進來，而且每次 IP 都不一樣，這下可就有些問題了，再不採取行動，怕不是郵箱真的要被拿去群發郵件。於是趕緊刪掉了域名的 MX、SPF、DMARC 記錄，尋找新的解決方案。

我原本只是想改改密碼，結果呢，騰訊企業郵箱改密碼的入口真的巨能藏，到處都找不到。算了，遷移，何必受這氣。

於是就有了這篇文章，從最開始的開放防火牆端口開始，到最後的優化送達率，我將分享我搭建 docker-mailserver 郵件服務器的經驗，希望能幫你少踩些坑。

搭建 docker-mailserver 郵件服務器前的準備

防火牆的處理

首先先開放防火牆的郵件服務常用端口，分別是25、143、465、587、993，各分支開放端口的操作不同，請自行谷歌或詢問 AI，以 Ubuntu 使用的ufw為例：

ufw allow 25
ufw allow 143
ufw allow 465
ufw allow 587
ufw allow 993

我的防火牆比較特殊，用到了ufw和 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置。所以當我想要把 Docker 容器的端口暴露在外時需要做出額外的配置。

# 開放郵件服務器所需的端口
ufw route allow proto tcp from any to any port 25
ufw route allow proto tcp from any to any port 143
ufw route allow proto tcp from any to any port 465
ufw route allow proto tcp from any to any port 587
ufw route allow proto tcp from any to any port 993

驗證你的服務器是否具備搭建條件

很多服務器，尤其是各種廉價的 VPS，並不適合搭建 docker-mailserver，各大郵件服務商為了過濾垃圾郵件，索性將所有曾經有過 Spam 行為的 IP 全部列入黑名單。如果你的 IP 被某個 Spammer 使用過，而恰好又被你的服務器提供商分配給了你，而你折騰了幾個小時的郵件服務器卻愣是收不到郵件，最後發現竟是 IP 被列入黑名單的原因，我不知道你會作何感想。

有的服務器提供商的 IP 乍一看確實不在郵件黑名單中，但實際上搭建好之後還是無法發送郵件，為什麼？因為服務器提供商擔心 IP 被濫用，索性將郵件服務的端口全都封鎖了。

使用如下腳本檢測你的服務器是否具備搭建郵件服務器的條件：

bash <(curl -sL IP.Check.Place)

如果在這一步發現你的服務器不適合搭建甚至不能搭建docker-mailserver，那就趁早打住吧，想辦法換一個更乾淨、限制更少的 IP 再說。

搭建過程

拉取配置文件

docker-mailserver 需要配置的配置文件有兩個，compose.yaml和mailserver.env，分別拉取配置文件：

mkdir mailserver && cd mailserver
sudo apt install wget
wget -O compose.yaml "https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/compose.yaml"
wget -O mailserver.env "https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env"

根據需求，可以修改不同的配置，下面是我修改的部分：

POSTMASTER_ADDRESS=webmaster@l3zc.com
TZ=Asia/Shanghai
SSL_TYPE=manual
SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

用 Caddy 準備和自動維護 TLS 證書¹

因為我已經在使用 Caddy，所以我這次就打算直接使用 Caddy 來自動維護證書。根據項目的官方文檔，我只需要在 Caddyfile 裡新增一個子域名，Caddy 就可以自動幫我維護證書。

mail.example.com {
  tls internal {
    # ?? 這不是直接生成的內部證書麼
    key_type rsa2048
  }

  # Optional, can be useful for troubleshooting
  # connection to Caddy with correct certificate:
  respond "Hello DMS"
}

當我更新完 DNS 記錄，實際操作起來發現，我的情況比較特殊：我這臺服務器上並沒有用到 Caddy 的自動申請證書功能，而是使用了15年有效期的泛域名 Cloudflare Origin Certificate。即使我不為這個子域名指定證書文件，Caddy 也會在加載這張泛域名證書後認為無需再申請新的證書。這就很尷尬了，用 Caddy 的時候 Cloudflare Origin Certificate 和郵件服務器只能二選一。只好安裝了dns.providers.cloudflare，並放棄使用 Cloudflare Origin Certificate，轉而讓 Caddy 自動為每個子域名申請和維護 TLS/SSL 證書，反正都是自動的，眼不見心不煩。

安裝dns.providers.cloudflare後的全局配置：

{
        acme_dns cloudflare {API_KEY}
}

最後把 Caddy 的證書存儲位置映射到 docker-mailserver 容器內。

volumes:
  - /home/user/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/:/certs/

如果 Caddy 以 root 用戶運行，則證書的位置應當為/root/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/，做出相應的修改即可。

然後就是之前提到過的配置，我將證書存儲位置映射到了容器內的/certs/目錄，所以配置為：

SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

首次啟動容器

首次啟動容器需要立即（120 秒內）創建新的 Postmaster 賬號。

docker compose up -d
docker exec -it  setup email add

優化送達率

DNS 記錄

一條 A 記錄，名稱隨意（假設為mail），指向服務器 IP（Cloudflare 需使用「僅 DNS」）
一條 MX 記錄，Apex 域（@），指向mail.yourdomain.tld
一條 TXT 記錄（SPF），Apex 域（@），可以在這裡生成(可選)。
一條 TXT 記錄（DMARC），名稱_dmarc，可以在這裡生成（可選）。
一條 TXT 記錄（DKIM），名稱mail._domainkey，具體配置在後文（可選）。

DKIM, SPF 和 DMARC²

什麼是 DKIM，SPF 和 DMARC？簡單來說，DKIM 是一個數字簽名機制；SPF 類似於「員工名單」，記錄所有合法的發件服務器；DMARC 則用於指示收件方的服務器如何處理未通過 DKIM 和 SPF 驗證的郵件。³

首先設置 DKIM，在服務器上生成公私鑰對。

docker exec -it  setup config dkim

生成後的公私鑰對可以在映射的容器目錄./docker-data/dms/config/opendkim/keys/下找到。

下載 mail.txt（複製其內所有內容粘貼到本地文件也可以），將其導入到 Cloudflare Dashboard 即可完成 DKIM 設置。需要注意配置完成 DKIM 後需要重啟容器才能生效。⁴

docker compose up -d --force-recreate

前面提到 SPF 相當於一個「員工名單」，既然我合法的發件服務器只有一臺，那麼 DNS 填寫如下設置即可。

"v=spf1 mx ~all"

再就是 DMARC，可以使用前面提到的模板生成，這裡不再贅述。

如果你的域名服務商擁有自己的設置嚮導（例如 Cloudflare），亦可以使用它們簡化設置流程。

客戶端設置

客戶端設置相對就很簡單了，IMAP 和 SMTP 服務器都是mail.yourdomain.ltd，開啟 SSL 後端口分別是 465 和 993，登錄即可。

善用 MailTester

至此我們已經完成了搭建 docker-mailserver 郵件服務器的整個過程，在開始發送郵件之前，我們可以使用 MailTester 測試我們的配置是否正確。如果測試結果是 10/10，那麼我們的 docker-mailserver 郵件服務器應該會擁有漂亮的送達率，好好享受吧。

如果不是 10/10，也不要著急，認真查看扣分的原因，對症下藥，一項一項解決即可。

TODO-List

配套 WebUI

參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#caddy ↩︎
參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/ ↩︎
更加具體的介紹: https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/ ↩︎
在官方文檔中有提及。 ↩︎

Firefish 數據庫升級記錄

Fri, 30 Aug 2024 04:45:12 +0000

我的 Firefish 實例搭建於去年的 11 月，使用的數據庫版本自然不是最新的，確切的說，是 PGroonga 12，一個基於 5 年前的 Postgres 的遠古版本。為了避免今後的兼容性問題和安全問題，同時為了更好的性能，今天這數據庫是非升級不可。

升級一個用 Docker 跑起來的數據庫和升級其他的 Docker 容器有很大不同，並不是拉取一個新的鏡像就可以宣告結束。因為 Postgres 幾乎每個大版本都有 Breaking Changes，新老版本產生的持久化文件並不兼容，如果直接拉取一個新的鏡像運行，數據庫是無法啟動的，必須要採用一定的手段進行數據的遷移。

Postgres 有官方的升級工具pg_upgrade¹，這一次我不採用，因為我的數據庫跑了一年多，而且用的還是 5 年前的老版本，用這個工具我不確定會不會出問題。這次遷移，大致思路是先導出 SQL，再將導出的 SQL 導入新版本。

升級前的部署概況

以下是一些升級前需要了解的配置信息：

項目	配置
實例部署方式	Docker Compose
數據庫容器名稱	firefish_db
升級前的數據庫容器鏡像	groonga/pgroonga:3.1.9-alpine-12-slim
數據庫用戶	example-firefish-user
數據庫名稱	firefish

Docker Compose 的數據庫部分如下：

db:
  restart: unless-stopped
  image: groonga/pgroonga:3.1.9-alpine-12-slim
  container_name: firefish_db
  networks:
    - calcnet
  env_file:
    - .config/docker.env
  volumes:
    - ./db:/var/lib/postgresql/data
  healthcheck:
    test: pg_isready --user="$${POSTGRES_USER}" --dbname="$${POSTGRES_DB}"
    interval: 5s
    timeout: 5s
    retries: 5

導出當前數據庫

對數據庫進行升級之前，首先下線 Firefish 的編排：

docker compose down

單獨啟動數據庫容器，導出當前數據庫為 SQL：

docker compose up -d db
docker exec -it firefish_db pg_dumpall -U example-firefish-user > backup.sql

由於 Firefish 的數據庫比較大，導出過程可能需要很長一段時間，比如我的個人實例就用了十幾分鍾。

導出文件的處理

可能是由於新版的 Postgres 認證方式有所變更，如果直接向新數據庫導入之前導出的backup.sql文件，就會改變新數據庫的 Authentication Scheme，導致之後 Firefish 連接數據庫時認證失敗。要避免這個問題需要對目前的backup.sql進行一些處理，只抽取出其中的firefish數據庫的部分，而不是直接導入所有數據。²

#!/bin/bash
[ $# -lt 2 ] && { echo "Usage: $0  "; exit 1; }
sed  "/connect.*$2/,\$!d" $1 | sed "/PostgreSQL database dump complete/,\$d"

編輯一個 Shell 腳本為以上內容，保存至script.sh，用以處理目前的backup.sql：

nvim script.sh  # 或者任何你喜歡的編輯器
chmod +x script.sh
./script.sh backup.sql firefish >> upgrade.sql

如果一切順利，當前目錄下就會出現一個名為upgrade.sql的文件，可以打開它看一下，確保其被正確導出。

向新數據庫導入現有數據

修改docker-compose.yml：

db:
  restart: unless-stopped
  image: groonga/pgroonga:3.2.2-alpine-16-slim # 最新的容器
  container_name: firefish_db
  networks:
    - calcnet
  env_file:
    - .config/docker.env
  volumes:
    - ./database:/var/lib/postgresql/data # 注意這一行的變動
  healthcheck:
    test: pg_isready --user="$${POSTGRES_USER}" --dbname="$${POSTGRES_DB}"
    interval: 5s
    timeout: 5s
    retries: 5

注意數據庫目錄映射配置由./db:/var/lib/postgresql/data變為./database:/var/lib/postgresql/data，這麼做是為了給新的數據庫一個 Fresh Start，同時也保存老的持久化數據，即使出現問題，也可以隨時用回老的數據庫。

拉取並啟動新容器：

docker compose pull
docker compose up db -d

向新數據庫導入upgrade.sql：

cat upgrade.sql | docker exec -i firefish_db psql -U example-firefish-user -d firefish

取決於數據庫的大小，導入過程也會持續較長的時間。

收尾工作

導入完成，啟動整個編排：

docker compose stop db
docker compose up

導入後的首次啟動不建議帶-d參數，建議不帶參數啟動，確保啟動過程沒有問題後再以-d參數啟動。

最後，登入剛剛啟動的 Firefish 實例，檢查是否有任何數據損失，沒有問題的話就大功告成啦🎉

官方文檔：https://www.postgresql.org/docs/current/pgupgrade.html ↩︎
參考：https://thomasbandt.com/postgres-docker-major-version-upgrade ↩︎

科學上網：用 Caddy 反向代理 VLESS

Tue, 13 Aug 2024 08:24:26 +0000

上一篇文章提到，我搭建了一個基於 Aria2 的 BT 離線下載服務器。為了用 Caddy 反向代理部署好的容器，我把原來偷懶用一鍵腳本部署的 Trojan 給卸載了，問就是因為這腳本把 80 和 443 端口都佔用了，不卸載掉根本沒法繼續。

於是離線下載服務器是搭建好了，可時不時需要的代理卻不得不下線。仔細一想，之前看到過有人 Cloudflare + V2Ray + WS 復活被牆的 VPS，既然是 WebSocket，還能用 Cloudflare 反代，那用 Caddy 反代又有何不可呢？況且 Caddy 還有自動 TLS，比起 Nginx + Certbot 的組合配置起來肯定更簡單。只要配置成功，我就可以在為 Caddy 留住 443 端口的同時跑代理了。

安裝 VLESS 和 Caddy

安裝VLESS 可以直接使用 v2fly/fhs-install-v2ray 一鍵腳本：

# 安裝執行檔和 .dat 資料檔
bash <(curl -L https://raw.githubusercontent.com/v2fly/fhs-install-v2ray/master/install-release.sh)

Caddy 的安裝請參考官方教程，例如，我使用 Debian 12，則使用以下命令：

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

配置 VLESS

編輯/usr/local/etc/v2ray/config.json：

{
  "log": {
    "access": "/var/log/v2ray/access.log",
    "error": "/var/log/v2ray/error.log",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 1234, //任意端口
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "super-random-uuid", //隨機生成一個 UUID 替換即可
            "level": 0,
            "email": "example@example.com"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "ws",
        "security": "none",
        "wsSettings": {
          "path": "/" // 需要與之後的 Caddy 配置保持相同
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

編輯完成後保存退出即可。

配置 Caddy

在你喜歡的位置創建一個 Caddyfile，或者編輯已有的 Caddyfile，加入如下內容，反向代理剛才在 VLESS 配置文件中設置的端口：

yourdomain.com {
        # 用一個 Matcher 匹配所有指定路徑的 Websocket 請求
        @websockets {
                path /      # 與前面 VLESS 的 path 保持一致
                header Connection Upgrade
                header Upgrade websocket
        }
        reverse_proxy @websockets :1234
}

至此，服務端所有配置文件都編輯完畢。

啟動服務

啟動 VLESS，並設置開機自啟動：

systemtcl enable v2ray && systemctl start v2ray

啟動 Caddy/更新 Caddy 配置：

caddy start
caddy reload  # 更新配置用

以上操作全部完成後，Caddy 反向代理 VLESS 就完成了。

客戶端設置

客戶端方面需要手動設置：

地址是綁定給 VLESS 的域名。
端口是 443
TLS 打開
傳輸方式選擇 websocket
UUID 是之前填入 VLESS 配置文件的 UUID

所有的客戶端設置大同小異，至於 Clash 的配置文件，可以參考 Mihomo 文檔¹，以下是我的示例配置文件：

proxies:
  - name: "A Random Name"
    type: vless
    server: yourdomain.com
    port: 443
    udp: true
    uuid: super-random-uuid
    flow: xtls-rprx-vision
    packet-encoding: xudp

    tls: true
    servername: yourdomain.com
    alpn:
      - h2
      - http/1.1
    skip-cert-verify: false

    network: ws

    smux:
      enabled: false

需要生成 Clash 配置文件可以使用 V2RaySE 提供的工具。

完成

好了，現在我們已經擁有了一個 VLESS 服務器，Caddy 會自動為我們申請和維護 TLS 證書，非常好用。

只需要這麼小小折騰一下，我彷彿又找到了當年用一鍵腳本搭建 SSR 時的愉悅，好好享受這種能順利打開 google.com 時的興奮吧。

TODO List

基本搭建
偽裝

畢竟繼承 Clash Meta 衣缽的 Mihomo 也算是 Clash 正統了。 ↩︎

搭建一個 BT 離線下載服務器

Sat, 10 Aug 2024 07:46:40 +0000

自從買了一些廉價 VPS 以後，手上就閒置了一臺 Azure 的學生機，除了用來跑個 Trojan 暫時沒有其他的用途。正好最近想要下一些 BT 資源，而國內的 BT 環境懂的都懂，遂決定用這臺接近閒置的機器離線下載 BT。

首先聲明，所有 BT 下載行為需要自行承擔被版權投訴的風險。

安裝 Aria2

對於這些不是「基礎設施」的軟件，我更喜歡直接拉取一個 Docker 容器的方案。我採用了P3TERX/Aria2-Pro-Docker¹，這套已經修改好的 Docker 容器。Docker 容器部署起來如出一轍：首先編輯docker-compose.yml，docker compose up把所有容器都跑起來，最後反代暴露的端口即可。

我的docker-compose.yml如下²：

services:
  Aria2-Pro:
    container_name: aria2-pro
    image: p3terx/aria2-pro
    environment:
      - PUID=65534
      - PGID=65534
      - UMASK_SET=022
      - RPC_SECRET=replace-me # 記得修改這一行
      - RPC_PORT=6800
      - LISTEN_PORT=6888
      - DISK_CACHE=64M
      - IPV6_MODE=false
      - UPDATE_TRACKERS=true
      - CUSTOM_TRACKER_URL=
      - TZ=Asia/Shanghai
    volumes:
      - ./aria2-config:/config
      - ./aria2-downloads:/downloads
    network_mode: bridge # 如果你需要用到 IPV6 網絡，也可以使用 host 模式
    ports:
      - 6800:6800
      - 6888:6888
      - 6888:6888/udp
    restart: unless-stopped
    # 防止日誌塞滿硬盤
    logging:
      driver: json-file
      options:
        max-size: 1m

  # 也可以使用其他面板
  AriaNg:
    container_name: ariang
    image: p3terx/ariang
    command: --port 6880 --ipv6
    network_mode: bridge
    ports:
      - 6880:6880
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: 1m

用 Caddy 反向代理

之前的反向代理，我都是用的基於 Nginx 的方案，而在這段時間裡關於 Caddy 的好評不絕於耳，這次的我便換用了 Caddy，當然，主要也是想嘗試一些新東西、新技術。

Caddy 的使用真的非常簡單，即使對新人也極其友好，例如，常用的反向代理本機某個端口，只需三行 Caddyfile 即可搞定。

domain.com {
  reverse_proxy :1234
}

安裝 Caddy 請參考官方文檔，例如，我的服務器使用 Debian，則使用以下命令安裝：

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

安裝完成後記得開放防火牆和從服務商策略組的 80 和 443 端口。

在域名服務商處將要綁定的域名指向服務器，就可以開始寫 Caddyfile 了。我們需要反向代理三個端口，分別用作不同的用途。我的 Caddyfile 如下：

# Aria-NG 面板
download.l3zc.com {
  reverse_proxy :6880
}

# Aria2 API
arapi.l3zc.com {
  reverse_proxy :6800
}

# Alist
downloaded.l3zc.com {
  reverse_proxy :5244
}

看到如此簡潔的配置文件，不由得感嘆，相比於 Nginx，Caddy 用起來真是令人心情舒暢。寫入配置完成後，重新啟動 Caddy³，就可以開始欣賞 Caddy 自動幫你申請 SSL 證書配置好 HTTPS 的絕贊過程。至此，反向代理的部分也就完成了。

配置 Aria-NG

Aria-NG 只是一個前端面板，可以和任何 Aria2 後端通信，為此，我們需要給 Aria-NG 提供配置信息。進入剛剛反代好的 Aria-NG 面板，轉到 AriaNG 設置，填入配置信息。

其中，RPC 地址是剛剛反代好的 RPC 地址，協議選擇 HTTPS，請求方法選擇 POST，RPC 密鑰是在docker-compose.yml裡replace-me處你所替換的值。

若「Aria2 狀態」旁出現「已連接」，說明配置正確。

用 Alist 映射下載目錄

我們通過 Alist 映射下載目錄，以更方便的查看、管理和下載服務器上已經下載好的文件。Alist 同樣也通過 Docker 部署，由於 Alist 本身在容器內運行們，無法訪問容器外的文件，部署時需要將 Aria2 的下載目錄提前 Bind 到 Alist 的容器下。

我的docker-compose.yml如下：

services:
  alist:
    image: "xhofe/alist:latest"
    container_name: alist
    volumes:
      - "/etc/alist:/opt/alist/data"
      - "/home/azureuser/aria2/aria2-downloads:/aria2-downloads" #這裡需要視情況綁定你自己的目錄
    ports:
      - "5244:5244"
    environment:
      - PUID=0
      - PGID=0
      - UMASK=022
    restart: unless-stopped

第一次啟動 Alist 時，Alist 會隨機生成admin用戶的密碼，所以，第一次啟動這套編排時，最好不要帶-d參數，而是直接docker compose up，並把容器啟動後的輸出妥善保存。如果不小心沒有保存管理員密碼，可以用這個命令重新隨機生成一個：

docker exec -it alist ./alist admin random

成功登錄 Alist 之後就可以開始掛載目錄了。

驅動選擇本機存儲，掛載路徑需要注意，按照我的編排，我將容器外的/home/azureuser/aria2/aria2-downloads目錄掛載到了容器內的/aria2-downloads，所以掛載路徑應該是/aria2-downloads。

完成

現在所有的服務都已經部署上線了，打開 AriaNG 可以添加下載任務，下載好的文件可以打開 Alist 看到，下載，以及在線觀看。

搭建這套服務之前，請仔細查看 VPS 提供商的服務條款，確保 BT 下載行為不會違規。以及，除了盧森堡等少數國家/地區，下載被 DMCA 保護的資源可能會遭到投訴，這些風險都需要你自行承擔。

反正我這 Azure 的學生機也是白嫖的，被投訴回收了我也無所謂，不管怎樣，現在可以心無旁騖的享受找資源的快樂了。

當然也可以試一試SuperNG6/docker-aria2 ↩︎
參考原作者的docker-compose.yml ↩︎
caddy stop和caddy start，參考Caddy文檔 ↩︎

在 GNU/Linux 和 Windows 間共享 Steam 遊戲庫

Fri, 12 Apr 2024 10:53:59 +0000

得益於與 Steam Deck 一同而來的 Proton，在常見的 GNU/Linux（以下簡稱 Linux）發行版上暢玩各類原本在 Windows 上才有的 3A 大作成為完全可行的選擇，最近我也進行了這方面的嘗試，效果已經較為理想，但隨之而來的是一個問題，我總不可能把動輒上百G的遊戲全都重新裝一遍吧？硬盤沒空間了不說，這麼麻煩還不如切回 Windows 玩呢。

出現$代表是終端命令，下面跟著的是命令執行後的輸出。

掛載 Steam 庫所在的分區

起初我試圖直接在 GUI 上掛載分區，但這樣會遇到莫名其妙的問題，有這個想法的朋友請不要跳過這一部分。

找到目標分區的 UUID

$ sudo blkid
/dev/nvme1n1p8: UUID="421a3d00-81a8-4112-a2df-4d234c674a24" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="84e56276-a585-412c-9bf5-0071b2b4d4da"
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p1: PARTLABEL="Microsoft reserved partition" PARTUUID="bbdb2720-6722-42b3-80f5-385332da77c3"
/dev/nvme0n1p2: LABEL="Vault" BLOCK_SIZE="512" UUID="DC64DA2064D9FCE8" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="f884fe24-1c4d-4650-9847-d2f83b9a93ba"
......

如果你能在類似「磁盤管理」的應用裡查到目標分區的 UUID，也可以直接使用。

查詢用戶 ID 和組 ID

$ id -u
1000
$ id -g
1000

默認狀態下，這兩個值都是1000。

創建掛載點並修改 `fstab`

$ sudo mkdir /media/gamedisk
$ sudo nano /etc/fstab

這裡也可以使用任何你喜歡的編輯器。

在文件的末尾加上：

UUID=DC64DA2064D9FCE8 /media/gamedisk lowntfs-3g uid=1000,gid=1000,rw,user,exec,umask=000 0 0

如果你之前已經掛載過這個硬盤，請刪除之前掛載產生的那一行。

大小寫敏感可能會導致問題，這裡使用的是lowntfs-3g，掛載後的 NTFS 卷將不會大小寫敏感，以免出現因大小寫敏感而找不到遊戲文件的問題。¹

防止出現 NTFS Read Error

⚠️注意：有報告稱這樣操作可能會造成數據丟失，請自行斟酌並承擔風險。

由於 NTFS 的特性，如果創建在 Windows 上無效名稱的文件/文件夾將導致 Read Error，進而導致遊戲無法啟動。最常見的問題是文件名中包含:字符，而 Proton 在 NTFS 磁盤上創建的文件名中就包含了這個字符。

修復這個問題相當簡單：在掛載的 NTFS 磁盤上創建一個/compatdata文件夾，並將其 symlink 到 Linux 分區上的文件夾。

創建 symlink：

$ mkdir -p ~/.steam/steam/steamapps/compatdata
$ ln -s ~/.steam/steam/steamapps/compatdata /media/gamedisk/Steam/steamapps/

如果提示/compatdata已經存在，刪除它並重新 symlink 即可。

最後，添加 Steam 庫吧

操作完成後，重啟電腦，目標磁盤就會在 Linux 上自動掛載，這時進入 Steam 正常添加遊戲庫即可

操作完成後，可以正常遊玩 Steam 庫裡所有的 Windows 遊戲，並且可以在任何一邊向庫內添加遊戲。

本文參考：Using a NTFS disk with Linux and Windows

來源：Server Fault ↩︎

最速 Firefish 部署指南

Mon, 04 Dec 2023 09:17:56 +0000

需要的環境

Docker 和 Docker Compose
任意 Web 服務器

最速教程

為 Firefish 準備一個目錄：

mkdir firefish && cd firefish

⚠️注意：近期 Firefish 更新頻繁，本文的docker-compose.yml已經過時，請參考官方倉庫中的docker-compose.example.yml和Notice for server administrators進行配置。

用你喜歡的文本編輯器創建docker-compose.yml：

version: "3"

services:
  web:
    image: registry.joinfirefish.org/firefish/firefish:stable-amd64
    container_name: firefish_web
    restart: unless-stopped
    depends_on:
      - db
      - redis
      ### Uncomment one of the following to use a search engine
      #     - meilisearch
      - sonic
    ports:
      - "6666:3000" # 6666換成需要的端口
    networks:
      - calcnet
    #     - web
    environment:
      NODE_ENV: production
    volumes:
      - ./files:/firefish/files
      - ./.config:/firefish/.config:ro

  redis:
    restart: unless-stopped
    image: redis:7.0-alpine
    container_name: firefish_redis
    networks:
      - calcnet
    volumes:
      - ./redis:/data

  db:
    restart: unless-stopped
    image: postgres:12.2-alpine
    container_name: firefish_db
    networks:
      - calcnet
    env_file:
      - .config/docker.env
    volumes:
      - ./db:/var/lib/postgresql/data

  ### Only one of the below should be used.
  ### Meilisearch is better overall, but resource-intensive. Sonic is a very light full text search engine.

  #  meilisearch:
  #    container_name: meilisearch
  #    image: getmeili/meilisearch:v1.1.1
  #    environment:
  #      - MEILI_ENV=${MEILI_ENV:-development}
  #    ports:
  #      - "7700:7700"
  #    networks:
  #      - calcnet
  #    volumes:
  #      - ./meili_data:/meili_data
  #    restart: unless-stopped

  sonic:
    restart: unless-stopped
    image: valeriansaliou/sonic:v1.4.0
    logging:
      driver: none
    networks:
      - calcnet
    volumes:
      - ./sonic:/var/lib/sonic/store
      - ./sonic/config.cfg:/etc/sonic.cfg:ro

networks:
  calcnet:
  #  web:
  #    external:
  #      name: web

你也可以用 Melisearch，但這是最速指南，只講 Sonic。

創建.config目錄：

mkdir .config && cd .config

創建docker.env：

# db settings
POSTGRES_PASSWORD=example-firefish-pass
POSTGRES_USER=example-firefish-user
POSTGRES_DB=firefish

創建default.yml：

#━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Firefish configuration
#━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# After starting your server, please don't change the URL! Doing so will break federation.

#   ┌─────┐
#───┘ URL └─────────────────────────────────────────────────────

# Final accessible URL seen by a user.
url: https://你的域名/
port: 3000

db:
  host: db
  port: 5432
  #ssl: false
  # Database name
  db: firefish

  # Auth
  user: example-firefish-user
  pass: example-firefish-pass

#   ┌─────────────────────┐
#───┘ Redis configuration └─────────────────────────────────────

redis:
  host: redis
  port: 6379

#   ┌─────────────────────┐
#───┘ Sonic configuration └─────────────────────────────────────

sonic:
  host: sonic
  port: 1491
  auth: SecretPassword
  collection: notes
  bucket: default

# Reserved usernames that only the administrator can register with
reservedUsernames: ["root", "admin", "administrator", "me", "system"]

signToActivityPubGet: true

回到上一層目錄，創建./sonic/config.cfg：

# Sonic
# Fast, lightweight and schema-less search backend
# Configuration file
# Example: https://github.com/valeriansaliou/sonic/blob/master/config.cfg

[server]

log_level = "debug"

[channel]

inet = "0.0.0.0:1491"
tcp_timeout = 300

auth_password = "SecretPassword"

[channel.search]

query_limit_default = 10
query_limit_maximum = 100
query_alternates_try = 4

suggest_limit_default = 5
suggest_limit_maximum = 20

list_limit_default = 100
list_limit_maximum = 500

[store]

[store.kv]

path = "./data/store/kv/"

retain_word_objects = 1000

[store.kv.pool]

inactive_after = 1800

[store.kv.database]

flush_after = 900

compress = true
parallelism = 2
max_files = 100
max_compactions = 1
max_flushes = 1
write_buffer = 16384
write_ahead_log = true

[store.fst]

path = "./data/store/fst/"

[store.fst.pool]

inactive_after = 300

[store.fst.graph]

consolidate_after = 180

max_size = 2048
max_words = 250000

全部創建好以後的目錄結構應該看起來像這樣：

.
├── .config
│   ├── default.yml
│   └── docker.env
├── docker-compose.yml
└── sonic
    └── config.cfg

最後執行docker compose up，綁定域名、反代端口，實例就搭建完成了。

Firefish 已經自動 Minify 了所有的前端文件，如果你使用 Cloudflare 或其他類似的服務，記得關掉 Auto Minify，否則會出現一些奇怪的問題。¹

以上就是最速教程。

一些問題

Q：docker.env和./sonic/config.cfg密碼和用戶名不改沒問題嗎？

A：沒很大問題，因為兩個服務沒有暴露到公網上，僅做個人使用不改也沒什麼大事。

Q：為什麼 network 要叫calcnet？

A：因為這個項目本來叫做 Calckey。

https://github.com/misskey-dev/misskey/issues/10328 ↩︎

受夠了 MacOS，我給 Macbook 裝上了 Linux

Tue, 07 Nov 2023 09:38:50 +0000

現在已經換成了 Arch，btw。

現役一臺 MacBook (Retina, 12-inch, Early 2016)，官方最高支持到 Monterey，當時收來的時候我認為，我會 Stick with MacOS。

這麼說是因為 MacOS 在我賣掉的老 MBP 上給我的印象是穩定好用，當時的想法是出掉 MBP 買入一臺廉價而性能夠用的 Windows 遊戲本和一臺天天帶出去的輕薄本——事實上我也不後悔這個決定。

好吧我承認我高估了這顆兩核 m5 的性能，目前的狀況是：如果使用 MacOS，必須要開啟「減弱動畫效果」，否則會卡得生活不能自理。這就是 MacOS 的另一個特點：「易卡難崩」。

於是我給我的 MacBook 裝上了 Linux，就有了現在這篇文章，written on Ubuntu。

Why Ubuntu?

我其實並不是很喜歡 Ubuntu，選用 Ubuntu 更多是一個無奈的權衡。

本次安裝 Linux 的目的是獲得更好的性能和更流暢的體驗，讓我的日常工作更加輕鬆。這臺電腦是我的日常裝備之一，我不太希望選擇一個不夠穩定的分支。之前滾壞過一次系統的經歷讓我直接把 Arch 排除在外。我有太多事情要做，時不時滾壞的系統？ Don’t have time for that. I just want a system that works out of the box 。

本來想裝 Pop!OS——System76 基於 Ubuntu 打造的系統，但安裝器不知為何老是閃退，遂放棄。

用distrochooser.de選出了 OpenSUSE，並且在虛擬機上裝好 OpenSUSE + Xfce 試用。我非常喜歡這套環境，但 Xfce 似乎不支持 HiDPI，也不優先考慮。YaST 真的很好用，將來我會在別的電腦上用這套系統，但這臺電腦，no。

在這臺 MacBook 上，Ubuntu 的驅動問題算是最少的。除了上面提到的兩個分支，我也嘗試了一些別的 Debian 系 Distro 比如 Linux Mint、Deuvan，甚至國產 Deepin，沒有一個擁有良好的硬件兼容性。

在作出這些嘗試以後我認為已經沒有必要再挑三揀四，先用 Ubuntu 權衡才是最優解。

Software：How Ubuntu fits into my workflow

我在安裝時就選擇安裝了 ThunderBird、Libre Office 等軟件。在進系統後也很快就用 apt 安裝好了所有我需要的 CLI 工具以及大部分應用。

我在 MacOS 下的包管理器是 Homebrew，換到 Ubuntu 就改用了自帶的 apt，也接受了 snap，即使這會影響到我安裝 GTK 主題後的一致性。¹與 Homebrew 相比，apt 提供更多的軟件包²，且 Homebrew 終究是作為一個第三方包管理器存在。

為了安裝一些別的應用，我也安裝了 flatpak 作為額外的包管理器。雖然比較難用，但也確實擴充了軟件的選擇範圍。

Browsing

Chrome 依舊是我的主力瀏覽器，我難以放棄它的同步功能，Which means I have no choice.

所有網頁都可以正常工作，就像在 Windows 和 MacOS 上那樣，as expected.

Office files

學生要看的 Word、PPT、PDF 等，這些在 Libre Office 上顯示效果超出我的預期——基本都能正確顯示。字體什麼的都是小問題，.doc、.ppt文檔的佈局都正常，渲染也沒有錯誤。

我從不在這臺電腦上做編輯 Office 的工作，即使在 MacOS 下也是如此。有這些工作我都交給了我的 Windows PC。

即便如此，在 MacOS 上我卻依舊全量安裝了 Office 365。Office 365 在後臺更新頻繁，我打開 Office 時，經常彈出「正在驗證xxx」的提示，每次都要等很久，非常煩人。相比之下，Libre Office 只在我apt upgrade時才會更新，用起來不知道比 MacOS 舒服多少。我已經在考慮將這臺 MacBook 上的 Office 365 換成 LibreOffice。

Blogging

我以 VSCode 作為代碼兼文本編輯器，用 Typora 來寫 Markdown 文章，用 PicGo 作為圖床上傳工具，用 Git 把寫好的內容和配置推到 Github 上併發布。我還在本地安裝了 Hugo 用以預覽我的修改，這些工具配置好以後使用起來和在別的平臺上無異。

Music

我主要使用 Spotify 和網易雲音樂來串流音樂。其中 Spotify 有 Native 版本，網易雲的 Linux 客戶端早已停止維護，可能網頁版才是更好的選擇。

Youtube 其實也是個聽音樂的好地方。

QQ 的全功能 Electron 重構版本 QQNT 原生支持所有主流的分支，還有 Telegram。至於微信，我暫時沒有什麼硬性需求，用手機就可以了，有文件要傳到電腦上可以用 QQ 中轉。

主流的 Twitter Like 社交平臺和 Fediverse 實例都有網頁版，部分還有 PWA³ 可用，這些用 Chrome 就可以解決。

ThunderBird 是非常好的郵件客戶端，我在 Windows 上已經在使用，換到 Ubuntu 的預裝更無需重新適應。

Password Management & RSS

我的密碼管理器是 BitWarden，一樣原生支持所有的主流分支。

RSS 閱讀器有老朋友 Fluent Reader 和 Thunder Bird，Fluent Reader 把 Fluent Design 直接原封不動搬了過來，一樣支持 Fever API 讓我和 FreshRSS 同步。

NewsFlash 也是很好的閱讀器，原生支持 FreshRSS，稍微有點麻煩的就是必須用 flatpak 安裝，同時滾動時我能感覺到明顯的卡頓和發熱。不知道是軟件自身的優化問題還是 flatpak 的問題。

Proxy

網絡代理我採用 Clash Verge 和 proxychains 的組合，解決了終端和系統代理的問題。除了在打開管理面板的時候 Tauri 很佔資源以外，本身依然是穩定好用。至於 Proxychains 是用來解決部分工具即使設置了環境變量也不遵循的問題而安裝的。我只需要配置好然後proxychains任何一個命令就可以讓這個命令走代理。

Terminal

終端應用直接採用默認的就好，我並不是 Bash 死忠粉，所以後來我也換到了 Zsh，和 MacOS 上一樣安裝了 Oh My Zsh。最近看到了 Terminology，準備一試。

Airdrop alternative

傳文件的需求我用到了 QQ 和 Snapdrop。

My experience with Ubuntu

在瀏覽器越來越強大，網頁版應用和 Electron App 越來越多的今天，Ubuntu 的軟件生態雖然無法和 MacOS 和 Windows 相比，但也足以讓我有底氣 to make the switch。

It’s impressive

Ubuntu 的性能相比於我在 MacOS 簡直就是一個天上一個地下。在安裝時我直接分了 4G Swap，所有的應用都啟動的非常快，與 MacOS 上彈個半天形成的對比非常強烈，甚至讓我懷疑我到底是不是在用同一臺電腦。對於這個性能表現我非常滿意。

即使是 CLI 應用，Ubuntu 上跑起來也比 MacOS 上要更快，更利落。以我最常用的 Hugo 來說，hugo server甚至比我的 Windows 電腦要更快，以至於我甚至願意用它接上電腦來繼續寫文章。

續航是我最滿意的部分：得益於更加乾淨的系統和無風扇的設計，目前這臺 MacBook 一次充電可以連續使用一個下午加一個晚上，相當於超過 8 小時的亮屏時間。但需要注意 Tauri 應用的效率問題，體現在實際使用上就是儘可能少用 Clash Verge 的控制面板。只要使用得當，就可以獲得超過 MacOS 的續航體驗。

高分辨率支持還不錯，只要整數倍縮放就不會出現應用模糊的問題，但 200% 的縮放未免太大了一點，也許我該直接調調 DPI？

It’s not perfect

藍牙和揚聲器無法被驅動，我嘗試過打內核補丁，但毫無用處，這意味著外放根本不能用，藍牙耳機、鍵盤、鼠標也想都別想。鍵盤背光幾乎沒法用，想要黑燈瞎火的打字幾乎也是不可能的。前置 Facetime 攝像頭也無緣被驅動，雖然我在 MacOS 上也幾乎不用它。

觸控板的防誤觸約等於沒有，寫東西時非常容易被觸控板干擾，目前我的解決方案是在寫東西時用TouchPad Indicator⁴的快捷鍵直接禁用觸控板。但這樣的體驗自然就不如打磨過防誤觸的 MacOS。

雙指滾動的速度太快，導致我看網頁時不得不使用方向鍵滾動網頁。為了調整滾動速度，我試著從 Wayland 換到 Xorg，並用 Xinput 調整設置，但暫時還沒有看到成效。

各種驅動上的問題以及體驗上的小問題非常影響體驗。我知道，這些問題中的某一些可能只需要花些時間和精力去做些 tweaks 就可以解決。但要在折騰和生產之間取得一個平衡的話，我想我大概會保持現狀。

Wrap up

我第一次安裝 Linux 時用的是 Ubuntu 16.04 LTS，當時的我苦於 Linux 軟件生態的匱乏而試著去折騰 Wine，許久終於用上了一些必要的 Windows 軟件，最後卻因心累而換回了 Windows。今天，我同樣在安裝 Ubuntu，除了驅動問題外，我幾乎從沒有遇到任何麻煩，並且幾乎全程樂在其中。這次日常使用 Linux 的嘗試無疑是成功的。

我可以說 Linux 見證我成長。現在的我已經可以擁抱開源生態系統，很顯然，這次，我不再需要換回去了。

Canonical 維護著一份主流 GTK 主題的 Snap 移植，但每次安裝新的 Snap 應用都要手動切換，非常不方便。 ↩︎
相比之下，Homebrew 更像是一個命令行形式的 Appstore。當然我最喜歡的包管理器還得是 pacman。 ↩︎
Progressive Web APP，漸進式 Web 應用。 ↩︎
本質上就是調 Xinput。 ↩︎

Linux on 亂筆

Terraform IaC 初體驗

為什麼要用 Terraform

Terraform 的安裝

Terraform 的兩個基本概念

Provider(s)

狀態管理

Terraform 的資源導入難題

Terraform 的文件結構

將現有資源導入 Terraform

狀態存儲和持續集成

後續的工作流程

創建基礎設施

修改與刪除基礎設施

日常協作建議

參考

從入門到進階：Tailscale + ShellCrash 異地組網和科學上網

什麼是 Tailscale

Tailscale 的連接過程原理

中心控制服務器（Control Server）

DERP 服務器

NAT 穿透（NAT Traversal）

完整連接流程圖示

自建 DERP

為什麼要自建 DERP？

準備工作

docker-compose.yml

反向代理

配置 ACL 策略

測試連接

與科學上網並存：在 Exit Node 劫持流量到 Clash 內核

聲明 Exit Node

啟用 IP 轉發和禁用 UDP GRO4

在 Exit Node 劫持流量

進階：用 TProxy 劫持 UDP 流量

路由規則持久化

原理解釋：TProxy 到底是怎麼轉發 UDP 流量的？

iptables 規則持久化

最終效果

OBS 多路推流折騰記：那些本不必要的麻煩

明確需求

多路推流

Bilibili 直播姬

推流到 Twitch

Netch

尾聲

docker-mailserver 郵件服務器搭建記錄

搭建 docker-mailserver 郵件服務器前的準備

防火牆的處理

驗證你的服務器是否具備搭建條件

搭建過程

拉取配置文件

用 Caddy 準備和自動維護 TLS 證書1

首次啟動容器

優化送達率

DNS 記錄

DKIM, SPF 和 DMARC2

客戶端設置

善用 MailTester

TODO-List

Firefish 數據庫升級記錄

升級前的部署概況

導出當前數據庫

導出文件的處理

向新數據庫導入現有數據

收尾工作

科學上網：用 Caddy 反向代理 VLESS

安裝 VLESS 和 Caddy

配置 VLESS

配置 Caddy

啟動服務

客戶端設置

完成

TODO List

搭建一個 BT 離線下載服務器

安裝 Aria2

用 Caddy 反向代理

配置 Aria-NG

用 Alist 映射下載目錄

完成

啟用 IP 轉發和禁用 UDP GRO⁴

用 Caddy 準備和自動維護 TLS 證書¹

DKIM, SPF 和 DMARC²

創建掛載點並修改 `fstab`