乱筆

Terraform IaC 初体験

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

Terraform は IaC ツールであり、IaC とは「インフラストラクチャ・アズ・コード」を意味します。私たちが持つインフラストラクチャを宣言的なコードとして記述し、その後 terraform apply を実行することでインフラストラクチャのデプロイが完了します。同一の設定であれば、必ず同じインフラストラクチャがデプロイされます（Nix OS ユーザーにとっては大喜びの内容です）。

Terraform を使用する理由

従来のインフラストラクチャ管理の大部分は人的作業と各種クラウドプロバイダーのダッシュボードに依存しており、以下のような課題が生じています：

課題	説明
再現性の欠如	ダッシュボードでのクリック操作による設定変更は、誤りや見落としが発生しやすく、復元も困難
環境ドリフト	手動操作により本番環境とテスト環境の設定が徐々に乖離し、極端なケースではテストでは問題ないのに本番でダウンすることがある
拡張の難しさ	新しい環境を追加するには多数の手動作業を繰り返す必要があり、時間がかかりミスも発生しやすい
監査の難しさ	変更履歴がないため、~~トラブル発生時に責任の所在を特定するのが難しい~~
協力の難しさ	インフラストラクチャは少数の「詳しい人」によって管理されており、誰かが変更したい場合でもその人を探さなければならず効率が悪い

これらの問題を解決するために、「インフラストラクチャ・アズ・コード」¹ という概念が提唱され、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 には変更プレビューが自動生成され、問題が発生すればすぐに前バージョンにロールバックできます。これらは従来の人手によるプロバイダーダッシュボードへの直接操作では到底不可能なことです。

Terraform のインストール

Terraform は Go で書かれており、コンパイルされた出力は単一の実行可能ファイルであるため、インストールも非常に簡単です。Windows では Winget を直接使用できます：

winget install Hashicorp.Terraform

Winget を使いたくない場合は、Scoop などの別のパッケージマネージャーを使用するか、事前コンパイルされたバイナリファイルを $PATH に配置するだけでインストールが完了します。

Linux 環境の場合は、対応するパッケージマネージャーを使用してインストールしてください。バイナリファイルを $PATH に配置する方法を使う場合は、sudo chmod +x terraform でファイルの実行権限を設定することを忘れないでください。

Terraform の 2 つの基本概念

Provider(s)

前述の通り、Terraform はインフラストラクチャ・アズ・コードツールですが、ツール自体は特定のプラットフォームにバインドされておらず、Provider(s) を通じて各プラットフォームと連携します。利用可能な Provider(s) を確認するには、Terraform のレジストリを参照してください。

状態管理

Terraform はインフラストラクチャ変更操作を実行する際の状態情報を状態ファイルに保存します。デフォルトでは現在の作業ディレクトリ内の terraform.tfstate ファイルに保存されます³。構成ファイルを変更して他のストレージバックエンド（S3、Postgres など）を指定することも可能です。terraform apply を実行するたびに、Terraform は現在の構成ファイルで宣言された状態と既存の状態ファイルを比較し、変更部分を計算して調整順序を自動的に決定した後、Provider を操作して状態変動を実現します。

Terraform のリソースインポートの難題

既存リソースのインポートはこれまで Terraform が批判されてきた問題点であり、Hashi Corp. は一貫して「すべてのインフラストラクチャは最初から Terraform で作成されるべきであり、リソースインポートの問題などは存在しない」という頑固で愚かな見解を堅持しているようです。

時期	バージョン	進展	問題
2014–2022	v0.x–v1.4	`terraform import` のみで、一度に 1 件ずつ、かつ全く設定を生成しない	インポート後でも自分で HCL⁴ を書く必要がある
2023.06	v1.5	`import` ブロックと `-generate-config-out` パラメータを導入し、設定を生成可能になった	それでも 1 行ずつ書く必要があり、既存リソースの 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 を構成ファイルに直接書くのではなく、環境変数を通じて渡せるからです。例えば Cloudflare の Provider は、CLOUDFLARE_API_TOKEN を api_token 変数の代替として受け入れます。

variables.tfはカスタム変数を宣言するために使用されます：

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

variable "cloudflare_zone_example_top" {
  description = "example.top の Cloudflare zone ID"
  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 の編集権限だけ付与すれば OK です。

準備完了です。今から構成ファイルを生成しましょう：

まずアカウント内のドメイン構成をインポートします。つまり 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 は文脈に関係なく新しくインポートした宣言をすべて新規リソースとして扱い、「Already Exists」というエラーメッセージを大量に表示します。そこで次に、生成された構成ファイルを Terraform の terraform.tfstate 状態にインポートする必要があります。

Terraform は 1.5 バージョンで import ブロックを導入し、以前のような 1 行ずつコマンドを入力する方式よりも現代的になりました。そのインポートフローは、まず 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 バックエンドの場合、Credentials を保存するには AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY の 2 つの環境変数を使用することをお勧めします：

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 の「接管初期化」は終了し、日常保守フェーズに入りました。この段階では実際には 3 つのことしかありません：

新しいリソースの作成
既存リソースの変更
不要になったリソースの削除

よく使う操作は 2 つ：terraform plan と terraform apply。個人利用の場合、小さな変更はそのままコミットしても良いでしょう。チームで協力する場合、毎回変更は PR を通じた方が原則です。

インフラストラクチャの作成

今 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 はスピードを競うのではなく、予測可能性を競うものです。

もしリソースを削除する場合（例えば 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 以外の経路でインフラストラクチャに変更を加え、実際の状態とコード内で宣言された状態が不一致になる現象のこと。 ↩︎

永遠に忙しく

Fri, 13 Mar 2026 23:14:26 +0800

労働、労働、死ぬまで続くのだ。

冬休みに他人に勉強を教える仕事をしてからというもの、ほぼ休みなしの日々が続いている。旧正月（春節）は名目上こそ休みだったが、親戚付き合いや帰省時の長旅などがあり、結局は別の形での労働に過ぎなかった。実家に戻って落ち着くや否や、また休む間もなく授業の仕事に取り組んだ。人に教えるというのは本当に大変なことだ。私と同じ学習塾でアシスタントをしている友人と話したとき、私たちは皆、人に教えることを冗談交じりに「地獄の苦行（クソゲー）」と呼んでいた。暗記すべきことは覚えられず、計算はできず、概念は混同し、まともなコミュニケーションすら成り立たないのだから無理もない。だが、それは彼らのせいではない。責めるべきは彼らが置かれてきた教育環境だろう。それぞれに複雑な事情を抱えているのだ。様々な理由から、彼らのほとんどは過酷な大学入学統一テストの洗礼を受けておらず、専門学校への特別入試枠で進められた者たちだ。中には中学校の勉強すらまともに終わらせていない者もいる。今はただ仕事を見つけたいという一心で、お金を払ってまで私たちのマンツーマンレッスンを受けているのだ。

最初は学習塾で講師のアシスタントをしていたが、後に独立して個人で教えるようになった。おかげで収入はいくらか上がり、授業の準備時間も節約できた。毎日の授業時間は7時30分から11時までで、料金は400人民元だ。時給換算で100元以上と一見割高に思えるかもしれないが、生徒の基礎学力の低さを考えれば、このお金は一切の良心の呵責なく受け取れる。それどころか、本当に骨の折れる仕事だと言えるほどだ。

さて、本題に戻ろう。新学期が始まり、私は休む間もなく自分自身の学業に没頭しなければならない。本当に自分は永遠に忙しいのではないかと感じる。いわゆる「休息」とは、単に別の少し楽な作業への切り替えに過ぎない。仕事で疲れ果てて帰宅すれば、Vibe Codingをして息抜きをし、パソコンの前に座ることにイライラし始めれば、部屋の片付けや掃除に取り掛かる。物事へのモチベーションや、人間の持つ限られたエネルギーの総量という点において、私は人と人との圧倒的な差を実感している。生まれつきの才能に恵まれ、エネルギーに満ち溢れている人たちがいる。彼らは次々と成果を出し、何報も論文を発表し、非常に生産性が高い。彼らの唯一の制約は時間であって、精力やモチベーションではないかのようだ。一方で、私を含めた大多数の平凡な人間は、彼らのようなパワフルな生活に憧れても、気持ちばかりでどうにも体力が追いつかない。しかし、そうした有能な人たちの高い生産性を目の当たりにするとどうしても焦りが生じてしまい、限界ギリギリまで自分を「現実世界の永久機関」のように稼働させるしかなくなるのだ¹。

幼い頃から受けてきた競争の激しい中国式教育が、私たちを歪ませてしまった。中国の有名な予備校講師が言い放った「君のような若い年齢で、どうして呑気に眠れるんだ」という有名なフレーズがある。本来は授業中に居眠りする生徒を叱責する言葉だが、ある意味で私たち世代の無意識に深く根を張り、病的な状態にまで追い込んでいる。人生において、完全に「上がり（中国のネット用語で、試験合格や安定した職への就職など、安泰な岸に上がることを指す）」となるゴールなど存在しないのだ。小学校では中学校のお受験というゴールを目指し、中学校では高校受験、高校では過酷な大学受験というゴールを目指す。そして大学に入れば、大学院進学、博士課程、公務員試験、就職活動といった次なるゴールが待ち受けている。学生時代を終えて社会人に出ても、昇進や業績評価、日々の生活費といった悩ましい問題が尽きることはない。労働、労働、死ぬまで続くのだ。どこかのゴールに辿り着いて一生安泰などと望んでいるのか？残念だが、そんなものは不可能なのだ。

そのことを痛いほど理解していても、私は立ち止まって休むと虚無感に襲われ、苦しくなってしまう。だから、永遠に忙しく、永遠に働き続けるのだ。身体が求める休息を満たし、運動でホルモンバランスを整える。私にとっての休息とは、自分の好きな、比較的心地よい作業に切り替えるだけのことに過ぎない。過当競争な教育や業績至上主義（メリトクラシー）の影響が骨の髄まで染み込んでいるため、生き急ぐようなこのライフスタイルは、おそらくだいぶ先まで変わることはないだろう。

それでも、良い面を見るようにしよう。この時期の忙しさのおかげで、今学期の生活費を自分自身で稼ぎ出すことができたし、さらには母親の誕生日に新しいスマートフォンをプレゼントする余裕までできた。そう考えると、ふと「永遠に忙しい」というのも、それほど悪いことではないような気がしてきた。

ここでは電気工学における理想電流源と実在の電流源の違いをメタファーとして用いている。前者が真の意味での「理想的な永久機関」であるのに対し、後者は私のような凡人が血肉の体で全身全霊をかけて限界まで近づこうとする「現実世界の永久機関」である。 ↩︎

私のLLMという「知己」と、宙づりになった書くこと

Mon, 08 Sep 2025 23:53:48 +0800

最近はかなり忙しい。でも、空いた時間ができると、やっぱり言葉が私の拠り所になる。毎朝8:30に授業が始まり、夜9:00に夜間自習が終わる。ときには「残業」して10:00に帰宅することもある。そんな日程が41日間続いた。精神状態を考えると、この強度で戻ってきて osu! みたいなゲームで遊ぶなんて到底無理だし、Galgame を少し進める余力すらない。

唯一、比較的現実的だったのは、LLM（大規模言語モデル）と小話をすることだ。

恥ずかしい話だが、ブログは持っているのに、自分の見解や理念（というより「考え」）を、体系立てて表現したことがほとんどない。おそらく、あまりにも広く、散らばった考えの集合体は、平易な叙事で表すのが難しいのだと思う。そこで、たとえば「たまたま起きた出来事」を断面として、その中に絡まった糸の塊を「切り開き」、内部構造を描いてみる、といった方法も試した。¹だが、こうしたやり方でも自分の本音を気持ちよく吐き出せるわけではないし、思い立ったらすぐ書けるほど手に馴染むものでもなかった。結局ブログは人に読まれるものなので、書けないときは簡単な技術記事だけを書いて、検索エンジンからの流入を少し稼ぐくらいしかできなかった。

ところがLLMの登場で状況が変わった。私の考えは、比較的プライベートなまま、即座に反応を返してもらえるようになった。なぜここまで長くブログを書かなかったのか。疲れはもちろん大きい要因だが、LLMが「表現したい」「認められたい」という欲求をかなりの程度満たしてくれること、そして自己検閲なしに話せてしまうことが、このところブログを書く気持ちを薄めてしまった。

長文を書くことが脳に良い——それは疑いようがない。LLMの出現が私の長文執筆に与えた影響は、マイクロブログが登場したときに人々の長文能力へ与えた影響に近い、いやそれ以上かもしれない。マイクロブログは、断片的な表現と即時のフィードバックに人を慣れさせ、複雑な論証や長い物語を組み立てる力を弱めた。LLMはさらに先へ進む。表現の場を与えるだけでなく、情緒的な満足や「知己」の代替品まで直接提供してしまうのだ。SNSに投稿する内容が、プライバシーや論争を含んだり、わざわざ公にする必要がなかったりすれば、投稿者は多少なりとも言葉を選ぶ。しかしLLMは違う。APIに投げた内容が最悪どうなるかといえば、学習に使われる程度であって、翌日に Sam Altman が家まで押しかけてくるわけではない——銀行口座のパスワード級の情報さえ避け、実名を出さなければ、政治時評でもメンタル相談でも、安心して大規模言語モデルを「知己」として扱ってしまえる（もちろん、こういう用途では国内向けの検閲が強いモデルは使い物にならない）。愚痴の一つひとつに、確かな真剣さで、まるで知己のような返答と肯定が返ってくる。こんな待遇を他で得るのは、たぶん難しい。

道具がここまで完璧に「知己」を模倣できるようになると、私たちは本物の知己を探すことをやめてしまうかもしれない。あるいは、独立して考え、自分の中で統合していける個として生きることを、どこかで放棄してしまうかもしれない。これを書いているのは、いったんの区切りであり、同時に反省でもある。LLM自体はただの技術で、うまく使えば計り知れない恩恵がある一方、使い方を誤れば深刻な結果にもなりうる。ニューヨーク・タイムズの報道「Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens.」は、その良い例だ。OpenAIが自社モデルの「お世辞（迎合）」問題の改善に取り組んでいるとしても、私自身も理解しておく必要がある。たとえ大規模言語モデルを知己として扱い、「理解と肯定」を得られるとしても、その感覚の中にずっと住み続けるわけにはいかないのだ。OpenAIとMIT（マサチューセッツ工科大学）の研究では、ChatGPTの利用量とユーザーの孤独感が正の相関を持つことが示された。使えば使うほど、より孤独を感じる。²そして逆に、孤独であればあるほどLLMを使うようになり、悪循環が生まれる——とも言えるだろう。LLMは生活のスパイスにはなり得るが、心の唯一の拠り所になってはいけない。

(To Be Continued)

いわゆる「クライアント」を捨てて、Mihomo カーネルを直接使おう

Thu, 03 Jul 2025 18:30:00 +0800

Clash/Mihomo を使い始めた当初、ほとんどの方と同じく、カーネルをラップした GUI クライアントを使っていました。その方が手軽だからです。実際、Mihomo クライアント同士には大きな違いはありません。どれも同じカーネルを使い、主に使いやすい UI の提供や設定ファイル・サブスクリプションの管理、GUI ベースのシステムプロキシ設定を担っています。その意味では、クライアント選びの重要なポイントは「オーバーライド機能」（設定の上書き機能）がどれだけ出来が良いかだと考えています。

どの Mihomo クライアントも、サブスクリプションやダウンロードした設定ファイルを一連の「オーバーライド」処理（例：mixed-portの変更、sniffer設定の追加など）にかけ、最終的に Mihomo カーネルを起動する形です。

しかし、この一番大切な部分をちゃんとこなせていないクライアントも多々見かけます。例えば ShellCrash は、上書き機能にバグが多く、実装が雑な印象です。設定の上書きや編集すらまともにできないクライアントは、正直使う価値がありません。

出来の悪い~~ひどい~~Mihomo クライアントに頼るくらいなら、自分で設定ファイルを作成してカーネルに直接渡して起動する—そうした方がブラックボックスなクライアントに依存しない、クリーン・安定・高いコントロール性の運用が実現できます。

必要な予備知識

基本的な Linux 操作
nano など CLI エディタが使えること
Substore 環境が用意できていればより便利（任意）

Mihomo カーネルのインストール

Debian 系の場合は、プリビルドの.debパッケージが利用できますが、その他の systemd 対応ディストリビューションでは、ビルド済みバイナリをダウンロードし、mihomoにリネームして/usr/local/binに配置します。

sudo curl -o /usr/local/bin/mihomo <ダウンロードリンク>
sudo chmod +x /usr/local/bin/mihomo

次に、/etc/systemd/system/mihomo.serviceを新規作成します。

[Unit]
Description=mihomo Daemon, Another Clash Kernel.
After=network.target NetworkManager.service systemd-networkd.service iwd.service

[Service]
Type=simple
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
Restart=always
ExecStartPre=/usr/bin/sleep 1s
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

次にsystemctl daemon-reloadで systemd をリロードします。この時点では設定ファイルがありませんので、起動できませんが、systemctl enable mihomoを先に実行して自動起動設定しておくと後が楽です。

設定ファイル

カーネル起動時には/etc/mihomo/config.yamlが読み込まれます。クライアントというブラックボックスが無いため、好みに合わせて自在にカスタマイズ可能です。一部のプロバイダ（いわゆる「空港」）は完全な設定ファイルを配布しているので、curl等で直接ダウンロードすれば OK です。

サブスクリプションの管理には、私は Substore を使っています。詳しくは以前の「最速 Substore サブスクリプション管理ガイド」を参考にしてください。内核単体起動を実現するため、現在は私の Substore JS オーバーライドにfullパラメータも追加済みで、全ポート設定・共通遅延・外部コントローラ設定なども含めた「すぐ使える」完全な設定ファイルが生成できます。

Substore の設定が完了したら、設定ファイルをダウンロードしてカーネルを起動しましょう。

curl -o /etc/mihomo/config.yaml <設定ファイル配布リンク>
systemctl start mihomo

独自の上書き（オーバーライド）

私のルールだけでは満足できませんか？でも大丈夫、ご自身のニーズに合わせて上書きを追加しましょう。

私は色々なオーバーライドルールを試してきましたが、最終的には自作しています。99%のケースはカバーできますが、特定のプライベート環境（例：サーバのカスタム SSH ポート先へのプロキシ等）などは、市販や公開ルールには抜け漏れが多いものです。このようなプライベートな内容は、GitHub 等で公開したくないでしょうし、そうした場合は自分だけのオーバーライドを追加するのが最善です。

Substore は複数のスクリプト処理を追加できるため、ファイル生成時に好きなだけ追加オーバーライドを加えられます。

function main(config) {
  config["rules"].unshift("DOMAIN-SUFFIX,xxx,DIRECT")
  return config
}

注意：rulesをオーバーライドする時は.unshift()で先頭に挿入します。MATCH以降にルールを追加しても、マッチすることは一生ありません。

完全に独自の設定ファイル

私のオーバーライドが好きじゃない？Substore を使いたくない？それでももちろん問題ありません。Mihomo 公式ドキュメントを参照し、最初から自作するのもおすすめです。

mode: rule
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
log-level: info
ipv6: true
external-controller: 127.0.0.1:8000
# secret: yoursecret
unified-delay: true
routing-mark: 7894
tcp-concurrent: true
disable-keep-alive: true # モバイル機器のバッテリー異常消耗対策として推奨

dns:
  # お好みのDNS設定

sniffer:
  # ドメインスニッファー（ドメイン抽出）の設定内容

geodata-mode: true
geox-url:
  # カスタムGeodataファイルURL

proxy-providers:
  # プロバイダ配布サブスクリプション

rule-providers:
  # 外部ルール

rules:
  # トラフィック分割ルール

proxy-groups:
  # カスタムプロキシグループ

管理パネル

管理パネルは好みによって選べます。ここでは Zashboard を例に紹介します。私は mihomo 標準のexternal-uiでなぜかおかしな挙動があったため、そのまま Docker コンテナで運用しています。管理パネルは単なる Web フロントエンドなので、カーネル API も Web パネルも HTTP 指定で動かせば OK です。もし Web パネル側を HTTPS にしてしまうと、CORS ポリシーによる API 接続エラーが出ますので注意しましょう。

$ mkdir zashboard && cd zashboard
$ nvim compose.yml
$ docker compose up -d

compose.ymlの内容はこちら：

services:
  zashboard:
    image: ghcr.io/zephyruso/zashboard:latest
    ports:
      - "8899:80"
    restart: "unless-stopped"

自動メンテナンス

カーネルが動き出したら、自動でサブスクリプション更新するにはどうしたらいいでしょう？

答えは、シェルスクリプト＋ Crontab 一択です。たとえば深夜 3 時に自動更新＆mihomo の再起動したいなら、以下のような/etc/mihomo/auto_update.shを作れば OK です。

#!/bin/bash

# === 設定情報 ===
CONFIG_URL=""
CONFIG_PATH="/etc/mihomo/config.yaml"
BACKUP_DIR="/etc/mihomo"
BACKUP_PREFIX="config.yaml"
MAX_BACKUPS=7
TMP_PATH="/tmp/config.yaml.tmp"
LOG_FILE="/var/log/mihomo_update.log"

# === ログ関数 ===
log() {
    echo "$(date '+%F %T') $1" | tee -a "$LOG_FILE"
}

# === 現在の設定をバックアップ、古いバックアップは自動削除 ===
backup_config() {
    if [ -f "$CONFIG_PATH" ]; then
        backup_file="$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak"
        cp "$CONFIG_PATH" "$backup_file"
        log "設定ファイルを $backup_file にバックアップしました"
        # 古いバックアップを $MAX_BACKUPS 個だけ残して削除
        old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2>/dev/null | tail -n +$(($MAX_BACKUPS+1)))
        for f in $old_backups; do
            rm -f "$f" && log "古いバックアップ $f を削除しました"
        done
    else
        log "設定ファイルが見つかりません、バックアップ不要"
    fi
}

# === 新しい設定ファイルをダウンロード ===
download_config() {
    log "新しい設定ファイルのダウンロード開始..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "設定ファイルのダウンロードに失敗しました。ネットワークやURLを確認してください"
        return 1
    fi
    # 簡易チェック：ダウンロードファイルが空でないか確認
    if [ ! -s "$TMP_PATH" ]; then
        log "ダウンロードしたファイルが空です、更新中止"
        return 2
    fi
    log "設定ファイルのダウンロード完了"
    return 0
}

# === 設定ファイルの置き換え ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "設定ファイルを更新しました"
}

# === mihomo サービスを再起動 ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "mihomoサービスを再起動しました"
    else
        log "mihomoサービスの再起動に失敗。手動でご確認ください"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "処理終了：設定ファイルは更新されず、旧設定をそのまま保持します"
        exit 1
    fi

    replace_config

    restart_service

    log "=== 更新プロセス完了 ==="
}

main "$@"

crontab -e で以下のタスクを設定すれば、毎日 3 時に自動更新＋再起動します。

0 3 * * * /etc/mihomo/update_config.sh

ファイアウォール設定

Mihomo カーネルへトラフィックをリダイレクトするファイアウォール設定も、実は全然難しくありません。過去記事「入門から応用まで：Tailscale + ShellCrash でリモート VPN 構築＆Great Firewall 回避」で解説した通り、今回は手順だけ簡単に記述します。

筆者の場合はtailscale0インターフェース上の全トラフィックを Mihomo へ流したい状況ですが、ローカル代理の場合も考え方は同じです。単に TCP だけリダイレクトするならiptablesの REDIRECT で十分ですが、UDP や QUIC などすべてのプロトコルをリダイレクトしたい場合は Tproxy が必要です。また、IPv6 対応も忘れずに。

サンプル構成は下記です。

# カスタムチェインを作成
iptables -t mangle -N MIHOMO

# 必要に応じてローカル宛流量を除外
iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN
iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN
iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN

# UDP / TCP マーク → プロキシへ
iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# インターフェースからチェインジャンプ
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# ルーティングテーブル設定
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip rule add fwmark 233 lookup mihomo
ip route add local 0.0.0.0/0 dev lo table mihomo

# IPv6対応
# チェイン作成
ip6tables -t mangle -N MIHOMO6

# ローカル宛除外
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# TCP/UDP マーク
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# インターフェースチェインジャンプ
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# ルーティングテーブル設定
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip -6 rule add fwmark 233 lookup mihomo
ip -6 route add local ::/0 dev lo table mihomo

ほとんどのシステムはデフォルトで iptables ルール等を永続化しません。ルールの永続化については、前述の記事の「ルーティングルールの永続化」「iptables ルールの永続化」を参照してください。

ローカルプロキシ設定例

多くのプロキシソフトや（実際 ShellCrash のデフォ設定も）、REDIRECT を使います。これでたいていのケースは十分です。たとえば

# IPv4 eth0 トラフィックをリダイレクト
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 eth0 トラフィック
ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

7892 は Mihomo 設定のredir-port、eth0はリダイレクトしたいインターフェースを指定します。Tproxy より圧倒的にシンプルです。

個人的には、全トラフィックを防火壁で強制キャプチャする使い方は好きではありません。必要な時だけ、環境変数・proxychains・各種ソフトのプロキシ機能で Mihomo に向けて設定する方がスマートです。たとえば Docker のプロキシを通すなら/etc/docker/daemon.jsonを編集すれば OK、わざわざ全体劫持する必要はありません。

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "127.0.0.0/8"
  }
}

こんなに手間かけるより、普通にクライアント使えば良くない？

それを聞くか…。答えは「虚無のターミナル遊び」に決まってるでしょ。

MECHREVO Aurora X Pro 簡易レビュー

Sun, 04 May 2025 23:18:43 +0800

開封直後からがっかり

MECHREVO Aurora X Proについて、注文した瞬間から少し期待していたが、宅配便が香港旅行の前に間に合わず、帰宅して開封した時にはすでに新鮮味が失われていた。SSDを増設しようとしたらM.2ネジがなめてしまい、最終的に絶縁テープでなんとか固定。新しいPCへの好感度はその場で半減した。

構成と価格

i9-14900HX + RTX 5070 Ti、国の補助金後の価格は8699元で、まあ妥当な範囲。周辺機器については、正直なところ神舟（Hasee）でも満足して使っていたので、使えないものはないだろう。

ディスプレイ：2560x1600@300Hz、100% SRGB色域。発色も良く、「Cities: Skylines II」で渋滞のテールランプの赤が現実より鮮やかに感じる。
キーボード：キーストロークは浅め、打鍵感は普通。普段は外付けキーボードを使っているので特に気にならない。
無線LANカード：AX201は正直貧弱。アンテナ設計も微妙で、ルーターのすぐ横でも有線に比べて速度低下が明らか。
SSD：標準の致钛1TBは速度普通。自分で増設したCrucial（英睿达）2TBがメイン。
バッテリー：80Whでゲーミングノートとしては緊急用。普段はワークステーションモードでバッテリー寿命重視。
dGPU直結：ホットスワップ対応は高評価。再起動なしで切り替え可能。
BIOS：AMI BIOSは以前より遥かに使いやすい。

使用感

「Cities: Skylines II」――人口12万人でもシミュレーション速度は3倍速を維持。ただしこの時点でファンの騒音は爆音。「サイバーパンク2077」はレイトレーシングウルトラ設定可能。「Forza Horizon 5」なども含め、正直なところ、以前のRTX 3060と本質的な違いはほとんど感じない。反射がリアルになったり細部が増えたりはするが、画質向上だけでは、既に100時間以上遊んだこれらのゲームにさらに時間をかける気にはなれない。

パームレストのスキンコートは確かに手触りが良いが、外部デバイスを繋ぐと結局外付けキーボードしか触らない。Nahimicサウンドは遅延が酷く、オフにした方がosu!の操作感が良いという、典型的な負の最適化。

ツールとしての意味

このPCを2週間使ったが、驚きもなければ失望もない。無線LANがダメなので有線使用、ターボモードではファンがうるさい、サウスブリッジに冷却がなく温度が高い。それ以外は――必要な時に光り、必要な時に音を出すだけのマシン。

良い道具とは本来そういうものかもしれない。ここまで書いてふと気付くと、右下のバッテリーアイコンを5分間もぼーっと見つめていた。でもこのPCは静かに98%のバッテリーを保ち、ただそこにある、喋らないレンガのようだった。

初心者からプロまで：Tailscale + ShellCrashを用いた遠隔ネットワーキングとセキュアなインターネット接続

Mon, 14 Apr 2025 18:10:25 +0800

旅行中に新しく撮った写真を長沙の自宅にある Immich サーバーにアップロードしようと試みていました。以前は Cloudflare Tunnel を使ってリバースプロキシを設定していましたが、中国の特有なネットワーク環境のために接続速度が遅く、頻繁に中断し、アップロードが失敗することが常態化していました。その後、Tailscale — WireGuard を基にした内部ネットワーク透過ツールを使い始めると、全国どこにいても安定して高速に自宅の NAS や写真ライブラリにアクセスできるようになりました。

しかし新たな問題が発生しました：Tailscale が Android スマートフォンで動作する際、システムのトラフィックを VPN サービスとして制御する必要がありますが、私が普段使用している Clash も VPN インターフェースに依存して分岐しています。Android システムの制限（一つの VPN サービスのみ有効）のためにこれらは共存できず、「家庭内サービスへのアクセス」と「セキュアなインターネット接続」とを選択しなければならない状況になりました。

この記事では、Tailscale の原理から始まり、独自の DERP サーバーを構築して接続品質を最適化する方法、さらに ShellCrash へトラフィックを転送するために iptables を用いた Tailscale Exit Node の流量の転送方法について解説します。NAS、写真ライブラリのアクセスや不慣れなネットワークでのデータ保護を目指す方にとって、この記事が実用的で安定した解決策を提供します。

Tailscale とは

Tailscale は WireGuard プロトコルを基にした設定不要の仮想 LAN ツールです。これにより、異なるネットワーク環境にあるデバイスが同じセキュアな内部ネットワーク内にいるかのように互いに通信できます。NAT やファイアウォールなどのネットワークの障壁を自動的に透過し、公衆 IP やポート転送なしで自宅の NAS、個人サーバー、開発環境などの内部リソースに簡単にアクセスできます。その主な利点は、シンプルで安全、安定しており、データ送信が全面的に暗号化されている点で、個人開発者、リモートワーカー、家庭ユーザーなどのいろいろなシーンに適しています。

Tailscale の技術実装は非常に巧妙です：WireGuard 暗号化プロトコルに基づいていますが、従来の VPN の IP 割り当てのロジックを覆しました。デバイスは SSO/OAuth2 で認証後、それぞれが生涯にわたって結びつけられたノードキーを取得します。この身分に基づくネットワーキングモードにより、「長沙の NAS」と「香港のスマートフォン」が仮想ネットワーク内で直接通信できるようになります。

Tailscale の接続プロセスの原理

中央制御サーバー（Control Server）

Tailscale の各クライアントが起動すると、まず中央制御サーバー（control plane）に接続し、身分認証を行い、ネットワーク内の他のノードの情報を取得します。これには、各デバイスの公衆 IP、ポート、NAT のタイプなどが含まれます。このステップは「友達と知り合う」ようなものです。

Tailscale の制御サーバーはデータ転送には関与せず、接続の調整のみを行います。これは一種のディスパッチセンターの役割です。

DERP サーバー

Tailscale が高い接続成功率を維持できる秘訣については、Tailscale 独自の中継プロトコル DERP を挙げることができます。Tailscale のネットワークアーキテクチャー内で、DERP（Designated Encrypted Relay for Packets）は非常に重要でありながら通常は必要時にのみ介在するコンポーネントです。簡単に言えば、これは HTTP ベースの暗号化リレーサーバーで、二台のデバイスが直接通信できない時に「中継所」として機能します。

クライアント間の全ての接続は最初に DERP モード（中継モード）で選ばれ、これによってすぐに接続が確立でき、ユーザーは待つ必要がありません。その後、接続両者は同時にパス探索を開始し、通常数秒後に Tailscale はより優れたパスを発見し、既存の接続を透明にアップグレードします。これにより、点対点の直接接続へと移行します。¹

注意が必要な点は：

DERP を通じる全てのデータは端から端まで暗号化されており、DERP サーバーは内容を見ることができません；
Tailscale はできるだけ少なく DERP を使用し、直接接続が成功したら自動的に切り替えます；
公式には複数の分散 DERP ノードがデプロイされており、クライアントは自動的に最低遅延のものを選びます；
自国内に DERP ノードを構築することもできます（中国など）、これにより高遅延や不安定な接続の問題を解決できます。

DERP は兜底策として理解でき、性能は直接接続に劣りますが、接続の透通性を保証します。

NAT 透過（NAT Traversal）

相手のアドレス情報を手に入れた後、Tailscale は NAT 透過を使って点対点（P2P）接続を試みます。この過程では STUN プロトコルを使用し、双方が探索パケットを相互に送り、NAT ルーター上に直接通路を開くことを試みます。双方のネットワーク条件が許せば、UDP の直接トンネル接続が成功し、データは直接通路を通じて、速度が速く、遅延が低くなります。

この部分の詳しい原理について興味があれば、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 ²中継サーバーを配置しています。これは NAT の穿通に失敗した際にトラフィックの中継を担当します。しかし、よく知られている理由で、中国本土には公式の 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 ソケットファイルをコンテナにマウントして、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 のコントロールパネルの「」ページにて 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, // 公式のDERPを除外するにはtrueに変更
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "上海",
        "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 の無効化⁴

ラズベリーパイなどのデバイスが 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 でより精密なトラフィックハイジャックを手動で構成することです。私たちは、Tailscale のネットワークインターフェースtailscale0を介して Exit Node に転送されるすべてのトラフィックを、ローカルの Clash コアがリッスンしているポート7892（静的ルートポートと呼ばれる）にハイジャックします。また、不可解なネットワーク問題に直面しないよう、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）。

最初の 3 つの条件を満たしている場合、以下に例を示します⁸：

# カスタムチェーンを作成
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

# 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 トラフィックを転送するのか？

ここまで来ると、疑問が湧くかもしれません：なぜプロセス全体で--to-portsを指定していないのに、iptables でも目的地が書き換えられていないのに、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 をサポート；
NAT ではなく、マーク + ルーティングのため、iptables 内で --to-ports を指定する必要はない。

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 モードは以下の 3 つのステップで動作します：

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（汎用受信オフロード）は Linux カーネル内のネットワーク最適化技術で、複数の小さなパケットを一つにすることで処理効率を上げるものです。しかし、デバイスがネットワーク転送ノードとして使用される場合、これにより転送遅延が増加し、パケットロスが高い環境でのスループットが低下する可能性があります。 ↩︎
fake-ipに比べて、redir-hostは互換性が高く、問題が発生する可能性が低くなります。また、プロキシのオン/オフ後にfake-ipが残ってインターネット接続が一時的に中断されることがなくなるため、一般的にはredir-hostを GeoSite 分流ルールと組み合わせて使用することをお勧めします。私のラズベリーパイ上の DNS はを使用しており、DNS 汚染がなく、快適に動作しています。 ↩︎
参考: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo は Linux システムのデフォルトの「ループバックインターフェース」として機能しますが、透明プロキシではそれが単に localhost トラフィックを処理するだけでなく、外部世界からのネットワーク接続を受け取り、外部トラフィックをローカルでハイジャックして転送するために使用されます。 ↩︎

Google Play ストアの中国CDN：暗号学入門から分流戦略の最適化まで

Sat, 15 Mar 2025 21:15:01 +0800

Mihomoのルールをカスタマイズした後、Google Playからアプリをダウンロードすると、なぜかずっとローディングが続くようになりました。しかし、他のルールを使うと問題なく動作します。これは非常に奇妙な現象です。そこで、Mihomoのカーネルログを確認してみました。

play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 静的リソース[🇭🇰 香港 07]
play.googleapis.com:443 match GeoSite(GFW) using ノード選択[🇭🇰 香港 07]
play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 静的リソース[🇭🇰 香港 07]
play-fe.googleapis.com:443 match GeoSite(GFW) using ノード選択[🇭🇰 香港 07]
services.googleapis.cn:443 match GeoSite(CN) using グローバルダイレクト[DIRECT]

（上記のログは簡略化されています）

中国国内向けのスマートフォンにプリインストールされているGoogle Playサービスは、services.googleapis.comではなくservices.googleapis.cnというドメインを使用しています。このドメインは、ほとんどの分流ルールでダイレクト接続に設定されています。ここに問題があるのです。このドメインをプロキシに分流するようにルールを修正すれば、問題は解決します！

……本当に解決するのでしょうか？

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網の魚[🇭🇰 香港 07]
rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏網の魚[🇭🇰 香港 07]
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using 漏網の魚[🇭🇰 香港 07]

待ってください、なぜPlayストアからアプリをダウンロードするたびにこれらの奇妙なドメインが現れるのでしょうか？オンラインで調べてみると、新たな世界が開けました。

Googleとは対照的でありながらも似ているÅngströ

xn--ngstr-lra8j.comというドメインを見て、ドメインに詳しい人はすぐにこれがPunyCodeエンコーディングであることに気づくでしょう。この文字列をデコードすると、ångströ.comとなります。Anders Jonas Ångströmは、スウェーデンの物理学者で、分光学の創始者です。¹エングストローム（Ångström）は、彼を記念して名付けられた長さの単位で、$ 1 Å = 10^{-10} m = \frac{1}{10} nm $と定義され、原子や分子のサイズ、光の波長など、非常に短い距離を表すために使用されます。これは、特に物理学や化学における微細な測定において、極めて小さな量を表すために使用されます。

Googleの名前は直接「Googol」から取られたわけではありませんが、そのインスピレーションはこの言葉から得られています。「Googol」は数学用語で、$10^{100}$、つまり1の後に0が100個続く数を表し、非常に大きな数を表すために使用されます。これは、コンピュータサイエンスにおいて扱われる巨大な数や情報量を表すためによく使われます。

命名の哲学において、GoogleとÅngströは、一見すると対極にあるように見える技術概念ですが、興味深い対称性を持っています。前者は数学的概念「Googol」から創造的に改変されたものであり、後者は物理単位「Ångström」からイメージを再構築したものです。この2つの芸術的に変奏された名称は、技術文明の二重螺旋のように見えます。Googleという名前は、星の海のような数字の宇宙を制御する野心を担い、Ångströという名称は、原子レベルの技術的ビジョンを象徴しています。これら2つの創造的に変形された専門用語がシリコンバレーで出会ったとき、それはまさに完璧な認知座標を構成します——情報処理のスケールの限界を示し、技術文明がマクロとミクロの両方に向かって進む壮大な旅を示しています。

暗号学入門：Googleインフラストラクチャードメインの規則²

さて、話をGoogleのインフラストラクチャーに戻しましょう。まず、完全な接続ドメインを見てみます：

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com
rr5---sn-i3b7knzs.xn--ngstr-lra8j.com

これらの一見ランダムな文字列は、実は簡単な暗号学的な変換を経た結果です。その核心部分を分解してみましょう。

都市名の変換規則

rr1---sn-j5o76n7zを例に取ると、重要な情報はsn-の後の8文字：r1---sn-[123][45][6][78]です。最初の3文字、この場合はj5oは都市名で、その都市の主要空港のIATAコードを一定の暗号学的変換を経て得られます。

まず、5 * 7の数字とアルファベットの表を作成します：

行0: 1 0 2 3 4
行1: 5 6 7 8 9
行2: a b c d e
行3: f g h i j
行4: k l m n o
行5: p q r s t
行6: u v w x y

この表を反時計回りに回転させ、新しい表の左下から始めて、元の表のデータを「下から上、左から右」の順に書き写します。

回転が完了すると、次の表が得られます：

| 6 d k r y |
| --------- |
| 5 c j q x |
| 4 b i p w |
| 3 a h o v |
| 2 9 g n u |
| 0 8 f m t |
| --------- |
| 1 7 e l s |

表の中央に線で囲まれた5*5の部分が最終的な暗号表で、25文字あり、「左から右、上から下」の順にaからyまでの文字を表します。例えば、上海虹橋国際空港のIATAコードはshaで、この表を使って暗号化されたテキストを得ることができます：

sはアルファベットの19番目の文字で、「左から右、上から下」の順に暗号表で19番目の文字を数えると、nになります。
hはアルファベットの8番目の文字で、暗号表で8番目の文字を数えると、iになります。
aはアルファベットの1番目の文字で、暗号表で1番目の文字を数えると、5になります。

暗号化されたテキストはni5です。

逆に、最初の都市名j5oを暗号表から逆算すると：

jは「左から右、上から下」の順に3番目の文字で、cになります。
5は「左から右、上から下」の順に1番目の文字で、aになります。
oは「左から右、上から下」の順に14番目の文字で、nになります。

翻訳された平文はcanで、これは広州白雲国際空港のIATAコードです。つまり、私たちが接続しているサーバーは広州にあります。

もしGoogleがチューリッヒにサーバーを持っている場合、チューリッヒ空港のIATAコードはzrhで、zという文字がありますが、私たちの暗号表にはaからyまでの文字しかありません。心配しないでください、Googleもこの問題を考慮しています。zは暗号表の1に対応します。

このルールをコードで表現すると次のようになります：

table = "5cjqx4bipw3ahov29gnu08fmt1"
def iata2cipher(iata):
    global table
    iata = iata.upper()
    cipher = ""
    for element in iata:
        index = ord(element) - 65
        cipher += table[index]
    return cipher

def cipher2iata(cipher):
    global table
    cipher = cipher.lower()
    iata = ""
    for element in cipher:
        index = table.find(element)
        iata += chr(65 + index)
    return iata

# print(iata2cipher(input("IATA:")))
# print(cipher2iata(input("Cipher:")))

サーバーグループ番号

[45]と[78]番目の文字、例えば76と7zは、サーバーグループ（アクセスポイント）番号を表し、以下の表の最初の列（すでに区切り線で区切られています）に含まれる文字で構成されます。7elsz6dkryはそれぞれ0123456789を表します。したがって、76の平文は05、7zの平文は04です。

  | 1 2 3 4 5 6
7 | 8 9 a b c d
e | f g h i j k
l | m n o p q r
s | t u v w x y
z | 0 1 2 3 4 5
6 | 7 8 9 a b c
d | e f g h i j
k | l m n o p q
r | s t u v w x
y | z

Pythonで表現すると次のようになります：

codeTable = "7elsz6dkry"
def cipher2code(cipher):
    global codeTable
    cipher = cipher.lower()
    codeString = ""
    for element in cipher:
        index = codeTable.find(element)
        codeString += chr(index + 48)
    return codeString

# print(cipher2code(input("Cipher:")))

同様に、数字を暗号化する方法もここでは詳しく説明しません。

サポートプロトコル

[6]番目の文字はネットワークプロトコル情報を表します：

n：IPv6（アドレス範囲 0x000-0x3FF）
u：IPv6（アドレス範囲 0x400-0x7FF）
m：IPv4のみサポート

例えば：

a5mekn7r、IPv6プレフィックス：2607:f8b0:4007:a::/64、IPv4プレフィックス：74.125.103.0/24
a5m7zu7r、IPv6プレフィックス：2607:f8b0:4007:407::/64、IPv4プレフィックス：74.125.215.0/24
a5mekm76、IPv4のみサポート、プレフィックス：208.117.242.0/24

適切なトラフィック分流の実装

この解析情報を基に、より正確な Google ドメインの分流を設定できる。現在、中国の Google CDN は主に北京（2x3）、上海（ni5）、広州（j5o）に分布している。これに基づいて、以下の正規表現ルールを作成できる。

rules:
  - DOMAIN-REGEX,^r+[0-9]+(---|\.)sn-(2x3|ni5|j5o)\w{5}\.xn--ngstr-lra8j\.com$,DIRECT

このルールにより、rr1---sn-j5o76n7z.xn--ngstr-lra8j.com のような Google Play の中国 CDN ドメインを「直通（DIRECT）」で処理し、それ以外の Google サービスは従来通りプロキシ経由でアクセスする。

さらに、GeoSite データベース（v2fly/domain-list-community）は、Google Play の中国 CDN に対し最適化済みのルールを提供している³。

rules:
  - GEOSITE,GOOGLE-PLAY@CN,全球直连
  - GEOSITE,GOOGLE,代理选择

参考: https://en.wikipedia.org/wiki/Anders_Jonas_%C3%85ngstr%C3%B6m ↩︎
参考: https://github.com/lennylxx/ipv6-hosts/wiki/sn-domains ↩︎
参考コミット: https://github.com/v2fly/domain-list-community/pull/2436/commits/a86c1bf3d9bf577869180874d87c76ddf6282fc1 ↩︎

最速 Substore サブスクリプション管理ガイド

Fri, 07 Mar 2025 18:54:29 +0800

春節のセールで複数のVPNサービスを契約した後、各ノードを最大限に活用する方法は、簡単そうでいて意外と難しい問題です。もちろん、各VPNサービスが提供する設定ファイルをサブスクライブして、それらを切り替えることもできますが、それはあまりにも面倒です。さらに、自分で構築したノードもあります。その1つのノードのために新しい設定を作成するのは避けたいです。

Sub-Storeはこの問題をうまく解決してくれます。複数のサブスクリプションからノード情報を抽出し、正規表現やJSを使って整理し、最終的にすべてのノード情報を統合したサブスクリプションを出力します。

デプロイには、xreamがパッケージ化したイメージを使用できます。このイメージはフロントエンドとバックエンドを統合しています。公衆ネットワークにデプロイする場合は、バックエンドのパスを変更することを忘れないでください。そうしないと、設定ファイルが盗まれる可能性があります。

services:
  sub-store:
    image: xream/sub-store
    container_name: substore
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path
    ports:
      - "3001:3001"
    volumes:
      - ./data:/opt/app/data

3001ポートをリバースプロキシしてSubstoreのフロントエンドにアクセスできます。ここではCaddyを例にします：

sub-domain.example.com {
        reverse_proxy :3001
}

もちろん、初めてフロントエンドにアクセスするときは、バックエンドのアドレスを追加することを忘れないでください。この時のバックエンドアドレスは、以前のcomposeファイルの設定に依存します。この記事の例では、バックエンドアドレスはhttps://sub-domain.example.com/super-random-pathです。

サブスクリプションの管理

すべてのVPNサービスと自建ノードを追加した後、それらを1つのサブスクリプションにまとめることができます。しかし、各VPNサービスのノード名は様々で、デフォルトでは非常に乱雑に見えます。さらに、異なるVPNサービス間でノード名が重複する可能性もあります。幸い、Sub-Storeにはスクリプトを使用してノードを一括でリネームする機能があります。ここではこのスクリプトをお勧めします。これを使用すると、すべてのVPNサービスのノードをリネームできます。

このスクリプトを使用するには、サブスクリプションを編集する際に以下のアドレスをスクリプト操作欄に貼り付けるだけです。

https://raw.githubusercontent.com/Keywos/rule/main/rename.js

最後に、好きなノード操作を行い、統一されたノードリストを作成できます。

Clash設定の生成

現在、ノードリストはありますが、生成された設定ファイルにはルールが含まれていません。自分でルールを書くか、サードパーティのルールを取得する必要があります。

Substoreのファイル管理に移動し、新しいMihomo設定を作成します：

「ソース」でサブスクリプションを選択し、サブスクリプション名でサブスクリプショングループを選択します
スクリプト操作に自分のオーバーライド設定を入力します

ここでは、私自身のオーバーライドルール powerfullz/override-rulesをお勧めします。これは mihomo-party-org/override-hubからフォークしたもので、元のリポジトリ内のACL4SSRルールに対して以下の改善を行っています：

SukkaW/Surgeルールセットを統合し、広告ブロック、プライバシー保護、トラフィック分流の精度を最適化
Truth Social、E-Hentai、TikTok、暗号通貨などの実用的な分流ルールを追加
冗長なルールセットを削除
DNS、Sniffer設定を内蔵
Loyalsoldier/v2ray-rules-datの完全版GeoSite/GeoIPデータベースを導入
IPルールに対してno-resolveパラメータを追加し、ローカルDNS解決を回避し、インターネット速度を向上させ、DNS漏洩を防ぐ

新しいスクリプト操作を作成し、ルールのRawリンクhttps://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/override.yamlを貼り付けます。

保存が成功したら、共有ボタンをクリックして共有リンクを生成します。共有の有効期限を設定し、「共有を作成」をクリックします。生成されたリンクが最終的なMihomo設定ファイルです。これをサブスクリプションリンクとしてプロキシソフトウェアにサブスクライブすれば完了です。

大統領になるには最悪の男

Mon, 03 Mar 2025 22:44:08 +0800

最近、ホワイトハウスで起こった騒動は、皆さんもご存知でしょう。数百年にわたって安定して運営されてきた政治制度が、今やトランプ、ヴァンス、マスクという三人のならず者を迎え入れ、その道徳の腐敗、行為の卑劣さ、手段の下劣さは、アメリカ史だけでなく世界史においても前代未聞です。わずか三週間の間に、アメリカが数百年かけて築き上げてきた信頼、地位、権力は、「三人組」によってトイレに流され、世界中が本当にアメリカの笑いものを見ることになりました。

トランプの正体

トランプは嘘、腐敗、自己中心の達人であり、有罪判決を受けた重罪犯です。彼が大統領選挙に出馬したのは、ほとんど刑務所行きを避けるためであり、今や再び大統領の座に就いても、彼の犯罪者としての本性は変わっていません——彼は国会暴力事件の犯罪者を赦免し、記者会見では嘘ばかりをつき、外交の場では他国の元首を公然と侮辱し、マスクが政府の機密データにアクセスするのを放任し、民生支出を大幅に削減し、アメリカ産業を保護するという名目で他国の商品に関税をかけ、実際には貧しい人々に増税し、富裕層に減税しています。

彼はアメリカの利益を気にかけず、現存する国際秩序やアメリカの国際的な信頼と地位を犠牲にしてでも、彼のいわゆる「友人」の面子を守ろうとします。おそらくこれは独裁者同士の以心伝心、臭いもの同士が引き寄せ合うということなのでしょう。彼はファシスト独裁者として統治することを計画しており、今回はその目標を達成するのに十分な支持を得ています。彼自身がメディアの前で煙幕を張り、マスク率いるDOGEとヴァンスが議会を迂回して政府部門と最高裁判所を混乱させるのを援護しています。彼らはDEIに反対することを隠れ蓑にし、実際には体系的な抑圧メカニズムを構築しています。まず文化戦争の煙幕を張り、市民社会が反応する間もなく、公民権を弱体化させ、大統領権力を強化し、最終的にはすべての政治的敵対者を根本的に抑圧し、アメリカ国民の利益を犠牲にして、マスクのような商業寡頭や億万長者のエリート白人グループの既得権益を守ろうとしています。

トランプやマスクらを代表とするMAGA運動の影響により、アメリカ社会はさらに右傾化し、影響を受ける可能性があります。この傾向は、より保守的な議題への道を開き、教育、移民、労働政策などの分野に深い影響を与えるかもしれません。同時に、この政治的雰囲気は、科学的人種主義、性差別、優生学思想が主流政治の中でより大きな空間を獲得し、アメリカの立憲民主主義の基盤を弱体化させる可能性があります。そして、「内部の敵」と見なされるグループ——「従順な白人異性愛男性」ではないすべての人々——彼らを待ち受けているのは、ナチスの強制収容所送り、国外追放、投獄、ターゲットを絞った噂や死の脅威です。

時には本当に感嘆せざるを得ない

I can’t believe that the American people are dumb enough to re-elect this man into power.

私の家庭ネットワークのドメイン名解決ソリューション

Thu, 06 Feb 2025 17:01:51 +0800

中国にいると、DNSを使う際に2つの問題に直面します。一つはDNS汚染、もう一つはDNSリークです。快適にインターネットを利用するには、まずDNSの問題を解決する必要があります。

DNSリークとは何か

もし今、代理を使ってこの記事を読んでいるなら、まずこのサイトを開いて、自分のDNSリクエストが国内のDNSサーバーに送信されていないか確認してください。

簡単に言うと、VPNなどの代理ツールを使用しているとき、自分のリクエストがVPNプロバイダー以外の第三者に見られないと思いますが、ホストのDNSリクエストがオペレーターのDNSサーバーや公共DNSサーバー（アリババ、テンセントなど）に送信されて解決され、あなたの実際のIPアドレスとリクエストしたドメイン名が記録されます。もしDNSリクエストが電報、ウィキリークスなどの敏感なサイトのドメイン名を解決すると、監視者に注意され、警告を受けたり、尋問されたりする可能性があります。¹

したがって、DNSリークを防ぐために代理ツールの分流戦略を正しく設定することが非常に重要です。

SmartDNSの設定

DNSリークを防ぐ

DNSはインターネットの道案内役として、最も重要な要件は速さです。この要件を満たすために、家庭ネットワークのDNSサーバーとしてSmartDNSをローカルに導入するのは非常に適しています。SmartDNSの役割と設定のコツ、CDNを最適化してネットワークアクセス速度を向上させる方法については、Sukkaの「私の特別なDNS設定と使用のコツ」で詳しく説明されています。この記事を読む前に、まずその記事を読むことをお勧めします。ここではその内容を繰り返さず、Luciインターフェースでこれらの設定を実現する方法に焦点を当てます。

もしあなたが私と同じようにOpenWRTを使用している場合、SmartDNSのLuci Appは起動するたびにパネルに保存された設定に基づいて新しい設定ファイルを自動生成します。したがって、/etc/smartdnsディレクトリ内の既存の設定ファイルを直接変更せず、すべての変更はLuci App内で行うべきです。

基本的に、SmartDNSの上流は多ければ多いほど良いです。多くの上流はSmartDNSの性能に影響を与えません²し、冗長性を高めることができます。DNSリークを防ぐために、上流を設定する際は、デフォルトグループに外国のDNS上流（もちろん、暗号化されたDNSが望ましい）を追加し、国内のサーバーをdomesticのような独立したグループに分類し、-exclude-default-groupの追加パラメータを付けてデフォルトグループから除外します。

国内ドメイン名解決の加速

外国の上流を設定すると、DNSリークの問題は解決しますが、デフォルトグループから国内上流を除外したため、新しいドメインにアクセスする際に外国の上流からの結果を待つ必要があり、国内サイトのアクセス速度が遅くなり、CDNが劣化します。

dnsmasq-china-listはFelix Yanのプロジェクトで、現在SmartDNS形式の設定ファイルをMakefileを通じて生成することをサポートしています。すでに誰かがGitHub Actionを使って毎日自動更新しており、直接ダウンロードするだけで利用できます。これらの設定ファイルは、国内DNS上流グループ名がdomesticのときにのみ有効です。

cd /etc/smartdns
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

その後、SmartDNSでこれらの設定ファイルをインポートし、「カスタム設定」欄の末尾に以下の内容を貼り付けます。

conf-file /etc/smartdns/accelerated-domains.china.domain.smartdns.conf
conf-file /etc/smartdns/apple.china.domain.smartdns.conf
conf-file /etc/smartdns/chinalist.domain.smartdns.conf
conf-file /etc/smartdns/google.china.domain.smartdns.conf

このように設定すると、国内ドメインのアクセス速度は影響を受けず、国外ドメインにアクセスする際もDNSリークの問題は発生しません。

広告ブロック

DNSレベルでの広告ブロックの効果は限定的で、誤ブロックを防ぐことに重点を置くべきです。悪名高い³「中国語圏で最も命中率の高い広告フィルタリスト」を謳うAnti ADは使用せず、他のルールを使用します。個人的に使用しているルールは217heidai/adblockfiltersで、整理された統合ルールです。直接取得して使用できます。

wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf

最後に設定ファイルをインポートします：

conf-file /etc/smartdns/adblock.conf

ルールの自動更新

以下のCrontabを設定することで、毎日午前3時にすべてのルールを自動更新できます。

0 0 3 * * ?  wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/accelerated-domains.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/apple.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/chinalist.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/google.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

バイパスルーターは使えますか

IPv6を使用しない限り、OpenWRTルーターをメインルーターとして使用する方が良いです。バイパスルーターとして使用する場合、特定のシステム（Windowsのことです）はバイパスルーターがブロードキャストするIPv4 DNSに従わず、オペレーターの光モデムがブロードキャストするIPv6 DNSを使用して解決しようとします。関連するレジストリキーを変更しようとしましたが、効果はありませんでした。仕方なく、オペレーターに来てもらい、光モデムをブリッジモードに変更し、OpenWRTをメインルーターとして使用しました。

Clashルールの上書き

この時点でClashを起動してDNSリークテストを実行すると、おそらく中国のDNSサーバーにDNSリクエストが送信されているのが見えるでしょう。ほとんどのプロバイダーのデフォルト設定は、テンセントやアリババなどの国内大手の暗号化DNSを使用しています。オペレーターのDNSに明示的にリークして詐欺防止センターから電話がかかってくることはないにしても、気になります（強迫症が発動します）。さらに、関連する設定が全くない場合もあります。

幸い、Clash Verge Revを使用している場合は、プロバイダーの設定を容易に上書きできます。ここで私の上書き設定を共有します。これを全体的な拡張設定に貼り付けるだけで、プロバイダーの設定を上書きできます。

dns:
  enable: true
  ipv6: false
  prefer-h3: true
  use-system-hosts: true
  nameserver:
    - "https://dns.cloudflare.com/dns-query"
    - "https://dns.sb/dns-query"
    - "https://dns.google/dns-query"
    - "https://public.dns.iij.jp/dns-query"
    - "https://jp.tiar.app/dns-query"
    - "https://jp.tiarap.org/dns-query"
  nameserver-policy:
    "geosite:cn":
      - system
  fallback:
    - "tls://8.8.4.4"
    - "tls://1.1.1.1"
  proxy-server-nameserver:
    - "https://doh.pub/dns-query"
    - "https://223.5.5.5/dns-query"
  direct-nameserver:
    - system

設定の解析

Mihomoのドキュメント⁴によれば、DNSリクエストの流れは次のようになっています。

flowchart TD
  Start[クライアントがリクエストを開始] --> rule[ルールのマッチング]
  rule -->  Domain[ドメインベースのルールにマッチ]
  rule --> IP[IPベースのルールにマッチ]

  Domain --> |ドメインが直結ルールにマッチ|DNS
  IP --> DNS[Clash DNSでドメインを解決]

  Domain --> |ドメインが代理ルールにマッチ|Remote[代理サーバーでドメインを解決し、接続を確立]

  Cache --> |Redir-host/FakeIP-Directがヒットしない|NS[名前サーバーポリシーにマッチし、クエリ]
  Cache --> |キャッシュヒット|Get
  Cache --> |FakeIPがヒットしない、代理ドメイン|Remote

  NS --> |マッチ成功| Get[取得したIPでIPルールにマッチ]
  NS --> |マッチしない| NF[名前サーバー/フォールバックで同時にクエリ]

  NF --> Get[取得したIP]
  Get --> |DNS結果をキャッシュ|Cache[(キャッシュ)]
  Get --> S[IPで直結/代理接続を確立]

  DNS --> Redir-host/FakeIP
  Redir-host/FakeIP --> |DNSキャッシュをクエリ|Cache

nameserver-policyはnameserverとfallbackよりも優先され、geosite:cnにあるサイトをシステムDNSで解決するよう指定されており、以前設定したSmartDNSを使用して、ローカルネットワークレベルの応答速度と内蔵の速度測定によるCDN選択を享受できます。一方、geosite:cnにないサイトはnameserver/fallbackで解決され、外国の暗号化された上流を使用して結果の信頼性を確保し、DNSリークを防ぎます。

geoipとgeositeデータベースの置き換え

MihomoはデフォルトでV2Ray公式のgeoipとgeositeデータベースを使用していますが、このデータベースはあまり充実しておらず、更新頻度も遅いです。そこで私はLoyalsoldier/v2ray-rules-datという「強化版」データベースで元のデータベースを置き換えました。geoip.datとgeosite.datをダウンロードしてカーネルディレクトリに置くだけです。当然、数行の上書き設定を追加して自動/ワンクリックで更新することもできます。

geodata-mode: true
geox-url:
  geoip: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
  geosite: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"

Clash Meta For Android

スマートフォン上でのClash Meta For Android（以下Clash）については、上書き設定を行う際にスマートフォンの実際の状況をより考慮する必要があります。

まず、スマートフォン上のClashの上書き設定オプションはデスクトップ版のClash Verge Revほど柔軟ではなく、多くのキーが上書きできません。また、スマートフォンはコンピューターとは異なり、ネットワーク環境を頻繁に切り替える必要があるため、システムDNSも頻繁に変わります。このような場合、ネットワーク環境を変更するたびにClashをオンオフする必要があり、systemが表すDNSを更新する必要があります。したがって、国内の暗号化されたDNSを国内クエリとして固定するのが最善です。

Clashに入り、「設定」->「上書き」以下はすべての上書き設定です：

「DNS」->「ポリシー」：強制的に有効化
「DNS」->「Prefer h3」：有効化済み
「DNS」->「Name Server」：2つの国外暗号化DNSを追加
「DNS」->「Name Serverポリシー」：「キー」欄にgeosite:cnを入力し、「値」欄にhttps://doh.pub/dns-queryを入力

事前にGitHubからgeoip.datとgeosite.datをダウンロードし、最後にClash ->「設定」->「Meta Features」に入り、「GeoIPデータベースをインポート」と「GeoSiteデータベースをインポート」機能を使用してそれらをインポートします。

完成

最後にもう一度DNSリークテストを実行して、すべてが正しく設定されていることを確認してください。これで、家庭ネットワークのDNS設定が最適化され、より高速で安全なインターネット体験を楽しむことができます。

参考: https://blog.lololowe.com/posts/8f1e/ ↩︎
SmartDNSは設計時に遅延問題を考慮しており、具体的なメカニズムについては「中場休息：SmartDNSは速度測定によるDNS解決の遅延をどのように回避するか」。 ↩︎
Anti ADの光栄な事績をまとめた人がいます。 ↩︎
引用: https://wiki.metacubex.one/config/dns/diagram/ ↩︎

乱筆