網路安全排錯與可達性分析

什麼是網路安全排錯與可達性分析？

AWS 的網路安全排錯是一門有紀律的學科：拿到一個症狀——「應用程式無法連到資料庫」、「Inspector 回報某台 EC2 可以從網際網路存取，但我們以為它是私有的」、「我們網域的 DNS 查詢量突然飆升」——然後用正確的 AWS 分析器服務與日誌來源組合，找出根本原因，而不是靠猜的。SCS-C02 考試的 Task 3.4 明確測試網路安全排錯與可達性分析，因為安全工程師（不只是網路工程師）必須能夠診斷某個安全管控為何如預期般運作或未如預期般運作。網路安全排錯也是 Domain 3 其他所有主題匯集的地方——security group、NACL、AWS Network Firewall、Transit Gateway、Inspector——如果你無法診斷一個行為異常的管控，就無法證明工作負載真的受到保護。

AWS 原生的網路安全排錯工具箱比多數工程師意識到的還要龐大。你有三種可達性分析器（VPC Reachability Analyzer、Network Access Analyzer、Inspector Network Reachability）、三條日誌流（VPC Flow Logs、WAF logs、Route 53 Resolver 查詢日誌）、一種封包擷取機制（Traffic Mirroring），以及多種日誌查詢介面（CloudWatch Logs Insights、Athena、Security Hub）。每個工具回答的問題形狀不同，SCS-C02 考試最愛測試你能否在第一眼看到題目時就把問題對應到正確的工具。本指南提供那棵決策樹，以及你需要有把握地使用這棵樹的 TCP/IP 基礎知識。

本主題端到端涵蓋 Task 3.4：你將建立「症狀對應工具」的診斷決策樹、學習每種可達性分析器如何構建答案、深入研究 VPC Flow Logs 的拒絕代碼（BLACKHOLE_ROUTE、ENI_SECURITY_GROUP_RULES_DENY、NACL_RULES_DENY）、複習 TCP/IP 基礎包括 ephemeral port 與路徑 MTU 探索，以及了解用於完整封包擷取的 Traffic Mirroring。讀完本指南，SCS-C02 上的網路安全排錯情境題應該會變得機械化：你讀症狀、挑工具、解讀輸出、選出正確答案。

為什麼 SCS-C02 重視網路安全排錯

Task 3.4 佔 Domain 3 相當大的比重（考試 20%），是整份 SCS-C02 藍圖中最「工程師風格」的任務。Tasks 3.1、3.2 和 3.3 要你設計管控，Task 3.4 要你診斷已部署的管控。題目讀起來像工單描述：開發人員說 Lambda 無法連到 RDS、稽核人員標記某個 S3 bucket 為全世界可讀、Inspector 掃描說某台本不該如此的 instance 是可達的。你的工作是選出正確的可達性分析器或日誌來源。

網路安全排錯主導 Task 3.4 的第二個原因，是 AWS 專門釋出了幾款分析器（2021 年的 Network Access Analyzer、Inspector V2 網路可達性、2022 年的 Reachability Analyzer 跨帳號功能），以取代臨時拼湊的 shell 腳本和一連串 aws ec2 describe-* 指令。考試測試你是否知道這些工具的存在，並能選對——對每個網路問題都回答「在 instance 上跑 tcpdump」的考生，會輸給回答「使用 Reachability Analyzer，在來源 ENI 和目的地 ENI 之間追蹤路徑」的考生。

診斷決策樹——症狀對應工具

網路安全排錯中最值得測試的技能，就是把症狀對應到正確的工具。在設計逐路徑機制之前，先把這棵樹內化。

「A 現在能不能連到 B？」→ VPC Reachability Analyzer

當題目給你一個特定的來源 ENI 和一個特定的目的地（ENI、internet gateway、transit gateway attachment、VPC endpoint），並問路徑是否通暢，使用 VPC Reachability Analyzer。它建立一個封包會經過的每個 security group、NACL、route table、peering 連線和 TGW route 的模型，然後告訴你「可達」並附上路徑，或「不可達」並指出確切的阻斷元素。

「誰有可能存取我的敏感資源？」→ Network Access Analyzer

當題目詢問一組資源的意外暴露（例如，「找出 production VPC 中所有網際網路主機可以在 TCP/22 上存取的 EC2」），使用 Network Access Analyzer。它執行一個 Network Access Scope（預期路徑的 JSON 允許清單），並標記出每條違反 scope 的實際路徑。

「即使目前沒有流量，這台 EC2 是否可以從外部存取？」→ Inspector Network Reachability

當題目是弱點掃描類型——「Inspector 回報 instance 可在 port 3306 被存取，但我已打上修補程式」——使用 Inspector Network Reachability。它將 instance OS 上的開放 port 偵測與來自網際網路（或來自 peered VPC）的可達性檢查結合，也就是餵入 Security Hub 關於暴露運算資源的發現的來源。

「連線 timeout 了——為什麼？」→ VPC Flow Logs ACCEPT/REJECT

當題目是關於實際的 TCP/UDP 失敗——timeout、RST、連線緩慢——查看 VPC Flow Logs。看 action 欄位（ACCEPT 或 REJECT），如果有的話，還有 v5 的新欄位如 pkt-srcaddr/pkt-dstaddr，以便觀察非對稱路由或 NAT 行為。

「Layer 7 攻擊模式」→ WAF logs 搭配 Athena 查詢

當題目涉及 CloudFront/ALB/API Gateway 上的 HTTP 層攻擊（SQLi、XSS、惡意爬蟲），答案是 AWS WAF logs 傳送至 S3 並用 Athena 查詢，或傳送至 CloudWatch Logs 並用 Logs Insights 分析。

「懷疑有 DNS 外洩」→ Route 53 Resolver 查詢日誌

當題目提到 DNS tunneling、command-and-control，或異常長的子網域查詢，你需要 Route 53 Resolver 查詢日誌，通常會與 GuardDuty 的 Backdoor:EC2/C&CActivity.B!DNS 發現相關聯。

「我需要用於鑑識的原始封包擷取」→ Traffic Mirroring

當題目明確要求封包擷取（PCAP），或提到超出 flow log 揭露範圍的 L4–L7 檢查，答案是 VPC Traffic Mirroring，傳送至 NLB 前置的安全設備或另一個 ENI。

白話文解釋

如果你第一次接觸網路安全排錯，三個生活化的類比可以幫你把這些工具的差異記住，考試時看到情境題立刻反射答案。

類比一：急診室的三種診斷儀器——對應三種不同的問題 急診室有 X 光、超音波、核磁共振三種儀器，差別不是哪個比較高級，而是回答的問題不同。X 光（Reachability Analyzer）只看「這一段骨頭到那一段骨頭之間有沒有斷」——明確的點對點問題；超音波（Network Access Analyzer）做全身掃描找隱藏的病灶——「整個 production VPC 裡有沒有任何 instance 能被 internet 在 22 port 摸到」；核磁共振（Inspector Network Reachability）專門看軟組織，把 OS 層面的開 port 跟網路路徑結合在一起判斷。網路安全排錯是看症狀派儀器，跟急診醫師看症狀開檢查單一樣，派錯就找不到病灶。

類比二：機場安檢——不同層的記錄不同事情 機場有四種記錄：閘門刷卡紀錄（VPC Flow Logs，誰在哪個門被擋下/放行）、X 光行李掃描紀錄（WAF logs，HTTP 內容檢查）、廣播系統電話查詢紀錄（Route 53 Resolver 查詢日誌，DNS 查詢）、CCTV 錄影（Traffic Mirroring，原始畫面）。當你被問「這位旅客是怎麼進來的？」要先確定你需要的是哪一層證據。Flow Logs 告訴你他刷了哪個門但不知道帶什麼；WAF logs 告訴你他行李裡有什麼但不知道他在哪一個閘口；Traffic Mirroring 是最高解析度但儲存最貴。SCS-C02 的網路安全排錯題目經常考你「成本最低且能達成目的」，不是無限選 CCTV。

類比三：偵探辦案——Reachability Analyzer 像是路線重建 偵探有幾種辦案方法：1) 拿著一個明確的「嫌疑人從 A 到 B 走哪條路」假設，去比對監視器（Reachability Analyzer 一對一）；2) 列出所有「可能進入案發地點的路徑」做地毯式搜索（Network Access Analyzer 做 scope）；3) 看法醫報告找出毒物來源（Inspector 從 instance 倒推）；4) 翻通聯紀錄（Flow Logs）；5) 翻網路發文紀錄（WAF logs）；6) 翻電話查詢紀錄（Resolver logs）；7) 拿到完整 CCTV 影像（Traffic Mirroring）。考試考你選對辦案手法，不是同時用全部，因為時間和預算有限。

每位 SCS-C02 考生必須複習的 TCP/IP 基礎

沒有 TCP/IP 基礎就無法做網路安全排錯。SCS-C02 的題目常常取決於你是否記得 NACL 是無狀態的且需要 ephemeral port 範圍，或路徑 MTU 探索需要 ICMP type 3 code 4 能夠穿過防火牆。

TCP vs UDP 以及有狀態 vs 無狀態

TCP 是連線導向的（三向交握 SYN → SYN/ACK → ACK、序列號、重傳）。UDP 是無連線的，沒有確認機制。Security group 是有狀態的——即使沒有明確的輸出規則，返回流量也會自動被允許。NACL 是無狀態的——兩個方向都必須被允許，包括回應端的 ephemeral port 範圍。這個單一區別是 SCS-C02 所有 Layer 4 細節中造成最多錯誤答案的原因。

Ephemeral Port——NACL 陷阱

當 IP 為 10.0.1.5 的客戶端開啟一個到伺服器 :443 的 TCP 連線時，OS 會從一個範圍中挑選一個 ephemeral 來源 port——Linux 是 32768–60999，Windows 是 49152–65535，AWS NLB 是 1024–65535。伺服器的回應傳回該 ephemeral port。如果伺服器子網路的 NACL 只允許輸出到 :80/:443，而不允許 ephemeral port 範圍，回應會被靜默丟棄，客戶端看到的是 TCP timeout。SCS-C02 最愛這個陷阱。

OSI 模型考試快速參考

• L3（網路層）— IP、route table、NACL、network ACL
• L4（傳輸層）— TCP/UDP、security group、AWS Network Firewall 無狀態規則
• L7（應用層）— HTTP、AWS WAF、AWS Network Firewall 有狀態 Suricata 規則、Application Load Balancer

MTU 與路徑 MTU 探索

VPC 內部的預設 MTU 是 1500 bytes；jumbo frame（9001）在 placement group 或單一子網路內有效，但跨 VPC peering 或 transit gateway 不行。當 fragment 被靜默丟棄時，應用程式會在剛好 1500 bytes 的 payload 時卡住——這是過度嚴格的 NACL 或 AWS Network Firewall 規則丟棄 ICMP Destination Unreachable / Fragmentation Needed 的典型症狀。修復方式是明確允許 ICMP type 3 code 4。

VPC Reachability Analyzer 深度剖析

VPC Reachability Analyzer 是網路安全排錯的精準手術刀。給定一個來源資源、一個目的地資源、一個可選的協定（TCP 或 UDP），以及一個可選的目的地 port，它會追蹤封包穿越 VPC 資料平面的完整路徑，並告訴你封包是否會被傳遞。

支援的來源與目的地

來源：instance、ENI、internet gateway、VPC endpoint（interface 或 gateway）、TGW attachment、VPN gateway。目的地：相同集合加上 VPC 內部的 IP 位址。跨帳號、跨 VPC、跨區域（自 2022 年起）在兩個帳號都在同一個 AWS Organization 時受到支援。

分析器評估的內容

對每個 hop，Reachability Analyzer 評估：來源 security group 輸出、來源子網路 route table、來源 NACL 輸出、中間的 peering/TGW route table、目的地 NACL 輸入、目的地 security group 輸入、返回路徑的目的地 route table。如果路徑失敗，回應包含說明類型（SECURITY_GROUP_NO_RULE、NACL_NO_RULE、NO_ROUTE、BLACKHOLE_ROUTE 等）以及確切的阻斷資源 ID。

Reachability Analyzer 不評估的內容

這是考試的重點。Reachability Analyzer 是控制平面模擬器。它不測試：

• 應用層可達性（即使網路路徑是通的，應用程式也可能掛了）
• DNS 解析（它使用 IP 運作，不使用 hostname）
• AWS Network Firewall 有狀態規則（它評估無狀態規則，但只將有狀態規則標記為「可能被封鎖」）
• WAF 規則
• 作業系統防火牆（iptables、Windows Firewall）

定價與執行頻率

每次路徑分析費用 $0.10。你可以儲存路徑並透過 Lambda 或 EventBridge 按排程重新執行，以實現持續合規——適合在每次部署前證明「資料庫層無法從網際網路存取」。

Network Access Analyzer 用於集合對集合的暴露分析

AWS Network Access Analyzer 是 Reachability Analyzer 的以 scope 為基礎的兄弟。Reachability Analyzer 回答「路徑 A→B 是否可行？」，Network Access Analyzer 回答「在我的整個帳號中，有哪些路徑符合我的 Network Access Scope 定義？」

Network Access Scope JSON

scope 是一個 JSON 文件，包含 MatchPaths（你想找到的路徑）和 ExcludePaths（你接受的路徑）。範例：「找出從任何 internet gateway 到 prod-data VPC 中任何 EC2 在 TCP/3306 上的每條路徑，除了終止於 bastion ENI 的路徑。」分析器爬取每個 SG、NACL、route table、peering、TGW route、VPC endpoint 和 PrivateLink 連線，並列出每條符合的實際路徑。

AWS 提供的範例 Scope

AWS 附帶了幾個涵蓋常見稽核問題的預建 scope：「從 internet 到 VPC 的所有路徑」、「從 VPC 到 internet 的所有路徑（潛在資料外洩）」、「受信任與不受信任 VPC 之間的所有路徑」。大多數關於「意外網際網路暴露」的 SCS-C02 情境都對應到 AWS 提供的「Internet to VPC」scope——知道這一點可以在考試中節省時間。

成本與執行頻率

Network Access Analyzer 依每次分析執行中分析的 ENI 計費（每個 ENI $0.002）。透過 EventBridge 每週執行一次作為合規報告的一部分；結果透過自訂整合與 Security Hub 整合。

Inspector Network Reachability——運算加網路

Amazon Inspector v2 的網路可達性規則套件之所以獨特，是因為它將 OS 層的資訊（instance 實際上監聽哪些 port）與 VPC 層的可達性（這些 port 是否可以從網際網路、peered VPC 或只能從同一子網路存取）合併在一起。

Inspector Network Reachability 的運作方式

Inspector 透過 SSM 讀取 instance 的 netstat 等效狀態，識別監聽中的 port，然後追蹤每個 port 的 VPC 可達性。發現的嚴重程度與暴露程度相關——「port 22 可從 0.0.0.0/0 存取」是 HIGH，「port 22 可從 peered VPC 存取」是 MEDIUM，「port 22 只能從同一子網路存取」是 INFORMATIONAL（或沒有發現）。

何時用 Inspector vs Reachability Analyzer

當題目是「告訴我我的 EC2 機群中哪些被暴露以及在哪些 port 上」——Inspector 持續掃描你的整個機群，使用 Inspector。當你有一個特定的可疑路徑並想知道它為何有效或失敗，使用 Reachability Analyzer。兩者是互補的：Inspector 告訴你什麼是暴露的，Reachability Analyzer 告訴你為什麼。

發現傳送至 Security Hub

所有 Inspector 發現都透過 ASFF 流入 Security Hub，因此一條 EventBridge 規則可以將 Severity.Label = HIGH 的 Inspector 網路可達性發現路由到隔離 runbook（例如，透過 SSM Automation 附加隔離 SG）。

VPC Flow Logs——鑑識主力工具

VPC Flow Logs 擷取 VPC 中網路介面進出 IP 流量的元資料。對於間歇性或部分失敗的網路安全排錯，它是最重要的單一日誌來源。

格式與版本

Flow Logs 有 v2（預設）、v3、v4、v5（最新）。v5 新增關鍵欄位 pkt-srcaddr、pkt-dstaddr、traffic-path 和 flow-direction，讓你區分「封包從網際網路進入 ENI」和「封包從 peered VPC 進入」。對於 SCS-C02 排錯，一律使用自訂格式啟用 v5，並包含 tcp-flags，以便看出純 SYN flood 與完整交握的區別。

REJECT vs ACCEPT 解碼

action 欄位是 ACCEPT 或 REJECT。REJECT 可能來自 security group、NACL，或缺少路由。要區分：

• ENI_SECURITY_GROUP_RULES_DENY（在 v5 log-status 欄位）——security group 封鎖
• NACL_RULES_DENY——NACL 封鎖（帶有無狀態特性：你可能看到請求通過但回應被 REJECT，這就是 ephemeral port 症狀）
• BLACKHOLE_ROUTE——目的地的 route table 沒有路由，或有明確的 blackhole

一個微妙的模式：如果你在一個方向看到 ACCEPT，但沒有對應的返回封包，返回路徑是壞的——通常是目的地 table 中缺少路由，或透過 TGW 的非對稱路由。

Flow Logs 的傳送目的地

三個目的地：CloudWatch Logs（適合即時告警）、S3（廉價長期儲存，用 Athena 查詢）、Amazon Data Firehose（即時串流至 SIEM）。對於 SCS-C02，S3 + Athena 是鑑識查詢的成本效益預設；CloudWatch Logs Insights 用於延遲低於一分鐘的即席操作搜尋。

常見調查的 Athena 查詢

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpcflow
WHERE action = 'REJECT' AND dstport IN (22, 3389)
  AND day BETWEEN '2026/04/20' AND '2026/04/25'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC LIMIT 50;
-- 找出 top-50 被拒絕的 SSH/RDP 探測——SCS-C02 事件分類的基本查詢

VPC Flow Logs 不擷取的內容

考試的關鍵：Flow Logs 不擷取 (a) 往返 instance metadata service（169.254.169.254）的流量，(b) DHCP 流量，(c) 往返 Amazon DNS 伺服器的流量，(d) 往返 Windows 授權啟用伺服器的流量，(e) 同一網路介面中 ENI 之間的流量。DNS 調查請使用 Route 53 Resolver 查詢日誌。IMDS 濫用偵測請使用 GuardDuty。

Traffic Mirroring 用於封包擷取

VPC Traffic Mirroring 複製來自 ENI 的網路流量，並將其傳送至目標 ENI 或 NLB 前置的安全設備。它是網路安全排錯的封包層級工具——當 Flow Logs 沒有提供足夠細節時使用。

Filter 與 Session 模型

mirror filter 是一組無狀態規則（協定、來源 CIDR、目的地 CIDR、來源 port、目的地 port），描述要鏡像哪些封包。mirror session 綁定一個來源 ENI、一個目標（ENI 或 NLB）、一個 filter，以及一個用於排序的 session 號碼。你可以鏡像輸入、輸出或兩個方向，擷取的封包用 VXLAN 封裝，目標因此能看到完整的原始標頭。

支援的來源 Instance

Traffic Mirroring 支援基於 Nitro 的 EC2 instance（M5/M6/C5/C6/R5/R6/T3/T4 及類似型號）。不支援基於 Xen 的舊型（M3/M4/T2）。考試情境說「舊有機群運行 M4 instance」時，Traffic Mirroring 就不是答案。

效能影響

鏡像流量消耗 ENI 頻寬——來源和目的地都會。AWS 建議對高吞吐量工作負載只鏡像取樣（例如，每十個流鏡像一個）。mirror filter 可以只針對特定 port（TLS 交握、可疑目的地）以保持合理的流量量。

SCS-C02 上的使用案例

三個典型使用案例：

1. 主動事件期間的鑑識封包擷取——搭配隔離 VPC 上的 Suricata 或 Zeek IDS。
2. 特定 port 上未加密輸出的 DLP 檢查。
3. 合規示範——透過擷取 TLS 交握並顯示沒有明文，證明到受管制工作負載的流量已加密。

Route 53 Resolver 查詢日誌用於 DNS 鑑識

Route 53 Resolver 查詢日誌記錄 VPC 資源透過 Amazon Resolver（AmazonProvidedDNS 或 .2 resolver）發出的每次 DNS 查詢。當症狀是 DNS 相關時——透過長子網域查詢的外洩、command-and-control 信標、或網域 typosquat 流量——它們對網路安全排錯至關重要。

日誌目的地與格式

Resolver 查詢日誌傳送至 CloudWatch Logs、S3 或 Data Firehose。每筆記錄包含來源 ENI、來源 VPC、查詢名稱（FQDN）、查詢類型（A、AAAA、TXT 等）、回應代碼（NOERROR、NXDOMAIN、SERVFAIL），以及回應的 resolver endpoint。將日誌與 GuardDuty 的 DNS 類發現配對，例如 Backdoor:EC2/C&CActivity.B!DNS 和 Trojan:EC2/DNSDataExfiltration，可得到高可信度偵測。

跨帳號匯總

在 AWS Organizations 層級設定 Resolver 查詢日誌記錄，並傳送至中央 S3 bucket；然後用 Athena 查詢。SCS-C02 明確測試組織層級的日誌匯總模式。

Resolver 查詢日誌看不到的內容

• 繞過 Amazon Resolver 的查詢（直接使用 8.8.8.8 等公共 DNS 的 instance）
• 透過 peering 連線到另一個 VPC 中的 DNS 伺服器的查詢，而不使用 Resolver

對於繞過 DNS 的考試情境，答案是透過 Route 53 Resolver DNS Firewall 的輸出 DNS 防火牆規則強制使用 Amazon Resolver，阻斷對非 AWS resolver 的 TCP/UDP 53 輸出。

WAF Logs 與 Athena 用於 Layer 7 調查

AWS WAF logs 擷取每次 Web ACL 評估：哪條規則命中、採取了什麼行動（ALLOW、BLOCK、COUNT、CAPTCHA、CHALLENGE）、請求 URI、標頭，以及命中的規則 ID。它們是 Flow Logs 的 L7 對應物。

日誌目的地

WAF 可以將日誌傳送至 CloudWatch Logs、S3 或 Amazon Data Firehose。對於長期存檔和 Athena 查詢，S3 是標準模式。CloudWatch Logs Insights 適合調查進行中攻擊時的過去幾小時資料。

Athena 查詢模式

典型的 SCS-C02 情境要求你識別某個時間窗口內被封鎖的 SQLi 嘗試的前幾名來源 IP：

SELECT httprequest.clientip AS ip, COUNT(*) AS blocks
FROM waf_logs
WHERE action = 'BLOCK'
  AND terminatingruleid LIKE '%SQLi%'
  AND from_unixtime(timestamp/1000) >= TIMESTAMP '2026-04-25 00:00:00'
GROUP BY httprequest.clientip
ORDER BY blocks DESC LIMIT 10;

關聯 WAF、Flow Logs 和 CloudFront Logs

Layer 7 攻擊通常有 L3/L4 特徵。WAF 封鎖了 99% 的 SQLi 嘗試但剩餘 1% 成功的情境，可能需要關聯 WAF logs（攻擊模式）、CloudFront access logs（快取和 origin 行為）和 ALB access logs（origin 回應代碼）。SCS-C02 有時問「團隊需要確認任何 SQLi 是否到達 origin」——答案是關聯所有三個日誌來源。

CloudWatch Logs Insights——操作夥伴

CloudWatch Logs Insights 讓你使用專用查詢語言對 CloudWatch Logs 執行即席查詢。當 Flow Logs、WAF logs 或 Resolver logs 正在串流至 CloudWatch Logs，而你需要在接下來三十秒內得到答案時，它是快速選項（低於一分鐘）。

網路安全排錯的常見 Insights 查詢

用於找出過去一小時被拒絕的 SSH 嘗試的標準查詢：

fields @timestamp, srcaddr, dstaddr, dstport, action
| filter dstport = 22 and action = "REJECT"
| stats count() as hits by srcaddr
| sort hits desc
| limit 20

何時選 Insights vs Athena

Insights 是互動式且有索引的；Athena 對冷的長期 S3 資料更便宜。Insights 用於過去 24-72 小時的調查，Athena 用於較舊的資料和跨多個日誌來源的 join。SCS-C02 關於成本最優的長期鑑識查詢問題，答案一定是 Athena。

常見 SCS-C02 網路安全排錯陷阱

以下是讓沒有充分準備的考生翻車的四個標準陷阱。

陷阱一——SG 跨參照在沒有 DNS 的情況下無法跨 VPC Peering

VPC A 中的 security group 可以參照 VPC B 中的 security group（透過 peering），前提是 (a) 兩個 VPC 已 peering，且 (b) peering 連線上已啟用 DNS 解析。如果 DNS 解析是關閉的，SG 參照解析為空，流量被靜默拒絕。Reachability Analyzer 會抓到這個；手動檢查 SG 可能不會。

陷阱二——NACL Ephemeral Port 拒絕

如上方 TCP/IP 基礎所討論。典型症狀：對 :443 的輸出 TCP 請求成功，但回應被靜默丟棄，因為同一子網路的輸入 NACL 不允許 ephemeral port 範圍 1024-65535。

陷阱三——Route Table 缺少返回路徑

跨 TGW 或 VPC peering 的非對稱路由。前向路徑沒問題，但目的地子網路的 route table 將返回流量送往 internet gateway 而不是透過 TGW 回去。Flow Logs 在一個方向顯示 ACCEPT，另一個方向什麼都沒有。

陷阱四——Reachability Analyzer 漏掉 AWS Network Firewall 有狀態規則

Reachability Analyzer 評估 Network Firewall 的無狀態規則，但無法完整評估有狀態 Suricata 規則。如果你的路徑經過一個對特定 TLS SNI 模式有 drop 規則的 Network Firewall 有狀態規則組，Reachability Analyzer 會將路徑標記為「可能可達」，你需要 Flow Logs 或 Network Firewall logs 來確認。

端到端實作範例——「Lambda 無法連到 RDS」

讓我走過一個標準的 SCS-C02 排錯流程來鞏固決策樹。

症狀。 私有子網路 subnet-A 中的 Lambda 函數無法連線到同一 VPC 私有子網路 subnet-B 中的 RDS for PostgreSQL。Lambda CloudWatch Logs 在 30 秒後顯示 connection timed out。

步驟一——執行 VPC Reachability Analyzer。 來源 = Lambda 的 ENI（透過 aws lambda get-function 找到），目的地 = RDS endpoint ENI，協定 = TCP，port = 5432。Reachability Analyzer 回傳「不可達」，說明為 subnet-B 輸入 NACL 上的 ACL_RULE_NO_MATCH。完成——你在沒有碰任何封包的情況下找到了根本原因。

步驟二——用 VPC Flow Logs 驗證。 為確認，查詢來源 ENI 的 Flow Logs：

fields @timestamp, srcaddr, dstaddr, dstport, action
| filter dstaddr like /10.0.2./ and dstport = 5432
| sort @timestamp desc
-- 查詢去往 RDS 子網路的被拒絕連線

你看到 REJECT 記錄，沒有對應的 ACCEPT。這確認 NACL 在封鎖；下一步是修復 subnet-B 的 NACL 輸入規則。

步驟三——重新執行 Reachability Analyzer。 修復後，重新執行。判定翻轉為「可達」，並列出完整的轉發路徑。

這為什麼對考試重要。 SCS-C02 的問題有時會給你中間證據（「Flow Logs 顯示 REJECT」）並問「下一步是什麼？」答案是 Reachability Analyzer 來精確定位規則，而不是「手動檢查每個 NACL」。縮短根本原因時間是致勝條件。

整合——網路安全排錯操作手冊

SCS-C02 考生的完整網路安全排錯操作手冊：

1. 閱讀症狀並使用決策樹挑選工具（Reachability Analyzer、Network Access Analyzer、Inspector、Flow Logs、WAF logs、Resolver logs 或 Traffic Mirroring）。
2. 用遙測資料確認——用 Flow Logs、WAF logs 或 Resolver logs 確認有問題的層。
3. 應用 TCP/IP 基礎——檢查 NACL ephemeral port 範圍、返回路徑路由、jumbo frame 上的 MTU/PMTUD。
4. 使用 Inspector 進行機群範圍的可達性分析——永遠不要手動檢查 200 台 instance；讓 Inspector + Security Hub 匯總。
5. 只在必要時才擷取封包——Traffic Mirroring 精準但昂貴；保留給主動事件和 DLP。
6. 自動化操作手冊——透過 EventBridge 將分析器的輸出接到 Security Hub 發現，再接到修復 runbook（例如，透過 SSM Automation 的隔離 SG）。

反覆出現的主題是讓 AWS 原生分析器承擔繁重工作，將手動檢查保留給分析器無法評估的真正邊緣案例（有狀態防火牆規則、OS 防火牆、應用程式監聽器）。在答案中默認使用手動 describe-* 指令鏈的考生，始終比選對正確分析器的考生得分低。

常見問題——網路安全排錯

Q1：我應該何時選擇 VPC Reachability Analyzer 而不是手動檢查 security group 和 NACL？

對於任何路徑特定的問題，一律選擇 VPC Reachability Analyzer。它在一次呼叫中評估 SG、NACL、route table、peering、TGW routes、VPC endpoint 和 Network Firewall 無狀態規則，並返回確切的阻斷元素。手動檢查容易出錯且緩慢；分析器每次分析費用 $0.10。SCS-C02 的錯誤答案經常提供手動檢查——認出它是干擾選項。

Q2：VPC Reachability Analyzer 和 Network Access Analyzer 有什麼不同？

Reachability Analyzer 回答「路徑 A→B 是否可行？」——一個來源、一個目的地，返回可達/不可達並附完整路徑。Network Access Analyzer 回答「在我的帳號中，有哪些路徑符合我的 Network Access Scope JSON？」——它爬取每條潛在路徑並列出違規。事件回應用 Reachability Analyzer，定期合規稽核（「prod 中沒有任何東西可以從 internet 在 TCP/22 上存取」）用 Network Access Analyzer。

Q3：為什麼 Inspector 說我的 EC2 在 port 22 可達，即使我已經打過補丁？

Inspector 的網路可達性規則檢查的是從網際網路是否存在網路路徑，不管 OS 服務是否已修補。打補丁關閉的是 CVE；它不關閉網路路徑。使用 VPC Reachability Analyzer 在 internet gateway 和 instance ENI 之間追蹤，找出允許該路徑的 SG 規則或路由，然後關閉路徑。Inspector 和 Reachability Analyzer 是互補的。

Q4：我的 VPC Flow Logs 顯示 ACCEPT 但應用程式連線仍然 timeout。為什麼？

Flow Logs 中的 ACCEPT 表示 L3/L4 封包被 SG 和 NACL 允許。它不表示應用程式監聽器接受了它。可能的原因：(1) OS 防火牆（iptables、Windows Firewall）丟棄了它；(2) 應用程式沒有監聽那個 port；(3) AWS Network Firewall 有狀態規則丟棄了 TLS SNI；(4) ALB target group 健康檢查失敗且目標不健康。接下來在 OS 和應用程式層調查，而不是在 VPC 層。

Q5：VPC Flow Logs 是否擷取到 EC2 instance metadata service 的流量？

不。 Flow Logs 不記錄到 169.254.169.254、Amazon DNS 伺服器、DHCP 或 Windows 授權啟用的流量。要偵測 IMDS 濫用，依靠 GuardDuty（當 role 的憑證在 AWS 外部被重複使用時，它產生 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS）。透過 launch template 和 SCP 強制使用 IMDSv2（基於 token）以提前防止濫用。

Q6：我應該何時使用 Traffic Mirroring 而不是 VPC Flow Logs？

當你需要原始封包內容——深度封包檢查、DLP、IDS 分析、TLS 交握鑑識——使用 Traffic Mirroring。當你只需要流量元資料（5-tuple、action、位元組/封包計數）時，使用 VPC Flow Logs。Traffic Mirroring 貴得多且頻寬密集；保留給主動調查或明確需要封包層級證據的合規使用案例。

Q7：我的 NACL 允許輸出 TCP/443 但輸入回應被封鎖。發生了什麼？

這是 NACL ephemeral port 陷阱。NACL 是無狀態的——來自 TCP/443 目的地的回應，到達你的客戶端的 ephemeral 來源 port（Linux 32768–60999，Windows 49152–65535）。你的輸入 NACL 必須允許該 ephemeral port 範圍。修復方式是允許來自目的地 CIDR 的輸入 TCP 1024-65535。有狀態的 security group 沒有這個問題。

Q8：如何偵測被入侵 EC2 的 DNS 外洩？

啟用 Route 53 Resolver 查詢日誌並將日誌傳送至中央 S3 bucket。搭配 GuardDuty，它在可疑 DNS 模式（長子網域、已知 C2 網域、信標間隔）上產生 Trojan:EC2/DNSDataExfiltration 和 Backdoor:EC2/C&CActivity.B!DNS 發現。也部署帶有受管網域清單的 Route 53 Resolver DNS Firewall 以封鎖對惡意網域的輸出查詢。封鎖輸出 TCP/UDP 53 到除 Amazon Resolver 以外的任何地方，以防止攻擊者繞過你的 DNS 可見性。

Q9：多帳號環境中鑑識封包擷取的正確架構是什麼？

在來源帳號的可疑 ENI 上設定 VPC Traffic Mirroring session，鏡像目標為專用鑑識 VPC（通常在安全工具帳號或獨立鑑識帳號）中的 Network Load Balancer。NLB 後面，執行一個 Auto Scaling Group 的 Suricata 或 Zeek sensor，將 PCAP 寫入帶有 Compliance 模式 Object Lock 的 S3 bucket 以確保監管鏈。跨帳號透過 VPC peering 或 PrivateLink 到 NLB 實現。

Q10：我如何向稽核人員證明我的 production VPC 中沒有任何東西可以從網際網路在敏感 port 上存取？

使用 AWS Network Access Analyzer 搭配一個 Network Access Scope，匹配 MatchPaths: 任何 internet gateway → production VPC 中的任何 ENI → port 3306，ExcludePaths: []。透過 EventBridge 排程每週執行分析器，將發現傳送至 Security Hub，並將空發現證據儲存在帶有 Object Lock 的 S3 中。稽核人員看到零意外暴露的持續記錄。SCS-C02 頻繁測試這個精確的模式。

總結

SCS-C02 的網路安全排錯與可達性分析技能組是一個小而精確的工具箱：三個分析器（Reachability Analyzer 用於單一路徑，Network Access Analyzer 用於集合對集合 scope，Inspector 用於運算加路徑）、三條日誌流（VPC Flow Logs 用於 L3/L4，WAF logs 用於 L7，Route 53 Resolver 查詢日誌用於 DNS）、一種封包擷取機制（Traffic Mirroring），以及兩個查詢介面（CloudWatch Logs Insights 用於快速操作查詢，Athena 用於廉價長期鑑識）。掌握症狀對應工具決策樹、TCP/IP 基礎（特別是 NACL ephemeral port 和有狀態 vs 無狀態）以及四個常見陷阱（peering DNS 解析、NACL ephemeral、返回路徑路由、有狀態防火牆盲點），Task 3.4 的問題就會變得機械化。始終優先使用原生分析器而不是手動檢查，用 Flow Logs 遙測資料驗證分析器判定，並用 Object Lock 儲存鑑識證據以確保監管鏈。網路安全排錯是 Domain 3 所有其他設計決策最終接受壓力測試的地方——也是 SCS-C02 將真正的工程師和只懂理論的架構師區分開來的地方。