自架服務 WireGuard NetBird Zero Trust mesh VPN IdP

WireGuard 解了加密、Headscale 解了路由,NetBird 用一支 binary 把 Zero Trust 的最後一塊拼起來

NetBird 在 2026 年 2 月釋出的 v0.65 把整套自架 mesh VPN 從原本五六個容器收斂到一支 binary,並內建 IdP 跟反向代理。本文拆解它跟 Headscale 的定位差異、unified binary 的工程取捨、內建 IdP 對自架門檻的影響,以及 Docker Compose 部署細節。

NetBird 在 2026 年 2 月釋出的 v0.65 把整套自架 mesh VPN 從原本五六個容器收斂到一支 binary,並在管理服務裡內建 IdP 跟反向代理。對於正在用 Headscale 撐 Tailscale 替代方案、卻一直繞不開「身分驗證要另外接一套」這個痛點的團隊,NetBird 提供的不是同類產品,而是更高一階的 Zero Trust 網路平台。

WireGuard 把端對端加密這件事壓到核心模組裡,效能跟簡潔度都遠勝過 OpenVPN 或 IPsec。但 WireGuard 本身只負責「兩個 peer 之間怎麼加密通訊」——peer 怎麼找到對方、誰能加入網路、ACL 怎麼設、SSO 怎麼接,全是上層問題。Headscale 把 Tailscale 的控制平面開源化,已經解決了很大一塊;NetBird 則把問題拉到「整個企業 Zero Trust」這個層級。

Headscale 是控制平面,NetBird 是完整網路平台

把兩個專案放在一起比較其實有點失焦——Headscale 的設計目標就是「給 Tailscale 客戶端一個自架的協調節點」,所以它接受了 Tailscale 客戶端的全部限制:閘道靠 DERP relay、ACL 用 Tailscale 那套 JSON 描述、SSO 走 Tailscale Connector 邏輯。優點是體積極小、跑得起來幾乎零維運;缺點是想擴充功能就會撞到 Tailscale 客戶端不開源的牆。

NetBird 從第一天就是自己一套體系。它有自己的客戶端(Go 寫的,BSD-3 授權)、自己的管理服務、自己的 signal server 跟 relay。完整的 Zero Trust 功能堆疊長這樣:

  • 管理服務:peer 註冊、ACL、user/group 規則、稽核日誌
  • Signal Server:peer 間 NAT traversal 的協調訊號,不轉發實際流量
  • TURN/Relay:peer 直連失敗時的中繼,用 coturn 或 NetBird 自家 relay
  • 內建 IdP:v0.62 之後直接內建,不必再架 Keycloak
  • 反向代理:v0.65 加進來的,等同於 Tailscale Funnel

換句話說 Headscale 解的是「Tailscale 控制平面屬於別人」這個問題,NetBird 解的是「整套企業遠端存取要怎麼自家化」這個更大的問題。

v0.65 把五個服務收進一個容器的工程取捨

NetBird 早期的 Docker Compose 配置長得很「微服務」:dashboard 一個容器、管理服務一個、signal 一個、coturn 一個、外加 Caddy 做 reverse proxy。實際運行五六個容器、每個都要顧 health check 跟 volume,部署門檻直接讓不少團隊放棄。

v0.65 釋出的 Unified Server Binary 是有意識的去微服務化決策。對於自架場景來說,management、signal、relay 三個服務通常都跑在同一台機器上,拆成三個容器只是增加部署複雜度,沒有實質的擴展性好處。把它們合進同一支 Go binary 的好處很直接:

  • 只剩一個容器要管,重啟、升級、看 log 都簡單
  • 內部通訊不必走 TCP socket,直接 in-process function call
  • 設定檔合併成單一 YAML,不必對齊三份 config 的版本
  • 記憶體基線從原本 500 MB 左右降到 200 MB 上下

代價是大型部署要橫向擴展時要把容器拆回去——但對絕大多數的自架使用者來說,這個取捨完全合理。

內建 IdP 把自架的心理門檻砍掉一大半

舊版 NetBird 強制依賴外部 OIDC 提供者,意味著想自架的人得先去學 Keycloak 或 Authentik。光是 Keycloak 一個 realm 設下來,對非身分驗證背景的工程師就是半天的學習曲線。

v0.62 引進內建 IdP 之後,整個流程變成:跑自架腳本、腳本自動建立第一個 admin user、從 dashboard 邀請其他成員、他們收到 email 就能登入。對於 30 人以下的小型團隊這就夠了。內建 IdP 支援本地帳號、密碼、TOTP 二階段驗證,完全是合理的最小集合。

需要走 SSO 的,再把外部 IdP 接上來——NetBird 支援 Authentik、Keycloak、Auth0、Google Workspace、Microsoft Entra ID,配置時切到外部 IdP 模式即可,使用者資料在遷移時可以保留。

這個設計取捨值得稱讚。Headscale 跟 Tailscale 的 SSO 都是「沒它就動不了」,內建 IdP 把這個前置條件拿掉,自架的心理門檻降了一大截。

反向代理補上 Funnel 那塊

Tailscale Funnel 讓 tailnet 裡的服務能對公網開放——把 service.tailnet.ts.net 變成可以從外部存取的網址,而且自動配 HTTPS。Headscale 一直沒有這個功能,因為它本質上就是個 control plane,不負責資料平面。

NetBird v0.65 的內建反向代理直接解決這件事。在管理介面上點幾下就能把某個 peer 上的服務(例如 internal-app:3000)對應到一個 *.netbird.example.com 子網域,自動申請 Let’s Encrypt 憑證、自動加上認證閘道、只允許網內成員存取。

底層的實作是把 Caddy 內嵌到管理服務裡——這也是為什麼 v0.65 之前需要在 Compose 旁邊另外跑一個 Caddy。內嵌之後一切都包在同一支 binary 裡,憑證、規則、log 集中管理。

對於 dev 環境想暫時開放某個服務給合作夥伴看、或是 staging 環境要讓 QA 從家裡連進來,這個功能比起「先架 Nginx 再設 SSO 再開防火牆規則」省掉太多步驟。

自架硬體配置與容量規劃

NetBird 自架管理服務的資源需求其實不大,因為 peer 之間是直連,管理服務只負責協調跟 ACL 評估。實務參考點:

  • 小型團隊(< 50 peer):1 vCPU、2 GB RAM、20 GB SSD 就夠了
  • 中型部署(50–500 peer):2 vCPU、4 GB RAM、50 GB SSD,relay 流量是主要變數
  • 大型部署(500+ peer):建議把 relay 拆出去獨立部署,避免 NAT traversal 失敗時 relay 流量擠爆管理節點

頻寬規劃要注意 relay 那一塊。理論上 peer 直連時 relay 不耗流量,但實際上有 NAT 環境(特別是雙重 NAT、企業防火牆封 UDP)會強制走 relay。觀察 NetBird 統計儀表板上的 relay 流量比例,超過 30% 就要考慮升級頻寬或部署多個地理位置的 relay。

控制節點不一定要放臺灣——它只處理控制訊號,延遲幾十毫秒對使用體驗沒有實際影響。但 relay 節點建議放在 peer 集中的區域,因為 relay 流量等於完整的應用流量。臺灣團隊的 relay 放臺灣本地會比走海外回程明顯順暢。

Docker Compose 五分鐘部署

從 v0.65 開始,官方 quickstart 腳本就是抓 unified binary 的 Compose 範本,問幾個問題然後跑起來:

1
2
3
export NETBIRD_DOMAIN=netbird.example.com
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started-with-zitadel.sh \
| bash

腳本會問對外網域(DNS 要事先指過來)、管理員帳號 email、是否啟用內建反向代理。跑完會吐出 admin 密碼,打開 dashboard 登入之後,安裝指令會直接顯示在介面上,複製到目標機器執行:

1
2
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://netbird.example.com:33073

第二行會跳出瀏覽器登入流程,或者顯示一個 setup key 讓你貼。完成之後這台機器就加進 mesh,可以從其他 peer 直接 ping 它的 NetBird IP。

正式上線前要調的幾個地方:

反向代理憑證:預設用 Let’s Encrypt staging,要切到 production 把 config 裡的 ca 設成 letsencrypt

Setup Key 過期:批次部署用的 setup key 預設一個月過期,CI/CD 跑容器時要避開這個陷阱,要嘛用長期 key、要嘛在 pipeline 裡動態取得。

Relay 認證:開放公網的 relay 一定要打開 hmac secret,否則任何人都能拿來當免費 TURN 中繼。

什麼情況下還是該選 Headscale

NetBird 不是 Headscale 的全面替代品。幾個明顯該留在 Headscale 的場景:

已經深度使用 Tailscale 客戶端:MagicDNS、Tailscale SSH、Funnel 客戶端側的整合在 Tailscale 原生客戶端上更成熟。Headscale 讓既有 Tailscale 部署能無痛搬控制平面,NetBird 則要全套換掉客戶端。

手上的設備跑著 Tailscale-only 的整合:某些 IoT 設備、NAS 內建 Tailscale 客戶端,這些東西沒有 NetBird 版本,硬上會卡住。

只要最小化的 mesh VPN:如果只想串幾台 VPS 不要被公網掃到、不在乎 SSO 跟 ACL,Headscale 五十 MB 的 binary 就是最輕的方案。NetBird 那些功能會變成沒在用的程式碼。

把企業遠端存取搬回自家機房

Zero Trust 網路在 2026 年已經是企業合規的硬性需求,Zscaler、Cloudflare Access 這類 SaaS 是預設選項。但成本曲線跟 Datadog 是同一回事——使用者規模上去之後價錢爆炸,而且員工存取資料的流量全部要送到第三方廠商,敏感產業(金融、醫療、政府)光是稽核就過不去。

NetBird 把 SaaS Zero Trust 平台的功能完整自家化,授權是 BSD-3-Clause,沒有「企業版才有的功能」這種陷阱。對於想把遠端辦公、CI/CD agent、伺服器運維通道整合在同一張網的團隊,這套東西是少數真正把所有元件都開源的方案。

要在臺灣本地架設 NetBird 控制平面與 relay 節點,網路延遲跟跨境穩定度是決定使用體驗的關鍵。NCSE Network 提供位於是方電訊機房的 VPS 主機與 IP Transit 服務,臺灣骨幹直連對於 UDP-heavy 的 mesh VPN 流量特別友善,relay 節點放在這裡能明顯改善 NAT 穿透失敗時的回退體驗。前往 ncse.tw 了解規格與方案。

需要高品質的網路服務?

NCSE Network 提供 IP Transit、IP Tunnel 及 BGP 路由規劃,10M~100G 彈性頻寬,多上游備援確保穩定。

了解網路服務 →