💡 前言
在企業內部或小型環境中，我們有時會為了簡化設定，採用 OpenVPN 的靜態金鑰模式（Static Key Mode）。
這種架構只需要一個 secret key，不需憑證與 CA 架構即可建立安全的點對點加密通道，非常適合固定主機間的連線。
不過，若希望讓使用者（特別是筆電使用者）所有網路流量都經由 OpenVPN 伺服器轉送，
就會遇到一個經典問題：
一旦使用者接受 default gateway，VPN 反而會斷線。
本文將深入分析問題的根源與正確的設定方式，讓你能穩定實現「全流量走 VPN」的需求。
🔍 問題現象：為什麼會斷線？
在 OpenVPN 中，如果客戶端把預設閘道改成 VPN（例如 route 0.0.0.0 0.0.0.0 10.40.0.1），
那麼所有封包——包含控制通道本身（UDP 37000）——都會被導進 VPN 隧道。
由於連線尚未完全建立，控制封包出不去，VPN 立即中斷。
這就是論壇上常見的「設定 default gateway 後無法連線」問題。
⚙️ Static Key 模式的特性
靜態金鑰模式是最精簡的 OpenVPN 架構：
- 伺服器與客戶端共用一個 key (
secret /etc/openvpn/ns01.key) - 產生Static Key : openvpn –genkey –secret ns01.key
- 不使用憑證與 TLS 握手
- 無法使用
push指令傳送路由或 DNS 設定給客戶端 - 因此所有路由都必須 手動設定在 client.conf 裡
換句話說，「讓流量全走 VPN」這件事，在 static key 模式中只能靠客戶端手動完成。
✅ Server 端設定範例
port 37000
proto udp
dev tun
secret /etc/openvpn/ns01.key
ifconfig 10.40.0.1 10.40.0.2
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
mssfix 1450
compress lz4
verb 3
daemon
user nobody
group nobody
# 系統層啟用 IP 轉送與 NAT
# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -s 10.40.0.0/24 -o eth0 -j MASQUERADE
🔸 系統層設定
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.40.0.0/24 -o eth0 -j MASQUERADE
這樣，來自 10.40.0.0/24 的流量就會透過伺服器 NAT 出網。
✅ Client 端設定：關鍵在於「主機路由保護」
remote <server_public_ip> 37000
proto udp
dev tun
secret ns01.key
ifconfig 10.40.0.2 10.40.0.1
# 🌐 關鍵設定 1：保留控制通道的主機路由
route remote_host 255.255.255.255 net_gateway
# 🌐 關鍵設定 2：設定 default gateway 走 VPN
route 0.0.0.0 0.0.0.0 10.40.0.1
persist-tun
persist-key
ping 10
ping-restart 60
mssfix 1450
verb 3
🔍 說明
route remote_host會自動取代為remote指定的伺服器 IP。net_gateway是 OpenVPN 的內建變數，代表目前系統的實體預設閘道。
也就是筆電當下連網的路由器（可能是家裡的 192.168.1.1、公司的防火牆、或手機熱點）。- 這兩條指令讓 VPN 控制封包走「原路」，其餘流量走 VPN。
結果就是：
- 控制通道穩定不中斷；
- 使用者上網、EIP、ERP、Mail 全部流量都經 VPN 出口。
🧩 實際路由表檢查
連線後在客戶端輸入：
ip route
應看到：
default via 10.40.0.1 dev tun0
10.40.0.0/24 dev tun0 proto kernel scope link src 10.40.0.2
<server_public_ip>/32 via <local_gw> dev wlan0
最後一行就是防止自我切斷的「主機路由」。
🚀 進階設定：模擬 redirect-gateway def1
若你想模擬 TLS 模式的行為，也可這樣寫：
route remote_host 255.255.255.255 net_gateway
route 0.0.0.0 128.0.0.0 10.40.0.1
route 128.0.0.0 128.0.0.0 10.40.0.1
這樣會建立兩條 /1 路由以取代 default route。
但實務上使用 route 0.0.0.0 0.0.0.0 10.40.0.1 已足夠。
🔒 如果環境允許，TLS 模式更穩定
若你願意升級至憑證式架構（server / client 指令），
可直接用：
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
OpenVPN 就會自動幫所有客戶端保留主機路由，
再也不需要手動設定。
但若只是單點連線、IoT、或測試用途，static key 模式仍然相當方便。
⚠️ 常見踩雷整理
| 問題情況 | 原因 | 解法 |
|---|---|---|
| 連線後馬上斷線 | 控制通道被導入 VPN | 使用 route remote_host ... net_gateway |
| Client 能 ping VPN，但上不了網 | Server 未做 NAT 或未開 IP Forward | 開啟 net.ipv4.ip_forward 並加 MASQUERADE |
| VPN 正常但流量卡頓 | MTU/MSS 太大 | 加上 mssfix 1450 |
| 家用路由與 VPN 網段重疊 | 路由衝突 | 改 VPN 網段，例如 10.66.0.0/24 |
🎯 結論
在 OpenVPN 靜態金鑰模式下，
「接受 default gateway」並不會自動導致斷線，
真正的問題在於——控制通道封包也被導進 VPN。
解法很簡單：
route remote_host 255.255.255.255 net_gateway
route 0.0.0.0 0.0.0.0 10.40.0.1
搭配伺服器的 NAT 設定，就能穩定實現 full-tunnel VPN。
這套方式適用於筆電、多變的行動環境與任何無法事先預知閘道的使用場景。
📘 延伸閱讀