AWS|Azure|GCP及國際版阿里雲/騰訊雲/華為雲全球六大雲廠商安全組與網絡配置保姆級教程

2026-05-22 阅读 22

在雲計算的宇宙里,有兩句被無數網絡工程師的眼淚浸透的至理名言:

「網絡沒通,大概率是路由或安全組沒開。」

「網絡被黑,大概率是安全組開了 0.0.0.0/0。」

作為出海業務、跨國架構或者多雲部署的IT人,每天打交道最多的就是各大雲廠商的網絡配置。很多人覺得不就是「點點鼠標開個端口」嗎? 但真正到了多雲架構下,你會發現每個大廠的管轄邏輯、術語甚至坑位都完全不同。 AWS 的有狀態安全組、Azure 的 NSG 優先級、GCP 的全局 VPC…… 只要一個細節沒吃透,輕則網絡不通排查到深夜,重則核心數據庫直接在公網「裸奔」。

今天這篇深度硬核長文,不講虛的 PPT 理論,直接復刻全網最全的六大海外主流雲廠商(AWS、azure、GCP、OCI、Alibaba Cloud International、Tencent Cloud International)的網絡拓撲與網絡防火牆(安全組)的「保姆級」實操指南。建議收藏,關鍵時刻這就是你的網絡排查排障手冊。

一、核心概念對齊:別被大廠的黑話繞暈了

在正式敲鍵盤之前,我們必須先把六大廠商的「黑話(術語)」拉到同一個維度。雖然叫法千奇百怪,但底層邏輯無非是三樣東西:

私有網絡(坑位)、路由器/路由表(路標)、防火牆(門衛)

。

雲廠商

私有網絡 (VPC/VNet)

子網 (Subnet)

狀態防火牆 (安全組/組件)

Subnet/網絡級防火牆

亞馬遜網路服務

VPC (區域級)

Subnet (可用區級)

Security Group (有狀態)

Network ACL (無狀態)

阿茲ure

VNet (區域級)

Subnet (子網)

Network Security Group (NSG)

同樣使用 NSG 綁定子網

GCP

VPC (全局/Global)

Subnet (區域級)

VPC Firewall Rules (有狀態)

標籤/服務賬號組合控制

Oracle (OCI)

VCN (區域級)

Subnet (區域/可用區)

Security List / NSG

Security List (組件級)

阿里雲國際

VPC (區域級)

VSwitch (可用區級)

安全組 (Security Group)

網絡ACL (Network ACL)

騰訊雲國際

VPC （區域級）

子網路（可用區級）

安全組（Security Group）

網路ACL （Network ACL）

核心底層邏輯:有狀態(Stateful) vs 無狀態(Stateless)

這是新人最容易栽跟頭的地方:

有狀態(Security Group / 防火牆規則): 你進來了,我就默認讓你出去。比如你允許了外部 80 端口訪問,那麼服務器響應 80 端口回包時,不需要在出站規則里額外開闢隨機高端口。

無狀態(Network ACL / 某些特定路由): 進出分明,各走各路。你開了進站 80 端口,如果出站規則沒開 1024-65535 的臨時端口(Ephemeral Ports),流量依然死在半路上。

二、詳解六大海外大廠:實操與避坑指南

1. AWS (Amazon Web Services):老大哥的「雙層防禦」

AWS 的網絡設計極其經典,也是很多雲廠商模仿的對象。它的核心思維是:

區域級 VPC 劃分為不同的可用區(AZ)子網,再用無狀態的 NACL 守住子網大門,最後用有狀態的 Security Group(安全組)守住實例房門。

🛠��️ 黃金配置路徑:

創建自定義 VPC:千萬別貪省事用 Default VPC,自己規劃網段(例如 10.0.0.0/16)。

切分子網:至少劃分為 Public Subnet(關聯了 Internet Gateway,有公網路由)和 Private Subnet(沒有公網路由,僅通過 NAT Gateway 出網)。

安全組配置:入站(Inbound):精準開放。例如 Web 服務器只開 80 和 443,源地址設為 0.0.0.0/0 或 ALB(負載均衡)的安全組 ID。出站(Outbound):默認是 0.0.0.0/0 允許所有,如果合規嚴苛,需要限制為特定的私網網段。

⚠��️ AWS 避坑血淚史:

安全組引用: 別總傻傻地寫 IP 地址! AWS 安全組最強的功能是「源地址可以填寫另一個安全組 ID」。這意味著,你可以設置「只有後端安全組 B 允許接收來自前端安全組 A 的流量」,任憑前端 EC2 怎麼彈性伸縮、IP 怎麼變,網絡邏輯固若金湯。

NACL 默認規則: 自定義 NACL 默認是 Deny All。如果你建了自定義 NACL

又忘了加規則,整個子網瞬間變成網絡孤島。

2. Microsoft Azure:優先級至上的「安全組組長」

微軟的 Azure 稱私有網絡為

VNet

。 Azure 在安全控制上的邏輯和 AWS 有一點根本性的不同:它的

NSG(Network Security Group)

既可以綁定在網卡(NIC)上,也可以綁定在子網(Subnet)上。而且,Azure 引入了優先級(Priority,100-4096)的概念。

🛠黃金配置路徑：

創建 VNet 與 Subnet:Azure 的 Subnet 不綁定可用區,它是區域級的,這讓高可用部署更靈活。

配置 NSG 規則:規則數字越小,優先級越高。進站(Inbound): 允許管理員從特定 IP 訪問 22/3389,優先級設為 100;允許 HTTP/HTTPS,優先級設為 200;其餘默認。

⚠��️ Azure 避坑血淚史:

默認的三大隱藏規則: azure 的 NSG 底部自帶三個默認規則(你刪不掉,只能用更高優先級覆蓋):AllowVnetInBound:VNet 內部所有子網默認互通! AllowAzureLoadBalancerInBound:允許 Azure 探針。 DenyAllInBound:阻斷其餘所有。很多小白以為劃分了不同子網就隔離了,結果發現開發環境直接摸到了生產環境的數據庫,就是因為沒有顯式寫一條高優先級的 Deny 規則阻斷跨子網通信。

3. GCP (Google Cloud Platform):打破常理的「全局網絡」與「標籤大師」

谷歌雲(GCP)的網絡架構在六大廠里是最特立獨行的。

它的 VPC 是 Global(全局)的,不屬於某個特定區域(Region)。

只要你在一個 VPC 里,全球各地的子網默認通過谷歌的內網骨幹網互通。

更絕的是,GCP

沒有傳統意義上綁定網卡或子網的安全組

。它用的是

防火牆規則(Firewall Rules) 網絡標籤(Network Tags)或服務賬號(Service Accounts)

。

🛠黃金配置路徑：

定義網絡標籤:比如給你的虛擬機打上標籤 http-server 或 backend-db。

編寫防火牆規則:創建一條規則:「允許流量進來,目標端口 80,443」。目標(Targ

Et): 選擇「指定的網絡標籤(Specified target tags)」,填入 http-server。源(Source): 填入 0.0.0.0/0。

⚠��️ GCP 避坑血淚史:

標籤拼寫錯誤: 標籤是一個純文本字符串。如果你在虛擬機上打的標籤是 web-server,但在防火牆規則里手抖打成了 web_server(下劃線變連字符),谷歌沒有任何糾錯提示,你的服務就永遠在公網消失了。

默認拒絕 vs 默認允許: GCP 默認會創建一些 default-allow-internal 規則。如果你用的是默認網絡,全球所有區域的機器默認都能互相 Ping 通,記得在生產環境中精簡這些規則。

4. OCI (Oracle Cloud Infrastructure):嚴苛到極致的「默認拒絕」

甲骨文雲(OCI)這幾年因為各種高性價比的免費套餐和強勁的硬件異軍突起。 OCI 的網絡叫

VCN(Virtual Cloud Network)

。它的安全邏輯結合了 AWS 和 Azure 的特點,擁有

Security List(安全列表,子網級)

和

Network Security Group(NSG,網卡級)

。

🛠黃金配置路徑：

創建 VCN:推薦使用「VCN Wizard」,它會自動幫你把 Internet Gateway、NAT Gateway、路由表全部配齊,省去手工關聯的痛苦。

選用 NSG 代替 Security List:OCI 官方目前更推薦使用 NSG,因為安全列表是應用到整個子網的,粒度太粗。

添加入站規則:OCI 的規則界面非常直觀,選擇 Stateless(無狀態)或有狀態,指定 TCP 協議和端口。

⚠��️ OCI 避坑血淚史:

鐵壁江山,默認全關: OCI 的初始嚴苛程度是各大雲廠商之最。即便你創建虛擬機時分配了公網 IP,並且在控制台里把 NSG 開到了最大(0.0.0.0/0 允許所有),你大概率還是連不上機器。

系統內部防火牆(Ubuntu/Oracle Linux): 這是 OCI 最著名的巨坑! 它的官方鏡像內部(操作系統的 iptables 或 ufw)默認把所有入站流量都阻斷了。你必須 SSH 進去(如果能進),或者在初始化腳本(Cloud-init)里執行清空 iptables

的命令,外面的流量才能真正進來。

5. 阿里雲國際版 (Alibaba Cloud International):對大流量和高並發的高效收攏

阿里雲國際版的網絡設計(VPC)和安全組在邏輯上和 AWS 非常相似,但在管理複雜性上做了很多本地化和亞洲開發者的習慣優化。它的安全組分為

普通安全組

和

企業級安全組

。

🛠黃金配置路徑：

創建專有網絡 VPC 與交換機(VSwitch):注意,阿里雲的子網叫交換機(VSwitch)。

選擇安全組類型:普通安全組: 組內實例默認互通,單組支持實例較多。企業級安全組: 組內實例默認隔離,安全性極高,適合金融、電商等生產環境。

規則授權: 支持「地址段訪問」和「安全組組組互訪」。

⚠��️ 阿里雲國際版避坑血淚史:

ICMP(Ping)默認不通: 新手建完 ECS 實例後,習慣性地在本地 Ping 一下公網 IP,發現不通就以為網絡掛了。其實阿里雲國際版的默認安全組規則里往往沒有放行 ICMP 協議。去安全組裡加一條「協議類型:ICMP」就能解決。

出方向的攔截: 阿里雲對一些特定端口(如郵件常用的 25 端口)在網絡底層做了全局封禁。如果你要在雲上搭建自建郵件服務器,必須提交工單單獨申請解封,在安全組裡開通是沒用的。

6. 騰訊雲國際版 (Tencent Cloud International):極簡流線型與精細化管理

騰訊雲國際版(Tencent Cloud)的網絡架構同樣基於 VPC。它的安全組設計非常強調「可讀性」

和

「模板化」。你可以創建幾個標準的安全組模板(如「通用 web 服務器模板」、「數據庫只允許內網模板」),然後一鍵綁定到不同的實例上。

🛠黃金配置路徑：

創建 VPC 與子網。

利用安全組實例關聯:騰訊雲支持一張網卡綁定多個安全組。

規則生效順序: 從上到下,一旦匹配成功就不再往下匹配(類似於 Azure 和傳統防火牆的邏輯,這一點與 AWS 所有規則取並集不同)。

⚠��️ 騰訊雲國際版避坑血淚史:

多安全組疊加時的「覆蓋效應」: 因為騰訊雲的一台 CVM 實例可以綁定多個安全組,而它的規則是按順序匹配且單個組內有拒絕/允許之分。如果你不小心把一個帶有「Deny All」的安全組挪到了最上面,下面所有精心配置的「Allow」規則都會瞬間失效。

三、高階

架構避坑:多雲網絡配置的通病與解法

當你成為架構師,需要在一個項目里同時調度上述幾家廠商時,真正的挑戰才剛剛開始。

1. 跨雲連接的「MTU 懸崖」

當你用 VPN 或者專線把 AWS VPC 和 Azure VNet 連起來的時候,經常會遇到一個詭異的現象:

小流量的 Ping、SSH 很順暢,但一傳輸大文件或跑大 SQL,連接就會無故斷開(Timeout)。

原因: 各大廠商底層的網絡封裝不同,導致MTU(最大傳輸單元)不一致。 AWS 默認可能是 9001(巨型幀)或 1500,而經典 VPN 的 MTU 必須是 1420 或 1350。

解法: 務必在兩端的虛擬機或路由器上開啟 MSS Clamping(MSS 鉗製),或者手動將實例網卡的 MTU 調低到 1420。

2. 多雲互聯的網段重疊(Overlap)

在規劃網絡之初,就要死死記住:

絕對不要在任何地方使用重複的本地網段。

如果你把 AWS 設為 10.0.0.0/16,Azure 也設為 10.0.0.0/16,當業務發展需要打通跨雲對等連接(VPC Peering/Transit Gateway)時,你只能徹底推倒重來。最好的做法是按廠商和業務線嚴格劃分:

AWS 生產:10.1.0.0/16

Azure 生產:10.2.0.0/16

GCP 生產:10.3.0.0/16

四、總結:雲上網絡的「四大軍規」

不管你用的是哪家雲,通往優秀網絡架構師的道路上都有四條通行的軍規:

最小權限原則: 能開 /32(單IP)絕不開 /24(網段),能開 /24 絕不開 0.0.0.0/0。入站嚴管,出站精細: 限制內網核心數據庫、中間件的出網權限。即使黑客通過 Web 漏洞拿到了服務器的 Webshell,由於出站阻斷,他也無法把木馬下載進來,更無法把數據外傳(C2 回連失敗)。動用基礎設施即代碼(IaC): 超過10個安全組規則時,人類的肉眼和記憶力就不再可靠。用 Terraform 或 Pulumi 來管理你的網絡,讓每一次安全組的變更都有跡可循、代碼化評審。別忘了系統層: 當網絡不通時,排查順序永遠是:本地服務監聽狀態 -> 操作系統內核防火牆(iptables/ufw/Windows Firewall) -> 雲廠商安全組 -> 雲廠商子網ACL/路由

表。

掌控了這六大廠商的網絡配置底座,你就拿到了多雲架構演進的入場券。面對複雜的跨國出海業務,你也能氣定神閒地在鍵盤上敲下:Connection Allowed。