WireGuard 從 2020 年 3 月進 Linux 5.6 主線以來，一直沒有原生的多因素驗證，也沒有 session 概念——它的驗證邏輯只有一件事：對方的公鑰在不在 peer 清單裡。這個極簡設計是它效能能碾壓 OpenVPN、程式碼可以壓在 4000 行以內的關鍵，也是這幾年想把它推進企業環境的人最常撞的牆。Defguard 2.1.0 在 2026 年 9 月 4 日釋出，把 MFA、SSO、以及新的裝置姿態驗證全部塞進 WireGuard 的資料層，做法是把預共享金鑰（PSK）當成可輪替的 session token 用——這個角度值得拆開來看。
Defguard 是用 Rust 寫的零信任遠端存取平臺，桌面端走 Tauri v2、伺服器端把身分、政策、閘道拆成三個獨立元件。它的取捨是死守 WireGuard 官方協定、把所有企業級功能包在上一層，讓底下的 kernel WireGuard 或 wireguard-go 完全不需要動。
WireGuard 為什麼沒 MFA，以及這件事在實戰的成本
WireGuard 協定的每一次 handshake 都只做一件事：走 Noise IK 模式的靜態 ECDH，用雙方靜態公鑰配對算出共同秘密，MAC 驗過就給對方一組短期對稱金鑰。整個交握不用數位簽章、不用帳號密碼，也沒有任何挑戰響應——就算掛上 pre-shared key，也只是給對稱通道再疊一層抗量子的預混料，不改變授權模型。
這個設計拿去做點對點翻牆或家用 site-to-site 沒問題，但企業採用會踩到三個典型場景。第一個是筆電被偷：攻擊者只要能拿到 wg0.conf，vpn 就是他的，沒有第二道關卡。第二個是內部人員離職：管理者得手動把那把公鑰從所有 peer 檔案裡刪掉，稍有遺漏就是後門。第三個是合規要求——NIS2、ISO 27001、金融業內稽核，越來越多明文要求「所有遠端存取需經 MFA」，一把靜態公鑰過不了這條線。
過去業界的做法多半是繞路。Tailscale 用它的協調伺服器接 SSO，登入時發一次性設定，靠 client 幫忙擋住；NetBird 走同一條路，把身分驗證做在協調層，peer 表由中央推送。這兩條路的共同前提是：得用自家 client、自家協定去疊，不能拿標準 wg-quick 直接連。這個代價對於已經有既有 WireGuard 部署的組織來說並不小。
Defguard 用 PSK 當 session token 的巧思
Defguard 2.1 的做法直接得多。WireGuard 的每個 peer 除了公鑰外，本來就可以掛一組 pre-shared key，這是協定支援的欄位。Defguard 把這欄位重新利用成「授權票券」：MFA 通過前，Gateway 不會把 peer 塞進 wg 介面，也不會發 PSK；MFA 通過的當下，Core 產生一組新的 PSK，透過 Edge 這個對外代理下發給 client，同時把 peer + PSK 寫進 Gateway 的 wg 設定。
在使用者這端看到的是：桌面 client 按下連線，跳出 TOTP 或 WebAuthn 或生物辨識的驗證頁，過關之後 client 才真的建立 handshake。從 WireGuard 協定本身的角度看，這就是一次標準的 wg0 連線；差別在於這把 PSK 是動態的、每次 session 都不同。
登出的偵測是這個機制裡最巧的地方。WireGuard 是無狀態的，client 直接關筆電、拔網路，Gateway 這端沒有任何通知。Defguard 靠讀 wg 的 latest handshake 欄位來判斷——WireGuard 大約每 2 分鐘會做一次金鑰重協商（rekey），如果最新的 handshake 時間超過 3 分鐘沒動，Defguard 就把這個 peer 標記為已離線，刪掉 PSK、從 wg 介面移除 peer。下次要連回來，client 得重跑一次 MFA 流程。
這個設計的重點是：所有的驗證跟撤銷都做在 WireGuard 協定本身之外，但作用力落在 wg 介面上。底層 WireGuard 完全不需要改，也就自動繼承了它的效能、跨平臺、審計過的密碼學。跟那些把 auth 塞進協定本身、需要改 client 也改 server 的方案比，Defguard 這條路的相依性明顯低很多。
三段式架構把管理平面藏在攻擊面之外
Defguard 2.0 引進、2.1 補強的三段式架構是另一個值得注意的設計：Core、Edge、Gateway 三個元件各司其職。Core 管身分、政策、稽核紀錄——換句話說就是資料庫跟決策引擎，這一塊絕對不該直接曝在公網。Edge 是唯一對外暴露的元件，職責是幫 client 跟 Core 之間轉發已加密的驗證流量，同時處理 TLS 終結。Gateway 才是實際跑 WireGuard、把 peer 塞進 wg0 的地方，通常部署在被保護的網段裡。
這個切分方式的實務意義是：管理平面（Core）不需要有公網 IP，只要 Edge 能連得到 Core、Gateway 能連得到 Core 就夠了。攻擊者掃遍全網也找不到 Core，能打的只有 Edge——而 Edge 是刻意設計成薄薄的一層代理，攻擊面小、易於審計。這個切法跟 Cloudflare Access、Twingate、Google BeyondCorp 的架構本質上是同一套邏輯。
2.0 起 Core 跟 Edge 都內建 SSL 終結，不需要另外架 Nginx 或 Caddy 反代處理 TLS，也不用手動管憑證輪替。這件事對於中小型自架環境是實際的簡化——少一層元件就少一個要調的設定檔跟一個要監控的服務。
2.1 起也支援多顆 Gateway 跟多顆 Edge 部署，高可用性從 1.x 的「靠 keepalived 或前面架 LB」變成原生支援。對於跨機房或跨地區的部署，這條路乾淨很多。
2.1 的裝置姿態驗證把零信任的一塊拼圖補上
過去 Defguard 的驗證邏輯到 MFA 就結束了：使用者驗過了、裝置公鑰在清單裡，就放行。2.1 引進的 Device Posture Verification 把「這臺裝置本身安不安全」也拉進決策——client 每次連線前，會回報自己的作業系統版本、client 版本、系統更新狀態、防毒軟體是否啟用、磁碟是否加密、是否在 AD 網域裡等資訊，Core 比對政策後才決定放不放行。
實務意義很直接。典型攻擊路徑是：員工的個人筆電裝了 defguard client、驗證通過，但這臺筆電作業系統三個月沒更新、瀏覽器裝了不明擴充——一旦裝置被打，攻擊者就借用這個合法 tunnel 進內網。Device posture 讓管理者可以定義「作業系統 patch 落後超過 30 天禁止連線」「未啟用磁碟加密的裝置不能連生產環境」這類規則，把裝置本身的安全狀態接進決策。
這條路 CrowdStrike、Cloudflare WARP 已經走了幾年，商用產品也不便宜。Defguard 把它做進開源核心的意義是：自架 VPN 的組織不需要再另外買一套 EDR 端點政策管理才能達到同樣效果，對於已經有內部 IT 但預算不足以疊商用 zero-trust 平臺的中型組織尤其實用。政策以 location 為單位設定——「生產環境要嚴、測試網段可以寬鬆」這種常見需求可以直接落地，不需要多開好幾套 defguard instance。
對照 Headscale 跟 NetBird，Defguard 該選在哪
三套方案在自架 WireGuard 圈子裡常被拿來比較，但定位其實不太一樣。
Headscale 是 Tailscale 協調伺服器的開源重製，最大優勢是可以繼續用 Tailscale 官方 client，全平臺體驗一致，只是後端換成自架。缺點是它繼承了 Tailscale 的所有設計限制，MFA、SSO 得靠外掛，Web UI 幾乎沒有官方支援，適合已經用過 Tailscale、想把控制權拉回自家的人。
NetBird 是全自研路線，自己的 client、協調層、relay，BSD-3 授權。MFA 接在 OIDC 那邊，登入時驗過就放行，session 期間不再驗第二次。功能齊全但架構相對重，對中大型組織友善。
Defguard 的差異在於完全不動 WireGuard 協定、MFA 落在資料層（每次 tunnel 建立都要驗）、加上 device posture。對需要過稽核的組織是直接的合規武器——每次連線的驗證紀錄都在 log 裡，可以拿出來給稽核看。缺點是需要跑自家桌面 client，不能用 wg-quick 直接連（因為 wg-quick 不會跑 MFA）。
實用建議：想要 Tailscale 那種即開即用、對合規需求不高，選 Headscale；已經在跑 OIDC 生態、需要 SSO 但不介意架構重，選 NetBird；有合規需求、要每次連線都驗 MFA、又想把裝置安全狀態接進決策，Defguard 是這三者裡唯一能一次到位的。
VPS 上部署 Defguard 該怎麼放
Core 不該對外曝 IP，乾淨的做法是在內部 VPS 或機房內主機跑 Core，透過內部網路連 Edge 跟 Gateway。Edge 放在有公網 IP 的 VPS 上，因為只做代理跟 TLS 終結，512MB 到 1GB 記憶體的小機器就夠用。Gateway 放在被保護網段邊界，如果整套系統就是要保護單一 VPS 上的服務，跟被保護的應用同機部署也可以。
WireGuard 對頻寬跟延遲都敏感，選 VPS 時要注意實體位置跟到使用者的 RTT。臺灣本地機房比起海外節點在跨海延遲上有 100 到 200ms 的優勢，在 tunnel 上疊 SSH、遠端桌面、資料庫連線這類互動式工作負載感覺很明顯。IP Transit 品質也直接影響體感，同樣是臺灣機房，接骨幹跟走家用線的 peering 差好幾倍。
Gateway 端建議跑 Linux kernel WireGuard 而不是 wireguard-go，前者在單顆現代 CPU 上可以吃到接近 10Gbps，後者只能推到 500Mbps 左右。Debian 12、Ubuntu 22.04 以上跟主流雲廠商的 Rocky Linux 9 都內建 kernel 支援，不需要另外編。
Defguard 2.1 免費層支援 10 個使用者、30 臺裝置，超過就得走商用授權。這條線中型組織要注意，也可以先停在 1.6.x 分支——支援到 2026 年 10 月 31 日，之後就沒有安全更新。
結論：把 MFA 拉進資料層是自架 VPN 該走的下一步
WireGuard 協定本身極簡是它的優勢，也是它在企業採用上的天花板。Defguard 2.1 的取徑證明了一件事：不用動協定、不用改 client 底層，也能把 MFA 跟裝置姿態這些現代零信任的必備能力補完。對於在意合規、又不想把 VPN 送到 SaaS 廠商手上的組織，這是 2026 年開源選項裡最完整的一套。
NCSE Network 在臺灣是方電訊機房提供 VPS 主機服務，搭配 IP Transit 網路，適合部署 Defguard 這類需要低延遲、穩定連線的自架零信任閘道。若考慮把遠端存取架構從傳統 VPN 升級到零信任模式，可以參考 ncse.tw 上的 VPS 與網路服務方案，把 Core、Edge、Gateway 三段式架構跑在同一個機房內的低延遲網段裡。
