軟體VPN 原理：為什麼隧道協定
但 UDP 有個致命傷：很多企業防火牆、學校網路、公共 Wi-Fi 會封鎖非標準的 UDP 流量。這時候就會需要「走 TCP 443」這種備援方案，讓 VPN 流量偽裝成一般 HTTPS。OpenVPN 之所以長年被認為相容性最好，很大一部分原因就是它同時支援 UDP 與 TCP，而且可以設定成 443 埠，幾乎能穿過所有只開放網頁流量的環境。代價是 TCP 模式的延遲與吞吐通常明顯較差。
任務二：加密與完整性保護
封裝只解決「怎麼包」，加密才解決「被看到會怎樣」。現代協定幾乎都採用「認證加密」（AEAD）模式，例如 AES-GCM 或 ChaCha20-Poly1305。這類演算法的好處是：加密與完整性檢查一次完成，不需要先加密再另外算一個 MAC，封包開銷比較小，實作也比較不容易出錯。
相較之下，老一輩的設計常常是「加密用一種演算法、認證用另一種」，例如 IPSec 的 ESP 可以搭配 AES-CBC 加上 HMAC-SHA1。這種組合不是不能用，但設定複雜、參數眾多，實作上一旦搭配錯誤，就可能出現安全性被削弱的狀況。這也是為什麼新興協定傾向把「唯一正解」寫死，減少使用者與廠商亂配的機會。
任務三：身分認證與金鑰交換
這是整個隧道最關鍵、也最常被忽略的一環。你必須確認「對面那台真的是 VPN 伺服器」，否則中間人可以假裝成伺服器，你等於把資料直接送給他。常見做法有兩種：一是憑證（Certificate）搭配 TLS 握手，二是預共享金鑰（PSK）或公私鑰配對。
PPTP 之所以被淘汰，不只是加密弱，更因為它的 MS-CHAP v2 認證機制早已被證明可以離線破解，攻擊者只要攔截到握手過程，就能還原出你的帳號密碼。反觀 WireGuard，它要求雙方事先交換公鑰，沒有「先連上再說」的空間，從設計上就排除了大量中間人攻擊的可能。這種「把安全邊界前移到設定階段」的思路，正是現代隧道協定的共同趨勢。
三、主流隧道協定逐一拆解：從歷史遺產到現代輕量
理解三大任務之後，我們就可以用同一把尺來衡量各個協定。以下依「誕生年代」排序，順便說明它們為什麼會長成現在這個樣子。
PPTP：便宜、快、但已經不該再用的歷史遺產
PPTP（Point-to-Point Tunneling Protocol）誕生於 1990 年代中期，原本是為了讓撥接用戶建立點對點連線。它的封裝非常輕薄：用 GRE 把 PPP 封包包起來，外層再走 IP。因為標頭開銷小、運算需求低，在當年處理器很慢的時代，PPTP 的速度表現相當亮眼，也幾乎所有作業系統都內建支援。
問題在於它的加密與認證。PPTP 使用的 MPPE 加密基於 RC4，金鑰強度與派生方式都有已知弱點；MS-CHAP v2 認證更是早在 2012 年就被公開示範可被破解。時至今日，任何還把 PPTP 列為預設選項的服務，都應該被視為「不重視使用者安全」。它在某些老舊內網環境仍有存在價值，但絕對不適合用來保護日常上網隱私。
L2TP/IPSec：把「不加密的隧道」交給 IPSec 補救
L2TP 本身其實只負責建立通道，不負責加密。它常被誤認為一種加密協定，實際上它只是把 PPP 封包包起來傳送，真正提供機密性的是搭配的 IPSec（通常是 ESP 模式）。這種「兩層疊起來」的設計，導致封包開銷偏大：外層 IP、UDP、L2TP 標頭、IPSec ESP 標頭與尾端認證碼層層相加，MTU 消耗明顯。
L2TP/IPSec 的優點是幾乎所有平台都原生支援，設定相對標準化，企業環境接受度高。缺點除了開銷大，還有「UDP 500 與 4500 埠容易被封鎖」的實務問題。另外，部分實作使用預共享金鑰（PSK）作為認證，如果金鑰設定太弱或外流，整條通道的安全性就會被打折。整體來說，它是「堪用但不精簡」的選擇。
OpenVPN：用 TLS 把 VPN 變成一個可稽核的應用程式
OpenVPN 是開源社群的代表作，最大的貢獻是把 VPN 從「核心層的特殊協定」變成「使用者空間的一般應用程式」。它使用 OpenSSL 進行 TLS 握手，透過憑證互相認證，加密與雜湊演算法可以選擇，也支援 UDP 與 TCP。因為走的是標準 TLS，它能夠輕易穿過大多數防火牆，也能跑在 443 埠上偽裝成 HTTPS。
這種設計的優勢是彈性與可稽核性：安全社群可以逐行檢視程式碼，演算法也能隨時間更新。但彈性也帶來成本——設定檔參數繁多，握手過程比現代協定冗長，重新協商（rekey）時會有额外的運算負擔。在低功耗裝置或老舊手機上，OpenVPN 的 CPU 佔用與耗電通常比 WireGuard 明顯。不過它的成熟度與跨平台支援仍然是目前最可靠的選項之一。
WireGuard：把「最少程式碼」當成安全策略
WireGuard 的設計哲學幾乎與 OpenVPN 相反：不要選項、不要協商、不要歷史包袱。它固定使用 Curve25519 做金鑰交換、ChaCha20-Poly1305 做認證加密、BLAKE2s 做雜湊，整份程式碼量只有數千行，核心邏輯可以在很短時間內被審閱。每個對等節點就是一組公私鑰，設定好之後，封包處理流程非常線性。
這種「無狀態」設計帶來兩個實務好處。第一是速度：加解密開銷小，握手次數少，在行動裝置上特別有感。第二是漫遊（Roaming）：當你的手機從 Wi-Fi 切到 4G，來源 IP 變了，WireGuard 不需要重新建立隧道，只要收到新的合法封包就會自動更新對端位址，連線中斷時間極短。這也是為什麼近幾年幾乎所有新興 VPN 服務都把 WireGuard 列為主打。
它的限制也來自同一組設計：沒有內建的動態位址指派與複雜認證流程，需要靠外部工具管理金鑰；預設只走 UDP，遇到封鎖 UDP 的網路就比較被動；而且「金鑰即身分」代表金鑰外流等於身分被冒用，端點管理必須更謹慎。
IKEv2/IPSec：為行動網路而生的切換高手
IKEv2 是 IPSec 體系現代化的版本，最大的特色是 MOBIKE 擴充，能在 IP 位址改變時重新協商通道，而不必整條斷掉重連。對經常在高鐵、捷運、咖啡廳之間移動的使用者來說，這種「換網不斷線」的體驗非常有感。它也原生支援多種作業系統，在 iOS 與 Android 上的省電表現通常不錯。
IKEv2 的封包開銷介於 L2TP/IPSec 與 WireGuard 之間，握手效率比舊版 IKEv1 好很多。不過它同樣受限於 UDP 500/4500 埠，在嚴格防火牆環境下可能需要額外設定。整體而言，它是「行動裝置 + 企業級認證」情境下的穩健選擇。
五種協定橫向對比
協定
傳輸層
加密代表
封包開銷
穿透防火牆
行動切換
建議情境
PPTP
GRE/IP
MPPE（RC4）
普通
不建議使用
L2TP/IPSec
UDP
AES-CBC + HMAC
差（易被封）
普通
內建相容、臨時使用
OpenVPN
UDP/TCP
AES-GCM
中高
佳（可走 443）
普通
需要高相容性與可稽核
WireGuard
UDP
ChaCha20-Poly1305
普通
極佳
行動裝置、高速、省電
IKEv2/IPSec
UDP
AES-GCM
普通
佳（MOBIKE）
企業、跨網路切換
四、為什麼換個協定，速度差距會這麼大？
很多人會發現，同一條光纖、同一台伺服器，光是切換協定，測速結果可以差到三成以上。這不是錯覺，而是隧道協定的「物理成本」直接反映在頻寬與延遲上。以下三個因素最關鍵。
標頭膨脹與 MTU 黑洞
網路卡預設的 MTU（最大傳輸單元）通常是 1500 位元組。隧道封裝會在原本的封包外面加上一層層標頭，等於「可用的內層空間」被壓縮。若內層封包超過這個空間又沒有正確分段，就會出現「大封包過不去、小封包正常」的怪現象，俗稱 MTU 黑洞。症狀包括：網頁開得出來但圖片卡住、SSH 連得上但傳檔中斷、某些網站永遠轉圈。
不同協定的開銷差異明顯：PPTP 大約吃掉 40 位元組，L2TP/IPSec 可能吃掉 60 到 80 位元組以上，OpenVPN 的 UDP 模式約 60 至 70 位元組，WireGuard 約 60 位元組（IPv4）。看起來差不多，但加上 IPv6、雙棧、額外認證標頭之後，累積起來就足以讓 MTU 從 1500 掉到 1400 以下。好的軟體 VPN 會自動做 MSS Clamping（把 TCP 最大區段大小調小），爛的軟體則要你自己去改登錄檔或終端機指令。
CPU 運算與加密吞吐
加密不是免費的。AES-GCM 在現代 x86 處理器上有 AES-NI 指令集加持，幾乎不構成瓶頸；但在沒有硬體加速的老舊裝置、或者部分 ARM 平台上，ChaCha20 反而更快。這就是為什麼 WireGuard 在手機上特別省電——它預設用 ChaCha20，不必依賴硬體加速，在低功耗晶片上也能維持不錯的吞吐量。
另一個常被忽略的是「單執行緒效能」。OpenVPN 的傳統實作以單執行緒處理加解密，在多核心 CPU 上難以吃滿；WireGuard 則在核心層採用多佇列（multi-queue）設計，能隨核心數擴展。這在 gigabit 等級的線路上差異尤其明顯：一條 1Gbps 的連線，OpenVPN 可能只能跑到 300 到 500Mbps，而 WireGuard 有機會接近線速。
行動網路切換與重連成本
通勤族最有感：從捷運站走出來，Wi-Fi 斷了、切到 5G，VPN 圖示開始轉圈。這是因為多數協定需要重新握手、重新協商金鑰。IKEv2 的 MOBIKE 與 WireGuard 的無狀態設計，都能把這個中斷時間壓到極短；而 OpenVPN 與 L2TP/IPSec 在同樣情境下，往往需要數秒甚至十幾秒才能恢復。對於視訊會議、VoIP 通話來說，這幾秒就是「通話被掛斷」與「無感切換」的差別。
五、軟體 VPN 的實作架構：TUN/TAP、路由與洩漏防治
理解了協定，還要看軟體怎麼把它接上作業系統。這一段決定你的 VPN 會不會「看起來連上了，其實沒保護到」。
TUN 與 TAP：第三層與第二層的選擇
Linux 與 macOS 上的 VPN 軟體通常會建立一個虛擬網路介面，名為 TUN 或 TAP。TUN 是第三層（IP）介面，只處理 IP 封包，效率高、開銷小，是多數現代 VPN 的預設。TAP 是第二層（乙太網路）介面，會模擬一張虛擬網卡，能傳遞 ARP、廣播封包，適合需要橋接區域網路的企業情境，但效率較差。
Windows 上則以 TAP-Windows 或 Wintun 驅動程式實作，Wintun 就是 WireGuard 官方提供的輕量驅動，效能明顯優於舊版 TAP。這些細節一般使用者不會直接接觸，但驅動程式的品質會直接影響 BSOD（藍白當機）機率與待機耗電。
路由改寫：預設閘道與分流
VPN 連線建立後，軟體會修改系統路由表，把「預設路由」指向虛擬介面，讓所有流量都走隧道。這就是所謂的全域模式（Full Tunnel）。另一種是分流模式（Split Tunnel），只把特定網段或特定應用程式的流量導進隧道，其餘走本地網路。分流能降低延遲、節省伺服器頻寬，但如果規則設定錯誤，就可能出現「本該保護的流量漏出去」的狀況。
更細緻的做法是「依應用程式分流」，需要作業系統支援（例如 Android 的 VpnService 可以指定允許清單）。這也是為什麼同樣是 VPN App，Android 版與 Windows 版的功能常常不對等——底層 API 的能力差異很大。
DNS 洩漏與 IPv6 洩漏：最常見的「假連線」
即使隧道建起來了，只要 DNS 查詢仍然走本地 ISP，你的瀏覽紀錄就等於被看光。好的軟體 VPN 會在連線時強制把 DNS 指向隧道內的解析器，並在斷線時封鎖流量（Kill Switch），避免「回落到本地網路」的瞬間洩漏。
IPv6 是另一個經典漏洞。許多 VPN 只處理 IPv4，當你的系統同時啟用 IPv6 時，部分流量會直接走原生 IPv6 出去，完全繞過隧道。測試方法很簡單：連上 VPN 後開啟 IPv6 測試網站，若顯示你的真實 IPv6 位址，就代表有洩漏。專業的軟體會提供「停用 IPv6」或「封鎖非隧道流量」選項，這也是評測時應該實際檢查的項目。
六、實務選購與自我檢測：把原理變成可操作的清單
講完原理，最後回到實用面。以下幾個判斷點，可以幫你在眾多軟體與設定中做出選擇。
依情境選協定，而不是依「最新」選
如果你主要在手機上使用、經常切換網路、重視省電與速度，WireGuard 或 IKEv2 是首選。若你身處防火牆嚴格的環境（公司、學校、某些國家），需要極高的連線成功率，OpenVPN 走 TCP 443 仍是可靠備援。若你在老舊裝置上使用，或者需要與既有企業 IPSec 架構整合，L2TP/IPSec 與 IKEv2 的原生支援會省下很多麻煩。至於 PPTP，除非你是為了連進某個只支援 PPTP 的舊內網，否則沒有理由啟用。
五分鐘自我檢測流程
IPv6 檢測：確認沒有原生 IPv6 流量繞過隧道。
評測時該看的「非行銷」指標
伺服器數量與價格固然重要，但真正影響長期體驗的是：協定更新頻率（是否支援 WireGuard、是否淘汰 PPTP）、是否開源或至少經過第三方稽核、有無獨立 Kill Switch 與 DNS 保護、行動版是否支援依應用程式分流、以及是否提供連線日誌政策說明。這些項目不會出現在華麗的廣告頁上，卻決定了你在關鍵時刻會不會被出賣。
結語：隧道協定是 VPN 的骨架，不是規格表上的裝飾
回到最初的問題：為什麼隧道協定這麼重要？因為它同時決定了三件事——你的資料怎麼被包裝、被誰看到、以及在中斷與切換時會發生什麼。封裝方式影響速度與相容性，加密與認證方式影響隱私與信任邊界，通道管理方式影響行動體驗。這三者無法同時最大化，每個協定都是在特定時代背景下做出的取捨。
PPTP 用安全性換取輕量，L2TP/IPSec 用標準化換取相容，OpenVPN 用彈性換取可稽核性，WireGuard 用極簡換取速度與省電，IKEv2 用行動友善換取企業整合。理解這些取捨之後，你就不會再被「支援五種協定」這種話術迷惑，而會去問：這五種裡面，哪一種是我真正需要的？它的預設值合理嗎？切換時我的流量會不會短暫裸奔？
軟體 VPN 的價值，從來不是「有沒有一個開關」，而是「這個開關背後的隧道，蓋得夠不夠紮實」。下次打開設定頁面時，不妨多看一眼那個協定選單——那裡面藏著的，是整個團隊對安全與效能的理解深度。
```