Azure企業實名帳號 跨國網路架構Azure VPN設定：建立辦公室到香港伺服器的加密通道

Azure企業實名帳號 前言：為什麼跨國 VPN 不能只看「能連上」

跨國連線最怕兩件事：第一是「看起來連上了，但流量走歪了」；第二是「初期能用，過幾天就不穩」。因此，Azure VPN 的設定重點不只是把隧道做出來，而是把它做成一條可預期、可驗證、可維運的安全通道。

你想要的是從辦公室到香港伺服器的加密通道。這代表兩端至少包含：辦公室網路邊界設備（路由器/防火牆或主機）、香港伺服器所在的網路（可能是本地機房或雲端）、以及 Azure 上承載 VPN 閘道的元件。你需要的是一個清楚的規劃：哪些網段彼此能互通、流量應走哪條路徑、加密設定是否一致、以及如何用測試指標確認安全與可用性。

第一章：需求盤點與架構選型

1.1 先把「要連什麼」寫清楚

在設定之前，先把需求拆成可落地的清單。至少回答以下問題：

• 辦公室要連香港哪些網段？例如：香港內網 10.10.0.0/16、特定伺服器 10.10.20.10/32。
• 是否需要存取共用服務？例如網頁、資料庫、檔案服務、管理介面（SSH/RDP）。
• 是否有多站點未來擴充？例如之後增加分公司或遠端辦公。
• 預期流量型態：少量管理連線、還是有大量資料傳輸？
• 對延遲與吞吐量的要求：是否需要接近穩定的帶寬或僅需加密連線。

把這些寫成文件，你後面在路由、存取控制、故障排查時就不會反覆猜。

1.2 擇定 VPN 模型：站點到站點 vs. 以太網架構的互連

Azure企業實名帳號 在 Azure 世界裡，常見的跨網連線思路包含站點到站點 VPN（Site-to-Site）、以及用其他網路互連方案（例如 ExpressRoute 等）。本文聚焦在「Azure VPN」的典型做法：使用站點到站點 VPN 將辦公室出口與 Azure 建立加密隧道，再讓流量到達香港伺服器。

注意：你這裡的「香港伺服器」可能並不直接連在 Azure；更常見的是，你在 Azure 上建立入口（或中轉網段），並透過路由把目的網段指向香港那側的網路。這就導致一個關鍵：你必須定義「香港網段是怎麼到達的」。如果香港端也是一個 VPN/路由裝置，則可以形成多段互連；如果香港端在 Azure 外部，但可透過某種閘道連線，那你需要確保整體路由一致。

1.3 網段規劃：避免重疊是成功的一半

跨國 VPN 的最常見踩雷是「網段重疊」。例如辦公室使用 10.0.0.0/8、香港也使用 10.0.0.0/8，結果 Azure 或對端在路由判斷時會把包送錯地方。

建議做法：

• 列出辦公室子網、Azure VPN 需要通告的子網、香港子網。
• 確認三者不重疊；若不可避免，至少也要確定你採用的路由與轉譯策略可控。
• 若你是管理自有網路，優先調整使用較不會衝突的私有網段。

有了良好的網段規劃，後續路由宣告與存取控制才會乾淨。

第二章：Azure VPN 基礎元件與配置概念

2.1 需要哪些 Azure 元件

站點到站點 VPN 常見的核心元件包含：

• Virtual Network（VNet）：用來承載部署的網路資源（可選，但通常存在）。
• Gateway Subnet：VNet 中專門用來配置 VPN Gateway 的子網。
• Local Network Gateway（本機網路閘道）：描述對端（辦公室或香港端）的公網 IP 與其內網前綴。
• Virtual Network Gateway（VPN 閘道）：Azure 端的 VPN 終止點。
• 連線（Connection）：把 Local Network Gateway 與 Virtual Network Gateway 綁起來並設定模式/共享金鑰。

概念很簡單：Azure 端要知道「對端在哪裡」與「對端聲稱能到哪些內網」。你的關鍵工作，就是把這兩件事準確填入。

2.2 路由模式：選擇你要的可控性

Azure企業實名帳號 站點到站點 VPN 的路由策略通常可分為「靜態」與「基於 BGP」。對大多數辦公室場景，靜態是可快速落地的起點；若網段變動頻繁、或未來要擴充多站點，BGP 會更彈性。

選擇原則：

• 靜態：設定簡單、可預期；但新增子網需要重新調整。
• BGP：可自動學習路由；適合多段互連或網段規模較大。

對「辦公室到香港伺服器」這種明確目的的需求，先用靜態路由建立通道，再視情況升級到 BGP，往往更省時。

2.3 加密與一致性：不要只改一半

VPN 的加密設定必須兩端一致，包括：

• IKE 版本（常見是 IKEv1 或 IKEv2，依環境支援而定）。
• 加密演算法（例如 AES-256）。
• 驗證演算法（例如 SHA-256）。
• Diffie-Hellman 群組。
• 共享金鑰或憑證（PSK 或證書）。

很多人設定失敗不是因為「壓根沒連上」，而是其中一個參數在某端沒對齊。你要有一個規則：Azure 端填什麼，就用同樣的值在辦公室端（或香港端）填什麼；差一個細節，就會變成隧道建立不起來。

第三章：建立「辦公室到香港」加密通道的實作流程

3.1 先確定端點：辦公室閘道的公網 IP 與香港網段

在 Azure 裡，Local Network Gateway 需要你提供：

• 對端公網 IP（辦公室出口或對端閘道的公共位址）。
• 對端內網前綴（例如辦公室內網 192.168.10.0/24）。

同理，如果你的設計是讓香港端作為另一個對端，你就需要針對香港那側建立相應的 Local Network Gateway，並在路由策略上確定包如何被導向。

此處要強調一點：VPN 不是「自動了解」你的世界。Azure 端不會知道香港內網在哪裡，除非你把香港的前綴以正確方式通告或在路由表中呈現。

3.2 建立 VNet 與 Gateway Subnet（Azure 端）

你至少需要一個 VNet（用於承載連線）。接著，在 VNet 內加入 Gateway Subnet，讓 VPN Gateway 可以部署。

實務注意事項：

• Gateway Subnet 的大小要符合 Azure 要求，且不要塞太多自訂設定。
• Gateway Subnet 與其他子網的規劃要避免混用造成後續管理困難。
• Azure企業實名帳號 若你已存在 VNet，請確認不會破壞現有服務的路由與安全策略。

3.3 設定 Virtual Network Gateway：指定類型與 SKU

Virtual Network Gateway 的類型（Vpn）、以及 SKU（影響吞吐能力與可用區域行為）需要你根據場景選擇。

建議思路：

• 若主要是資料庫或應用存取，選擇足夠吞吐的 SKU，避免未來上線後才發現效能不足。
• 若需要高可用，考量多區或冗餘設計，但這會影響部署複雜度。

你不必一開始就做到最極致，但至少要避免選得太保守導致日後重做。

3.4 設定 Local Network Gateway：對端前綴必須正確

Local Network Gateway 對端前綴可以是多條子網。關鍵是「你要宣告的是你希望透過 VPN 可到達的目的」。

Azure企業實名帳號 例如：

• 辦公室內網：192.168.1.0/24、192.168.2.0/24
• 香港伺服器：10.10.0.0/16（或特定 /32）

如果你宣告得太廣，可能導致不必要的流量進到 VPN；宣告得太窄，則通行不足。最理想的是以「業務必需」為範圍。

3.5 建立 Connection：PSK 與協定一致

Azure企業實名帳號 Connection 綁定 Azure 的 Virtual Network Gateway 與 Local Network Gateway。此處最常出錯的是 PSK 或加密協定不一致。

實作步驟：

• 先在辦公室端設備（或香港端）確認它支援的 IKE/加密組合。
• 在 Azure 端輸入相同的共享金鑰與協定。
• 建立連線後，觀察狀態是否進入「連線成功」或至少顯示協商完成。

如果你在協商初期就失敗，通常不是路由問題，而是加密/金鑰/端點 IP 不匹配。

第四章：路由與防火牆：讓「能連」變成「能用」

4.1 路由不是只有 VPN，還有裝置本身的路由

VPN 隧道建立成功，只代表「加密通道存在」，不代表「應用流量一定會走正確路徑」。因此你需要同時檢查：

• Azure 端的有效路由（Effective Route）是否把香港目的網段指向 VPN。
• 辦公室端閘道是否有到香港網段的路由（靜態或學習到）。
• 若有中間裝置（防火牆、UTM、三層交換器），它們是否也知道如何回送回來。

常見現象是：單方向通了（例如從辦公室 ping 香港成功），但回程失敗。那通常是「其中一端沒有正確回路由」或「回程被防火牆擋下」。

4.2 防火牆放行原則：以最小權限設計

Azure企業實名帳號 加密通道不等於允許所有流量。你仍需要在以下位置做安全策略：

• 辦公室端的防火牆/閘道：允許源辦公室網段到目標香港網段的必要埠與協定。
• Azure 中承載資源的安全組或網路安全規則（NSG/防火牆服務）：允許由 VPN 來源流入指定目的。
• 若香港端也有防火牆：同樣要允許來自辦公室（或 Azure 出口）的流量。

實務上，先用「ICMP 測試」驗證可達性，再逐步放行應用埠（例如 443、1433、3389、22）。這樣你能快速定位問題出在哪一段。

4.3 使用虛擬網路內路徑：避免不必要的暴露

如果香港伺服器是在 Azure 外部，你可能需要設定 Azure 中的路由，使其只把特定目的網段導向 VPN，而不是把整個網路（0.0.0.0/0）都丟進隧道。這樣做的好處是降低風險，並避免把無關流量帶進來導致效能下降。

第五章：驗證與測試：把風險降到最低

5.1 隧道狀態檢查：先看協商，再看資料平面

隧道建立與否是第一層。你要觀察的不只是「綠燈」，還包括協商細節是否正常。典型流程：

• 確認 IKE 協商成功。
• 確認 IPSec SA（安全關聯）已建立。
• 確認是否存在重建或錯誤協商的跡象。

如果隧道不穩定，通常與加密協定、PSK、端點 IP 變動、或 NAT 行為有關。

5.2 連通性測試：從網段到服務

建議用分層測試：

• 網段層：ping（或 traceroute/mtr）目的網段中的一兩個關鍵 IP。
• 端口層：telnet/nc 測試目標埠是否開放。
• 應用層：實際登入資料庫或 API 呼叫，確認應用層回應無被阻斷。

尤其要注意回程。可以先在辦公室端對香港伺服器做連線，再反過來測（若規劃允許），確認雙向路由都正確。

5.3 日誌與指標：用資料排除猜測

當你遇到失敗時，不要只看「是否連線」。你要用日誌、流量統計與錯誤碼去定位：

• Azure企業實名帳號 Azure 端：VPN Gateway 的連線狀態與診斷資訊。
• 辦公室端：IPSec/IKE 日誌（是否協商失敗、是否重建過多）。
• 防火牆端：是否有封包被拒絕，拒絕的規則是什麼。

很多案件最後都卡在「路由對了，但封包被安全策略擋下」。因此，你必須把日誌當成證據，而不是當成背景噪音。

第六章：常見失敗原因與解法（務實清單）

6.1 隧道建立失敗：金鑰、端點 IP、NAT

最常見原因：

• PSK 不一致：一個字母錯，全部無法協商。
• 端點公網 IP 填錯：Azure 設定的對端 IP 與設備實際對外位址不一致。
• NAT 行為：若辦公室閘道在 NAT 後對外位址會變，IPSec 可能反覆重建。

解法：

• Azure企業實名帳號 在兩端比對設定值（包含 IKE/加密組合）。
• 確保辦公室端對外位址穩定（固定公網 IP 或合理的轉換配置）。
• 必要時在閘道上固定 NAT 規則，避免變動。

6.2 隧道通了但服務連不上：路由與防火牆

若 VPN 隧道狀態顯示正常，卻無法連到香港服務，通常是：

• Azure 沒有正確路由到香港網段。
• 辦公室端或香港端沒有回程路由。
• NSG 或防火牆沒有放行該埠或來源。

解法：

• 用網段測試確認目的是否被導向 VPN。
• 逐步放行埠：先測 ICMP，再測 TCP/UDP 必需埠。
• 檢查安全策略是針對「來源 IP」與「目的 IP」正確規則生效。

6.3 延遲高或吞吐不足：協定/裝置與容量考量

延遲與吞吐不理想可能來自：

• VPN Gateway SKU 容量不足，或併發太高。
• 加密演算法太重（雖然安全，但效能要評估）。
• 辦公室側防火牆/路由器性能不足。

解法：

• 選用合適的加密組合（在合規前提下保持平衡）。
• Azure企業實名帳號 必要時升級 Gateway SKU 或調整架構。
• 在壓測前先找出瓶頸在哪一段（端點裝置 vs Azure 端）。

第七章：維運與擴充：把它做成「可長可久」

7.1 設定文件化：讓未來的人能接手

你在上線前做的每一步都要留下紀錄，至少包含：

• 兩端的 VPN 參數摘要（IKE/加密/PSK 經由安全方式存放）。
• 通告的網段清單與用途。
• 路由模式（靜態或 BGP）與目前採用的政策。
• 防火牆放行規則與變更日期。

沒有文件的 VPN，最終會變成「只能由原作者修」的系統，風險極高。

7.2 監控：從被動排錯到主動預警

你可以建立監控告警，例如：

• VPN 連線狀態是否頻繁重建。
• 特定服務端的可用性與延遲是否上升。
• 防火牆拒絕事件是否異常增加。

當你把這些納入運維流程，問題就不會只在使用者抱怨後才被發現。

7.3 未來擴充：新增子網或站點時怎麼做

一旦你需要擴充（新增香港子網或新增辦公室站點），最重要的是先更新「可達性範圍」的規劃：

• 新增的網段是否與既有網段重疊。
• 新增網段要不要改成 BGP 或保持靜態。
• 防火牆規則是否要同步更新。

務實做法是：每次擴充都用同一套測試流程驗證，避免只改一端導致不一致。

結語：安全通道的核心是「一致性」與「可驗證性」

建立跨國網路架構 Azure VPN 設定、建立辦公室到香港伺服器的加密通道，真正的難點不在於點按幾個選項，而在於整體的一致性：兩端的加密參數要一致、路由宣告要準確、回程與防火牆策略要同步。當你能用清楚的測試驗證每一層（隧道協商、網段通行、端口與服務），這條 VPN 才算是真正可用。

把需求先寫清楚，把網段規劃做乾淨，把每個設定對齊並留下文件，再用分層測試與日誌證據排錯。這樣你得到的不只是能連上的結果，而是一條能長期維運的加密通道。