网络 on Sisy's Blog

从零开始接入 DN42 网络 - 4: 实现网络信息公网展示面板

Fri, 01 May 2026 00:00:00 +0000

前言

整个初始的灵感来源是

一般很多大网 DN42 玩家或者自己喜欢玩儿的都会有一个公共的 Web 面板来展示自己的网络信息，包括 AS、地址段、节点信息、互联政策等
MoonWX 纯 vibe 出来的面板还是很不错的，我基本就是希望拿 Vue 将其完整实现，添加几个他没有的功能，并稍做优化
Kioubit 的面板也给了我很大启发，尤其是我希望能像他一样能够提供一个批量 Ping 的服务，从而让用户能快速判断连接哪个节点最优。
先做个大概吧，离 Kioubit 那种功能完善的面板还差远了
后续可能还会有 Looking Glass 之类的功能？再说吧

写完的面板在 https://dn42.sisy.cc，开源在 https://github.com/SisypheOvO/SISY-DN42-Website，欢迎访问。

技术选型

Vue3.5 (Setup) + Vite 8 + TypeScript 6.0 + TailwindCSS v4 + vue-i18n + Docker Compose + Nginx + Github Actions

起初的设计里是没有容器的，但是本地 dev 写完之后还是加上了，所以也多了个容器内 Nginx 配置。

一开始是真没想到，但推了一两个 commit，每次都要自己在服务器上拉下来执行部署操作，之后觉得实在是有点多余，就想到用 Github Actions 来实现 CI/CD，实现提交之后自动触发我自己服务器上的拉取、构建、起 Compose 的流程，从而实现自动部署。这个也算是自动化运维思维的小进步吧…

功能实现中的问题与解决

起手肯定还是小修小改，问题都不大，一些简单的数据层提取，项目架构分层，组件化，国际化等等，捣鼓捣鼓就行，无非是时间。

vue-i18n 解析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


export default {
 policy: {
 title: "Peering Policy",
 intro: "We have an open peering policy. Please contact us to peer.",
 advertiseLabel: "We advertise the following prefixes:",
 disclaimer: "This network is experimental and educational, no SLA guaranteed. We will make our best efforts to maintain operation, but we are not responsible for any consequences caused by shutdown due to force majeure or personal financial reasons.",
 items: [
 "Only WireGuard tunnels are supported",
 "Connection may be terminated after long downtime",
 "MP-BGP + Extended Next Hop + IPv6 LLA is preferred",
 "Default port: 20000 + the last 4 digits of your ASN",
 "IPv4 / IPv6 single-stack endpoints are supported (use the 4. or 6. prefix)",
 ],
 },
}

在实现国际化的过程中，遇到了 vue-i18n 的一个问题。正常来说 Vue 模板部分里调用 vue-i18n 的 t 函数就行，例如以上这个 i18n 配置里的 policy 的对象，那么在模板里直接写

1

<span>{{ $t("policy.title") }}</span>

即可直接拿到 title 的翻译内容。这是因为 policy.title 是一个字符串。但是如果你要用 v-for 来循环一个数组，例如

1
2
3


<div v-for="item in $t('policy.items')" :key="item">
 <span>{{ $t(item) }}</span>
</div>

就会发现拿到的 item 的值是 undefined。这是因为 policy.items 是一个数组，t 函数默认只能解析字符串，无法直接解析数组。如果想用 t 函数来访问数组结构，需要通过索引来访问每一项：

1
2


t('policy.items[0]') // "Only WireGuard tunnels are supported"
t('policy.items[1]') // "Connection may be terminated after long downtime"

所以在这个 v-for 的使用场景下就不能用 t 函数。如果想在模板里遍历渲染，常见的做法有两种：

用 tm() 获取原始消息

用 tm() + rt() 来处理数组和复杂结构。vue-i18n v9+ 提供了 tm()（translation message），可以返回原始结构而非翻译后的字符串：

1
2
3
4
5


<ul>
 <li v-for="(item, i) in tm('policy.items')" :key="i">
 {{ rt(item) }}
 </li>
</ul>

tm() 返回原始消息对象/数组，rt() 用来解析每一项为最终字符串。这也是官方推荐的方式。

改为对象结构（避免数组）

如果不依赖 tm/rt，就得把数组改成带编号键的对象，然后在代码里手动组装：

1
2
3
4
5
6
7
8


policy: {
 items: {
 0: "Only WireGuard tunnels are supported",
 1: "Connection may be terminated after long downtime",
 2: "MP-BGP + Extended Next Hop + IPv6 LLA is preferred",
 // ...
 }
}

那么出于优雅性考虑，obviously 应当选择第一种方式。

ScrollSpy 实现

目标是判断当前视窗中活跃的是哪个 section，从而高亮对应的导航链接，并且自动把 url 里的 hash 更新为当前 section 的 id。

基本思路就是监控目前哪个 section 在视窗内且这个 section 的顶部的位置高于视口高度的 50%。

根据我搓完的经验，实现这个功能大致有两种方案，而造成有第二种方案的原因是如何处理底部的一个或几个 section：这些 section 可能很矮，在浏览器视口很高的情况下，它们的顶部位置可能永远都达不到视口高度的 50%，所以如果单纯地监控哪个 section 的顶部位置高于视口高度的 50%，就会导致最后一个或几个 section 永远无法被识别为活跃状态。

方案一：使用 IntersectionObserver API

注意这个方法很难解决底部 section 的问题，可能可以结合 scroll 事件来做一些特殊处理？反正我没搞定。

首先写一个名为 useScrollSpy 的 composable 来实现这个功能，核心就是用 IntersectionObserver 来监控每个 section 的可见性和位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


import { onMounted, onBeforeUnmount, ref } from "vue"

export default function useScrollSpy(options?: { offset?: number; rootMargin?: string }) {
 const current = ref<string | null>(null)
 let observer: IntersectionObserver | null = null

 function init(ids: string[]) {
 if (typeof window === "undefined" || !window.IntersectionObserver) return

 const offset = options?.offset ?? 0
 const rootMargin = options?.rootMargin ?? `-50% 0px -50% 0px`

 const elements = ids.map((id) => document.getElementById(id)).filter(Boolean) as HTMLElement[]
 if (!elements.length) return

 const cb: IntersectionObserverCallback = (entries) => {
 // choose the entry with largest intersection ratio
 const visible = entries.filter((e) => e.isIntersecting).sort((a, b) => b.intersectionRatio - a.intersectionRatio)[0]

 if (visible) {
 const id = visible.target.id
 if (id && id !== current.value) {
 current.value = id
 // update URL hash without scrolling
 try {
 const url = new URL(window.location.href)
 url.hash = `#${id}`
 history.replaceState(null, document.title, url.toString())
 } catch (e) {
 window.location.hash = id
 }
 }
 }
 }

 observer = new IntersectionObserver(cb, { root: null, rootMargin, threshold: [0, 0.25, 0.5, 0.75, 1] })
 elements.forEach((el) => observer?.observe(el))
 }

 function destroy() {
 observer?.disconnect()
 observer = null
 }

 onBeforeUnmount(() => destroy())

 return { current, init, destroy }
}

然后将其注入到App.vue中监视活跃元素，

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


<template>
 <div id="top" class="relative min-h-screen overflow-x-hidden text-[#f7f1e8]">
 <Background />
 <TopBar :active-section="spy.current.value" />

 <main class="mx-auto w-[min(1200px,calc(100%-2rem))] pb-4 md:w-[min(1200px,calc(100%-4rem))]">
 <Hero />
 <Policy />
 <Nodes :nodes="nodes" />
 <Contact />
 </main>

 <Footer />
 <CopyTooltip />
 </div>
</template>

<script setup lang="ts">
import Background from "@/components/Background.vue"
import Contact from "@/components/Contact.vue"
// import ... components
import TopBar from "@/components/TopBar.vue"
import { nodes } from "@/data"
import useScrollSpy from "@/composables/useScrollSpy"
import { onMounted } from "vue"

const spy = useScrollSpy()

onMounted(() => {
 // observe main sections to keep URL hash in sync
 spy.init(["policy", "nodes", "contact"])
})
</script>

方案二：纯粹监听 scroll 事件并特殊处理底部问题

把整个 useScrollSpy 的实现都改成使用以下监听 scroll 事件的方法来实现，App.vue 中的注册方式不变。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83


import { onBeforeUnmount, ref } from "vue"

export default function useScrollSpy() {
 const current = ref<string | null>(null)
 let elements: HTMLElement[] = []
 let lastId: string | null = null
 let ticking = false
 let onScroll: (() => void) | null = null

 function updateHash(id: string) {
 if (!id || id === current.value) return
 current.value = id
 try {
 const url = new URL(window.location.href)
 url.hash = `#${id}`
 history.replaceState(null, document.title, url.toString())
 } catch {
 window.location.hash = id
 }
 }

 function detect() {
 // touching the bottom of the page should activate the last section
 const atBottom = window.innerHeight + window.scrollY >= document.documentElement.scrollHeight - 2
 if (atBottom && lastId) {
 updateHash(lastId)
 return
 }

 // find the element whose top is closest to the center of the viewport but not below it
 const center = window.innerHeight / 2
 let closest: HTMLElement | null = null
 let minDist = Infinity

 for (const el of elements) {
 const rect = el.getBoundingClientRect()
 // only consider elements whose top is already in the viewport (top <= center)
 if (rect.top <= center) {
 const dist = center - rect.top
 if (dist < minDist) {
 minDist = dist
 closest = el
 }
 }
 }

 if (closest) updateHash(closest.id)
 }

 function init(ids: string[]) {
 if (typeof window === "undefined") return

 elements = ids.map((id) => document.getElementById(id)).filter(Boolean) as HTMLElement[]
 if (!elements.length) return

 lastId = ids[ids.length - 1]

 onScroll = () => {
 if (!ticking) {
 ticking = true
 requestAnimationFrame(() => {
 detect()
 ticking = false
 })
 }
 }

 window.addEventListener("scroll", onScroll, { passive: true })
 // detect in case the page is not scrolled to top when loaded
 detect()
 }

 function destroy() {
 if (onScroll) {
 window.removeEventListener("scroll", onScroll)
 onScroll = null
 }
 }

 onBeforeUnmount(() => destroy())

 return { current, init, destroy }
}

部署

配置与构建

Dockerfile、dockerignore、compose.yaml、容器内 Nginx.conf，宿主机 Nginx.conf，基本上你需要的就是这些了。

首先写个 Dockerfile 来构建这个 Vue 应用，分为 build 阶段和 runtime 阶段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


FROM node:22-alpine3.22 AS build
RUN apk update && apk upgrade --no-cache
WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginx:1.29-alpine AS runtime
RUN apk update && apk upgrade --no-cache
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/dist /usr/share/nginx/html

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

注意构建使用的镜像避免使用浮动标签，应该指定一个具体的版本号，例如 node:22-alpine3.22 和 nginx:1.29-alpine，以确保构建环境的一致性和可预测性。另外，在每个阶段使用

1

RUN apk update && apk upgrade --no-cache

来打上最新的 Alpine 安全补丁，以确保基础镜像中的包都是最新的，避免潜在的安全问题。基础镜像的发布时间点和 build 的时间点之间，Alpine 上游可能已经推送了修复包，apk upgrade 会将这些修复拉进来。

接下来写一个 compose.yaml 来定义服务：

1
2
3
4
5
6
7
8
9


services:
 web:
 build:
 context: .
 dockerfile: Dockerfile
 image: sisy-dn42-website:latest
 restart: unless-stopped
 ports:
 - "127.0.0.1:8080:80"

这个 compose 使用当前目录下的 Dockerfile 来构建镜像，并将容器的 80 端口映射到宿主机的 8080 端口上。这样一来，宿主机 Nginx 将 80/443 流量反代到 8080 上，容器内 Nginx 监听到容器的 80 端口传来流量，并做相应处理。

容器内的 Nginx 简单配置一下，宿主机的 Nginx 就不谈了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


server {
 listen 80;
 server_name _;

 root /usr/share/nginx/html;
 index index.html;

 location / {
 try_files $uri $uri/ /index.html;
 }

 location ~* \.(?:css|js|mjs|json|svg|png|jpg|jpeg|gif|ico|webp|woff|woff2|ttf|eot)$ {
 expires 30d;
 add_header Cache-Control "public, max-age=2592000, immutable";
 access_log off;
 }
}

部署问题

Dockerfile 中要求的 npm ci 需要 lockfile 文件，如果没有这个文件，构建会失败。另外，还需要特别确保项目根目录下的 lockfile 文件与 package.json 中的依赖版本一致。为此，本地可能需要把 package-lock.json 和 node_modules 彻底删除，重新使用 npm install 生成一次 lockfile。

解决该问题后，起 compose 应该就没问题了：

1

docker compose up -d --build

自动化部署

每次修改代码推送到 Github 上之后都要在服务器上 pull 并重启服务，感觉有点麻烦，所以就想用 Github Actions 来实现自动部署。

方案

使用 GitHub Actions 将服务部署到自己的远程主机主要有两种方式：

通过 SSH 部署到远程服务器

这是最常见的方式。在 workflow 中通过 SSH 连接到自己的服务器，执行部署命令。常用的第三方 Action 如 appleboy/ssh-action：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


- name: Deploy via SSH
 uses: appleboy/ssh-action@v1
 with:
 host: ${{ secrets.SERVER_HOST }}
 username: ${{ secrets.SERVER_USER }}
 key: ${{ secrets.SSH_PRIVATE_KEY }}
 script: |
 cd /path/to/your/app
 git pull
 docker compose up -d --build

使用 Self-hosted Runner

在自己的服务器上安装 GitHub Actions Runner，让 workflow 直接在服务器上执行，无需 SSH：

1
2
3
4
5
6


jobs:
 deploy:
 runs-on: self-hosted  # 指定使用自托管的 runner
 steps:
 - uses: actions/checkout@v4
 - run: docker compose up -d --build

相比之下 SSH 方案更简单易行，只需把 SSH 密钥存到 GitHub Secrets 即可，适合大多数用户，而 Self-hosted Runner 则提供了更高的安全性和灵活性，Runner 常驻在你的服务器上，不需要暴露 SSH 端口，适合需要访问内网资源或有更复杂 CI/CD 流程的场景，但需要额外的维护工作。

除此之外，还可以通过 rsync、scp 等方式传输构建产物到远程主机，或者利用 docker/build-push-action 推送镜像到私有仓库后再在远程主机上拉取。总之 GitHub Actions 在这方面非常灵活，基本上能在终端里做的事情，都可以在 workflow 中实现。

对比各种方案之下，还是 SSH 方案比较简易且优雅，下面写个 workflow 来实现这个方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


name: Deploy via SSH

on:
 push:
 branches: [ "main" ]
 workflow_dispatch: {}

jobs:
 deploy:
 name: Deploy to server via SSH
 runs-on: ubuntu-latest
 steps:
 - name: Checkout repository
 uses: actions/checkout@v6

 - name: Deploy via SSH
 uses: appleboy/ssh-action@v1
 with:
 host: ${{ secrets.SERVER_HOST }}
 username: ${{ secrets.SERVER_USER }}
 key: ${{ secrets.SSH_PRIVATE_KEY }}
 # optional ssh port
 port: ${{ secrets.SERVER_PORT }}
 script: |
 cd ${{ secrets.SERVER_DEPLOY_PATH }}
 git pull
 docker compose up -d --build

这个 workflow 会在每次 push 到 main 分支或者手动触发时执行，Github 的一台临时主机将通过 SSH 连接到服务器，进入指定目录，拉取最新代码，并重建并启动 Docker Compose 服务。

然而最终发现此方案需要调整很多东西，不像表面看上去那么简单，只需要几个 Github Secrets 就能搞定。

你可能会遇到的问题

设计上，首先考虑到安全问题，不应该使用 root 用户来操作，所以你需要一个配置好权限的 deployer 用户：

1
2


adduser deployer
chown -R deployer:deployer /path/to/your/app # 确保 deployer 用户对部署目录的所有子目录和子内容有读写权限

其次你需要注意仓库的的父目录不能处于 /root/ 等 deployer 用户无法访问的目录下，否则即使内部目录权限正确，也无法进入它。

否则你会在 CI 中遇到报错：

1
2
3


sh: 1: cd: can't cd to ***
fatal: not a git repository (or any of the parent directories): .git
no configuration file provided: not found

此外，在 appleboy/ssh-action 的 script 中，~ 可能不会被正确解析。你必须使用绝对路径来指定部署目录，例如 /home/deployer/app，而不能使用 ~/app。
你传入 Github Secrets 的 SSH 私钥必须是属于 deployer 用户的，而不是 root 用户的，且公钥应被添加到其 ~/.ssh/authorized_keys 文件中，否则 CI 无法正确连接到 deployer 用户。

1
2
3
4
5
6


# 以 deployer 身份生成 SSH key
su - deployer -c "ssh-keygen -t ed25519 -C 'deployer' -f /home/deployer/.ssh/id_ed25519 -N ''"
cat /home/deployer/.ssh/id_ed25519.pub
cat /home/deployer/.ssh/id_ed25519
# 验证能否正常 pull
su - deployer -c "cd /home/deployer/app && git pull"

否则你会在 CI 中遇到报错：

1
2
3
4


Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

如果你的项目是用 root 用户 git clone 下来并移动过来的，那么你可能还需要为 deployer 用户设置 git 的 safe.directory 配置

1
2
3
4
5
6
7
8


# 以 deployer 身份写入 known_hosts
su - deployer -c "ssh-keyscan github.com >> ~/.ssh/known_hosts"

# 解决 git safe.directory 问题（为 deployer 用户配置）
su - deployer -c "git config --global --add safe.directory /home/deployer/SISY-DN42-Website"

# 检查 git remote
su - deployer -c "cd /home/deployer/SISY-DN42-Website && git remote -v"

否则在执行 git pull 时会遇到以下错误：

1
2
3


fatal: detected dubious ownership in repository at '/home/deployer/app'
To add an exception for this directory, call:
 git config --global --add safe.directory /home/deployer/app

docker compose up -d --build 需要 deployer 用户有权限执行 Docker 命令。这意味着 deployer 用户需要被添加到 docker 组中：

1
2
3


usermod -aG docker deployer
su - deployer # 或者重新登录 deployer 用户会话以使组权限生效
docker ps # 确认 deployer 用户现在有权限执行 Docker 命令

否则你会在 CI 中遇到报错：

1

unable to get image 'sisy-dn42-website:latest': permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

结语

这样一来整个面板的开发和部署流程就都走了一遍了，后续可能还会继续完善一些功能。over!

从零开始接入 DN42 网络 - 3: Dummy 网卡创建与保持、ROA 配置

Thu, 23 Apr 2026 00:00:00 +0000

2026-05-01 更新：配置在 dummy 网卡上的 IP 段 v4:/27 和 v6:/48 分别改为 /32 和 /128 这包括 /etc/netplan/60-dn42-dummy.yaml 中的配置，以及文中示例命令 ip addr add dev dn42-dummy <路由器IP>/<子网> 中的 <子网> 部分。如果需要配置内网，这里不应该填自己分配到的整个 IP 段，否则会导致后续配置内网 IGP 时出现问题：例如对于 IPv4，如果给网卡配置 fd24:ac8e:9e04::3/48，内网的两个节点都会通过 direct protocol 产生同一条 /48 的路由，内核会把去往 ::2 的包直接丢给 dummy 接口（本地连接路由），而不是走隧道。改为 fd24:ac8e:9e04::3/128 后，direct protocol 产生的是主机路由，每个节点通过 Babel/OSPF 等协议，只通告自己的 loopback 地址，对端就能学到一条指向隧道的具体路由。

前言

在前两篇文章里我们已经完成了 DN42 网络的注册和 Bird2 的基础配置，接下来首先必须创建一个 dummy 网卡来承载 BGP 协议的 IP 地址，之后还要配置 ROA 来让 Bird 能够正确地验证路由的合法性。

Dummy 网卡创建与保持

DN42 网络中 BGP 协议的 IP 地址是不会绑定在物理网卡上的，而是绑定在一个 dummy 网卡上，它作为虚拟的网络接口来承载这些 IP 地址，而 Bird 会监听这个接口来进行 BGP 通信。

创建 dummy 接口：

1
2


ip link add dn42-dummy type dummy
ip link set dev dn42-dummy up

为其分配此路由器的 IP 地址（对 ipv4 和 ipv6 都要执行一次）：

1

ip addr add dev dn42-dummy <路由器IP>/<子网>

需要注意这里的 IP 指的是 DN42 网络中选定的 IP 地址，而不是主机的真实公网 IP。

然而这些命令是临时生效的，重启后会丢失。如果需要维持这个 dummy 网卡的配置在重启后不变，可以把这些命令写入系统的网络配置中，例如我的 Ubuntu 24.04 默认使用 Netplan 管理网络，可以创建一个新的 Netplan 配置文件 /etc/netplan/60-dn42-dummy.yaml 来定义这个 dummy 网卡：（注意这里提到的两个地址段应当调整）

1
2
3
4
5
6
7


network:
 version: 2
 dummy-devices:
 dn42-dummy:
 addresses:
 - 172.23.15.34/27
 - fd24:ac8e:9e04::2/48

保存后执行

1
2


chmod 600 /etc/netplan/60-dn42-dummy.yaml
netplan apply

来设置安全的权限并应用配置。如果不设置 600 权限，可能会在 apply 时遇到以下 warning：

1

** (generate:924409): WARNING **: 03:49:04.343: Permissions for /etc/netplan/60-dn42-dummy.yaml are too open. Netplan configuration should NOT be accessible by others.

ROA 配置

ROA 表一般是由社区维护的一个公共资源，包含了 DN42 网络中所有合法的路由前缀和它们对应的 ASN 信息。

可以直接从注册中心生成，也可以用下面这些预构建的 BIRD ROA 表，我用的是 burble 源里列出的最后两个表：

由 dn42regsrv 生成的 ROA 文件可从 burble.dn42 获取：

URL	IPv4/IPv6	说明
https://dn42.burble.com/roa/dn42_roa_46.json	两者皆有	用于 RPKI 的 JSON 格式
https://dn42.burble.com/roa/dn42_roa_bird1_46.conf	两者皆有	Bird1 格式
https://dn42.burble.com/roa/dn42_roa_bird1_4.conf	仅 IPv4	Bird1 格式
https://dn42.burble.com/roa/dn42_roa_bird1_6.conf	仅 IPv6	Bird1 格式
https://dn42.burble.com/roa/dn42_roa_bird2_46.conf	两者皆有	Bird2 格式
https://dn42.burble.com/roa/dn42_roa_bird2_4.conf	仅 IPv4	Bird2 格式
https://dn42.burble.com/roa/dn42_roa_bird2_6.conf	仅 IPv6	Bird2 格式

由 roa_wizard 生成的 ROA 文件可从 kioubit.dn42 获取：

URL	IPv4/IPv6	说明
https://kioubit-roa.dn42.dev/?type=v4	仅 IPv4	Bird2 格式
https://kioubit-roa.dn42.dev/?type=v6	仅 IPv6	Bird2 格式
https://kioubit-roa.dn42.dev/?type=json	两者皆有	用于 RPKI 的 JSON 格式

为了即时生效，并且能定时更新到最新的 ROA 表，我们分两步走：

先简单地手动下载最新的 ROA 表到本地，并放到 Bird 的配置目录下，以便直接跑通 Bird 服务。

1
2


wget -4 -O /tmp/roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird2_4.conf && mv -f /tmp/roa_dn42.conf /etc/bird/roa_dn42.conf
wget -4 -O /tmp/roa_dn42_v6.conf https://dn42.burble.com/roa/dn42_roa_bird2_6.conf && mv -f /tmp/roa_dn42_v6.conf /etc/bird/roa_dn42_v6.conf

使用 cron 或者 systemd timer 定时执行一个脚本来定期更新 ROA 表，这里我还是用 cron。

1

0 * * * * wget -4 -O /tmp/roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird2_4.conf && mv -f /tmp/roa_dn42.conf /etc/bird/roa_dn42.conf && wget -4 -O /tmp/roa_dn42_v6.conf https://dn42.burble.com/roa/dn42_roa_bird2_6.conf && mv -f /tmp/roa_dn42_v6.conf /etc/bird/roa_dn42_v6.conf && birdc c

这个 cron job 每小时执行一次，下载最新的 ROA 表并替换掉旧的文件，最后执行 birdc c 来让 Bird 重新加载配置，使新的 ROA 表生效。

现在 ROA 配置好了，Bird 就能够正确地运行了，下一步就可以直接开始添加 Peer 了。运行一下 birdc c 来跑通 Bird 服务，输出应该类似于：

1
2
3


BIRD 2.18.1 ready.
Reading configuration from /etc/bird/bird.conf
Reconfigured

从零开始接入 DN42 网络 - 2: DN42 的 Bird2 配置

Wed, 22 Apr 2026 00:00:00 +0000

前言

在 dn42-registry 仓库里把身份注册了之后，除去搭建 VPN 隧道外，下一步就是配置 BGP 路由守护进程了。DN42 网络中我还是习惯用 Bird2 作为 BGP 来管理路由。

Bird2 的配置文件相对来说比较复杂，包含了全局设置、协议定义、路由过滤等多个部分。而且 DN42 自己的 wiki 没有做 i18n，这个等以后熟悉社区了跟维护者沟通吧。

时隔一个月，借这篇博客详细解释、记录一下 wiki 里提供的标准配置示例各部分的意思。整体思路就是先把大的 bird.conf 文件搭建好。这里面会依赖外部引入的 ROA 表和对等方配置，ROA 表是起 Bird 服务所必须的；对等方配置可以依赖 bird.conf 中定义的模板来简化配置，后续添加新的对等方时只需要写一个小的配置文件就行了。后续流程还包括创建一个 dummy 网卡，再往后还有 BGP Community 配置、RPKI 配置和开启 BFD 之类的。

Bird2 配置详解

官方文章：Bird2

全局变量定义

1
2
3
4
5
6
7


define OWNAS = <OWNAS>;
define OWNIP = <OWNIP>;
define OWNIPv6 = <OWNIPv6>;
define OWNNET = <OWNNET>;
define OWNNETv6 = <OWNNETv6>;
define OWNNETSET = [<OWNNET>+];
define OWNNETSETv6 = [<OWNNETv6>+];

这一段用 define 定义了一些 ASN、IP 段相关的全局变量，方便后面多次复用，写过代码的话应该都懂。OWNNETSET 和 OWNNETSETv6 是前缀集合（prefix set），加了 + 表示匹配该前缀及其所有更长的子前缀。

之所以要同时定义 OWNNET 和 OWNNETSET 两个变量，是因为 Bird 在某些语法场景下（比如 route ... reject）需要单个前缀，而在过滤器中做匹配（net ~）时需要集合，Bird 的变量解析机制不允许在集合字面量中直接内嵌变量。

基础设置

1
2
3
4
5


router id OWNIP;

protocol device {
 scan time 10;
}

router id 用这台主机的 IPv4 地址全局变量作为路由器的全局标识符，BGP 要求每个路由器有唯一 ID。

protocol device 让 Bird 每 10 秒扫描一次系统网络接口的状态变化（如接口 up/down、地址增删）。

工具函数

1
2
3
4
5
6


function is_self_net() -> bool {
 return net ~ OWNNETSET;
}
function is_self_net_v6() -> bool {
 return net ~ OWNNETSETv6;
}

意思基本显然且平凡，即判断当前路由的前缀是否属于本 AS 自己的网段，下文中的过滤器 filter 中会用来避免从外部邻居那里接受自己的前缀，以防止路由环路。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


function is_valid_network() -> bool {
 return net ~ [
 172.20.0.0/14{21,29},
 172.20.0.0/24{28,32},
 ...
 10.0.0.0/8{15,24}
 172.20.0.0/14{21,29}, # dn42
 172.20.0.0/24{28,32}, # dn42 Anycast
 172.21.0.0/24{28,32}, # dn42 Anycast
 172.22.0.0/24{28,32}, # dn42 Anycast
 172.23.0.0/24{28,32}, # dn42 Anycast
 172.31.0.0/16+, # ChaosVPN
 10.100.0.0/14+, # ChaosVPN
 10.127.0.0/16+, # neonetwork
 10.0.0.0/8{15,24} # Freifunk.net
 ];
}

...

function is_valid_network_v6() -> bool {
 return net ~ [
 fd00::/8{44,64} # ULA address space as per RFC 4193
 ];
}

一个白名单过滤器，定义了 dn42 生态中所有合法的 IPv4 地址范围。{21,29} 的语法表示前缀长度必须在 21 到 29 之间。不在此范围内的路由一律拒绝，==防止对等方泄漏公网路由或其他无关路由进来==。各段分别对应注释中的不同网络。除了官方分配的地址段之外，还有一些社区网络（如 ChaosVPN、neonetwork、Freifunk.net）也在 dn42 中使用了自己的地址段。

IPv6 版本类似，只接受 fd00::/8{44,64}，即 RFC 4193 定义的 ULA（唯一本地地址）空间。

ROA 表（路由源授权）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


roa4 table dn42_roa;
roa6 table dn42_roa_v6;

protocol static {
 roa4 { table dn42_roa; };
 include "/etc/bird/roa_dn42.conf";
};

protocol static {
 roa6 { table dn42_roa_v6; };
 include "/etc/bird/roa_dn42_v6.conf";
};

声明了两张 ROA 表（IPv4 和 IPv6），并通过 include 从外部文件加载 ROA 数据。

ROA 数据的本质是"哪个 ASN 被授权通告哪个前缀"的映射关系。下文中的 BGP 过滤器会用 roa_check() 查询这张表来验证路由的合法性。

Kernel 协议（Bird <-> 系统内核）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


protocol kernel {
 scan time 20;
 ipv4 {
 import none;
 export filter {
 if source = RTS_STATIC then reject;
 krt_prefsrc = OWNIP;
 accept;
 };
 };
}

控制 Bird 与 Linux 内核路由表之间的同步：

import none：不从内核路由表导入任何路由到 Bird,从而限制 Bird 仅通过 BGP 学习路由）。
export filter：将 Bird 学到的路由写入内核，但排除静态路由（RTS_STATIC），因为静态路由只是占位用的（见下文），不需要写入内核。
krt_prefsrc = OWNIP：设置导出到内核的路由的首选源地址，确保主机（即该路由器）向 dn42 发出的数据包使用自己的 dn42 IP 作为源地址，而不是随机选一个。

IPv6 同理。

静态路由（前缀通告的来源）

1
2
3
4
5
6
7
8


protocol static {
 route OWNNET reject;

 ipv4 {
 import all;
 export none;
 };
}

声明一条 reject 类型的静态路由，目的不是为了真正路由流量，而是让 Bird 内部有一条自己网段的路由记录。

BGP 的 export filter 中检查 source ~ [RTS_STATIC, RTS_BGP]，这条静态路由满足 RTS_STATIC 条件，从而被通告给邻居——也就是告诉整个 dn42：“我拥有这个前缀，请把目的地是这个前缀的流量发给我。” reject 类型意味着如果真有流量到达但没有更具体的路由可匹配，就丢弃（黑洞路由），这是正常行为。

ipv6 同理。

BGP 模板 (Core part)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


template bgp dnpeers {
 local as OWNAS;
 path metric on;

 ipv4 {
 <import filter part>
 <export filter part>
 };

 ipv6 {
 <import filter part>
 <export filter part>
 };
}

template 定义了一个可复用的 BGP 配置模板，所有 dn42 对等方都继承它，避免重复配置。path metric on 表示 AS 路径中每一跳的代价为 1，Bird 会优选 AS path 最短的路由。

以下是 import/export filter 的具体内容，ipv4 和 ipv6 的过滤器内容相同，分别放在对应的 ipv4 和 ipv6 块中。

Import Filter（入站过滤）

1
2
3
4
5
6
7
8
9


import filter {
 if is_valid_network() && !is_self_net() then {
 if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {
 # Reject when unknown or invalid according to ROA
 print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
 reject;
 } else accept;
 } else reject;
};

安全检查，由外到内：

前缀必须在 dn42 合法范围内，且不接受自己的前缀从别人那里传回来，以防环路。
roa_check() 验证通告这个前缀的最终 ASN（bgp_path.last）是否被 ROA 表授权。不是 ROA_VALID 的一律拒绝，并打印日志。

全部通过则 accept。

Export Filter（出站过滤）

1
2
3
4


export filter {
 if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept;
 else reject;
};

只通告属于 dn42 合法范围的、且来源是静态路由（自己的前缀）或 BGP 学来的路由。避免将内核路由、直连路由等无关路由泄漏出去。

Import Limit

1

import limit 9000 action block;

如果从单个对等方收到超过 9000 条路由，就阻断该会话。这是一种安全机制，防止某个对等方因配置错误向本端泄漏海量路由（比如全表泄漏），保护主机的内存以及稳定性。

引入对等方配置

1

include "/etc/bird/peers/*";

从 /etc/bird/peers/ 目录加载所有对等方的配置文件。一般来说每次创建一个 peer 时，只需要在该目录下创建一个与该 peer 对应的配置文件即可。每个配置文件中定义一个 protocol bgp ... from dnpeers 实例，继承上面提到的模板，基本上只需要填入邻居的 IP 和 ASN 就行了。

整体数据流

整个配置的数据流思路：

路由器（即这台主机）通过静态路由声明自己拥有的前缀，BGP 模板将其通告给所有对等方；
从对等方接收路由时经过白名单、防环、ROA 的各个验证，合格的路由写入内核路由表（附带正确的源地址），从而使路由器能够正确地转发 dn42 流量。

从零开始接入 DN42 网络 - 1: 注册与身份认证

Sun, 22 Mar 2026 00:00:00 +0000

前言

一开始听说 BGP 还真不是从大黑书里，而是 MoonWX 玩 DN42 的时候一直给我安利。这下不得不玩一玩了。简单了解下来，DN42 确实是一个很适合学习真正的公网环境是如何运行的叠加网络。DN42 趣味在于调试的过程，不过接入这一块基本上也就是按照教程走，顺带在接入过程中学习一些网络知识，除了对等连接 (Peer) 这一步需要费些功夫配置。

本文大量参考了 DN42 的官方文档和一些社区资源，尤其是 DN42 Wiki 和蓝天大佬的博客文章。

大致思路

要接入一个网络，首先你需要在网络内有一个“身份”，包含一个 ASN（自治系统编号）、一个 IPv4 地址段（也可包含 IPv6 地址段）、该 ASN 的管理者、能够证明身份的通信凭证（auth key 之类）、联系方式等。
以上身份中的大多数内容是由自己来选择和定义的，但是需要先提交申请，并被批准，整个网络才会认可你的身份。
在 DN42 中，没有真正意义上的“接入点”，你可以在任何地方通过 VPN（如 WireGuard）连接到 DN42 网络中的其他节点来实现接入。这一步即是寻找其他节点并建立对等连接（Peer），需要配置好隧道软件 (VPN) 和 BGP 软件相关的设置。
同时找很多个人 Peer，这可以增加你网络的稳定性，避免某个节点临时故障导致你和 DN42 完全失联。并且，多 Peer 还能够提高其他节点的访问速度，提高网络的冗余性和整体性能。
后续的性能优化和安全配置等。

注册

注册的过程其实就是向 DN42 的身份信息 git 仓库提交 PR 的过程，各个信息配置文件的格式和内容都有严格的要求，被批准合并后就算拥有了自己管辖的 ASN 和 IP 地址段之类的了。

首先去 https://git.dn42.dev 注册一个账户，这是 DN42 通过 Gitea 提供的模板自部署的 DevOps 平台，类似于 GitHub。
所有 DN42 成员的账户信息就存放在仓库 dn42/registry 里。为了 PR，先 fork 一份到自己的账户。
Clone 已经 fork 的仓库到本地。
接下来就是创建并编辑各个自己所属的配置文件，提交 commit 后创建 PR 了。

需要注意 ASN 和 IP 地址段需要自己挑选空缺的，而且 IPv6 地址极不推荐自己定义地址段前缀，而是通过蓝天大佬提到的随机生成前缀的工具来生成，以符合 RFC4193 中对 IPv6 唯一本地地址的要求。下面列举所有初次注册时必须提交的 8 个文件（注意根据配置不同，可能还需要第 9 个文件 data/dns/[昵称].dn42）：

data/mntner/[昵称]-MNT：代表你的账户，用于验证后续操作
data/person/[昵称]-DN42：代表你个人的信息，包含昵称、邮箱等
data/aut-num/[你的ASN]：代表你想申请的 ASN 号，包含 ASN 号、AS 简介、管理者、联系方式等
data/inetnum/[地址段前缀]_[地址块大小]：代表你想申请的 IPv4 地址段，包含地址段前缀、地址块大小、管理者、联系方式等
data/route/[地址段前缀]_[地址块大小]：IPv4 地址段的路由信息，包含地址段前缀、地址块大小、AS 路由（即授权哪个 AS 使用这个地址段）等
data/inet6num/[地址段前缀]_[地址块大小]：代表你想申请的 IPv6 地址段（本文件是可选的，且如果不添加 IPv6 地址段，后续 data/route6 中的文件也可以不添加）
data/route6/[地址段前缀]_[地址块大小]：IPv6 地址段的路由信息

各个配置文件的内容和其解释可以直接参考蓝天大佬的博客的注册过程部分。描述和原理他已经讲的很清楚了，这里不作赘述。另外，一个好的学习方法是直接参考其他已经成功 merge 的 PR 或参考仓库中已经较为成熟的配置文件来写自己的部分。

这里补充一些蓝天大佬没提到的东西，以及一些需要注意的细节：

提交 commit 所使用的签名密钥必须要包含在 data/mntner/[昵称]-MNT 文件中的 auth 字段中。该字段的内容是用来验证后续操作的凭证，所以本次 PR 中的 commit 需要使用该密钥进行签名，使自动化验证工具能够确认你的身份拥有对该 ASN 和 IP 地址段的管理权限，并批准你的 PR。
寻找空闲的 IPv4 地址段时，蓝天提到了两个可用的网址，但是 https://dn42.us/peers/free 最后一次更新为 2025 年 10 月末，已经没有什么参考价值了。
对于 IPv4，DN42 一般建议申请的合适的地址块大小为 /27（即包含 32 个地址的块）
对于 IPv6，建议申请 /48 的地址段（即包含 65536 个地址的块）
v4 和 v6 的 inetnum (inet6num) 文件中所配置的 nserver 为反向 DNS 服务器，如果配置了，那么还需要在 data/dns 目录下添加一个对应的文件，内容包含反向 DNS 服务器的 IP 地址和主机名等信息。
一些文件的 remarks 字段可以添加一些比较美观的备注信息，增加一些个性化的内容，当然这不是必须的。以下展示我从 MoonWX 那里抄来的一个示例 remarks 字段：

由于蓝天没有提到第 5 点中的这个 DNS 文件，以下简单给出我这个文件的示例内容：

1
2
3
4
5
6
7


domain: sisy.dn42
admin-c: SISY-DN42
tech-c: SISY-DN42
mnt-by: SISY-MNT
nserver: ns1.sisy.dn42 172.23.15.33
nserver: ns1.sisy.dn42 fd24:ac8e:9e04::1
source: DN42

接下来，创建一个带签名的 commit 并提交 PR。PR 的审核过程可能需要一些时间，审核人员会检查你的配置是否符合要求，并且可能会提出一些修改建议。审核通过后，你的 PR 就会被合并到主分支，你就正式成为 DN42 网络的一员了。

其实感觉这里面最花时间的还是挑选自己喜欢的 ASN 和 IPv4 地址段，，，

关于第一个 Peer，暂且先决定放到下一篇里来讲吧。