讓我們從零開始認識AWS VPC到底是什麼
AWS 的 VPC，中文有時有人叫它虛擬私有雲吧，不過這個名詞大家講法還是有些差異。它在 AWS 帳號裡面算是一種比較基礎的網路分隔機制，說穿了就是讓使用者能夠把自己的流量和其他客戶的切開來，各自一塊田地。大概不像那種實體交換器那樣明確，但又比起純粹混合要來得乾淨，整個是軟體定義的。
通常每個人一開始註冊 AWS，帳號底下那些主要區域就會自己冒出一些預設的 VPC，好像 CIDR 範圍都抓在 172.31 開頭那附近（大致上啦）。後面你如果想再多開幾個，也沒什麼限制，甚至不用一定要循著某些 RFC1918 內部網段走，有些人會用很特別的範圍，看需求。
VPC 是區域性的東西——不是你在一個地方建好了，其他地區就跟著有，要到哪邊用就去哪邊開。然後，它會配給你一組識別碼，「vpc-」開頭，有長短之分；舊一點的好像只有八個字母，新版變得比較長，大約十幾碼。有些人看到短的可能還會愣一下，不過其實差不多意思。
打開 VPC 控制台應該可以一次看到所有地區現況，那裡資訊挺集中的。如果你進去翻 ARP 表可能也發現很怪，好像只是給作業系統看齊，其實很多傳統本地網路才需要靠 ARP 去找裝置，在 VPC 裡根本不太派得上用場。常見那種 ARP 欺騙攻擊，在這裡反倒沒什麼效果，畢竟架構完全不同。
如果剛剛還沒弄 TryHackMe 的雲端沙盒，可以點一下頁面右上角橘色按鈕去產生環境，把提供的憑證抄下來進入 AWS 管理介面玩玩看。記得所有資源都丟在美東那邊（us-east-1），位置固定不是隨便亂丟的。至於更多細節嘛……反正操作時多少都能摸到一些門道，有空可以慢慢翻翻控制台各種設定，也許還能發現意外的小細節呢。
通常每個人一開始註冊 AWS，帳號底下那些主要區域就會自己冒出一些預設的 VPC，好像 CIDR 範圍都抓在 172.31 開頭那附近（大致上啦）。後面你如果想再多開幾個，也沒什麼限制，甚至不用一定要循著某些 RFC1918 內部網段走，有些人會用很特別的範圍，看需求。
VPC 是區域性的東西——不是你在一個地方建好了，其他地區就跟著有，要到哪邊用就去哪邊開。然後，它會配給你一組識別碼，「vpc-」開頭，有長短之分；舊一點的好像只有八個字母，新版變得比較長，大約十幾碼。有些人看到短的可能還會愣一下，不過其實差不多意思。
打開 VPC 控制台應該可以一次看到所有地區現況，那裡資訊挺集中的。如果你進去翻 ARP 表可能也發現很怪，好像只是給作業系統看齊，其實很多傳統本地網路才需要靠 ARP 去找裝置，在 VPC 裡根本不太派得上用場。常見那種 ARP 欺騙攻擊，在這裡反倒沒什麼效果，畢竟架構完全不同。
如果剛剛還沒弄 TryHackMe 的雲端沙盒，可以點一下頁面右上角橘色按鈕去產生環境，把提供的憑證抄下來進入 AWS 管理介面玩玩看。記得所有資源都丟在美東那邊（us-east-1），位置固定不是隨便亂丟的。至於更多細節嘛……反正操作時多少都能摸到一些門道，有空可以慢慢翻翻控制台各種設定，也許還能發現意外的小細節呢。
準備好你的環境來探索VPC實戰操作
VPC這東西，有時候說起來有點像是那種把空間切一切、每一塊都給它規定個範圍的遊戲。裡頭的子網路（subnet），聽說只能窩在某個單一可用區（AZ）裡，不能兩邊跑；而且每個子網的範圍也得比VPC本身再小一些，數字嘛，也就是比原本的大概再少個幾成吧，反正不能重疊到。
大家經常會聽人提到什麼VPC的路由器，好像每條VPC都會自帶一台，有點像暗藏版，不是你真的看到那種硬體，而是AWS直接就內建了。流量怎麼走，就靠那些路由表決定了，每個子網都要配上一張，不管你是不是自己去指定，沒設特別關聯的話，好像系統自己就給你指派到主路由表那邊去了。對於同一張路由表，其實可以讓好幾個子網一起共用，但一個子網不太能同時掛多張，只能選一邊靠。
偶爾會有人講什麼「公有」或「私有」子網，其實AWS上也沒有哪個地方會明著寫這標籤啦。不過，判斷的方法大致上就是看你的路由表裡，有沒有哪條直接通往所謂Internet Gateway（IGW）的線。如果有，那大致上可以認為只要該子網底下的資源拿到了公開IP地址，就可能被外部世界碰得到。有些人覺得只要沒分配公開IP、而且又沒走IGW，那這樣子的子網通常就算偏向私有吧。當然，還有另一種叫Virtual Private Gateway（VGW），主要是在跟公司內部那些比較舊式、傳統型的連線做對接用。
其實這些名詞聽起來有點多，但仔細想想，就是誰跟誰打交道以及怎麼打交道罷了。有時候資訊跳來跳去，如果突然搞混，也蠻正常——畢竟設定方式和流程偶爾會改動，小細節很容易漏掉。如果不太確定自己的設定到底屬於哪類，也許多試幾次或換種思考角度看看，慢慢就習慣了。
大家經常會聽人提到什麼VPC的路由器，好像每條VPC都會自帶一台，有點像暗藏版，不是你真的看到那種硬體，而是AWS直接就內建了。流量怎麼走，就靠那些路由表決定了，每個子網都要配上一張，不管你是不是自己去指定，沒設特別關聯的話，好像系統自己就給你指派到主路由表那邊去了。對於同一張路由表，其實可以讓好幾個子網一起共用，但一個子網不太能同時掛多張，只能選一邊靠。
偶爾會有人講什麼「公有」或「私有」子網，其實AWS上也沒有哪個地方會明著寫這標籤啦。不過，判斷的方法大致上就是看你的路由表裡，有沒有哪條直接通往所謂Internet Gateway（IGW）的線。如果有，那大致上可以認為只要該子網底下的資源拿到了公開IP地址，就可能被外部世界碰得到。有些人覺得只要沒分配公開IP、而且又沒走IGW，那這樣子的子網通常就算偏向私有吧。當然，還有另一種叫Virtual Private Gateway（VGW），主要是在跟公司內部那些比較舊式、傳統型的連線做對接用。
其實這些名詞聽起來有點多，但仔細想想，就是誰跟誰打交道以及怎麼打交道罷了。有時候資訊跳來跳去，如果突然搞混，也蠻正常——畢竟設定方式和流程偶爾會改動，小細節很容易漏掉。如果不太確定自己的設定到底屬於哪類，也許多試幾次或換種思考角度看看，慢慢就習慣了。
Comparison Table:
| 主題 | 內容 |
|---|---|
| AWS IP 管理 | 使用指令查看公開的 IP 範圍，減少手動修改路由表與安全群組的麻煩。 |
| CloudFront CIDR | CloudFront 目前維護約四十個範圍，需定期檢查其變動。 |
| VPC Endpoint 安全性 | 可限制特定 S3 或 DynamoDB 的訪問，但存在被攻擊者利用的風險。 |
| VPC PrivateLink 功能 | 允許在 VPC 內部連接 AWS 服務或其他客戶，避免流量經過公共網際網路。 |
| DNS 設置與 Route 53 | Amazon 提供內建 DNS，若需私有解決方案可考慮 Route 53，有助於管理內部流量和健康檢查功能。 |
拆解VPC三大核心元件：可用區、子網路和路由表
有時候，AWS 裡面會有個叫做「網路存取控制清單」的東西，大家偶爾會直接稱它 NACL。這玩意兒本質上像是某種防火牆，不過作用範圍好像是針對子網去設計的。有些人可能記得，它不是每次都只管單邊流量——進來和出去那兩個方向都要分別設定，看起來不像安全群組那樣什麼都自動搞定。
NACL 允許你調整流量該不該通過，選項大致上就是允許或拒絕，好像沒什麼特別花俏的。規則順序還挺講究，每一條好像都得照著排下去才行。有人說這東西偏偏就是無狀態（stateless），所以如果你只開放其中一個方向，很容易遇到問題：舉例說，進來開了但出去沒對應，那資料包就卡住出不去了。
其實 AWS 提供的防護機制不少，但 NACL 算是其中比較常見的一種。如果仔細看，大概每個子網底下多多少少都會碰到它，只是大家用不用心設定又是另一回事。有的人覺得這套結構略顯死板，但在某些情境下，還是能提供必要的基本保護。不過，遇到複雜需求時，也許還要搭配其他方案一起考慮才比較踏實吧。
NACL 允許你調整流量該不該通過，選項大致上就是允許或拒絕，好像沒什麼特別花俏的。規則順序還挺講究，每一條好像都得照著排下去才行。有人說這東西偏偏就是無狀態（stateless），所以如果你只開放其中一個方向，很容易遇到問題：舉例說，進來開了但出去沒對應，那資料包就卡住出不去了。
其實 AWS 提供的防護機制不少，但 NACL 算是其中比較常見的一種。如果仔細看，大概每個子網底下多多少少都會碰到它，只是大家用不用心設定又是另一回事。有的人覺得這套結構略顯死板，但在某些情境下，還是能提供必要的基本保護。不過，遇到複雜需求時，也許還要搭配其他方案一起考慮才比較踏實吧。
搞懂NACL和Security Group的防火牆差異
跟IAM那一套比起來，NACL（網路存取控制列表）這東西有點不太一樣。有時候大家會覺得只要明確允許就一定可以，但其實NACL的規則是按照順序一條條往下比對，只要遇到第一個吻合就停了。預設情況下，AWS那邊會自動幫你加上一個「全部拒絕」的底線規則。
（圖那些都是TryHackMe出的內容啦）
像在AWS主控台裡面設定NACL，大致上畫面就是那種感覺——假如現在有某個NACL把所有SSH流量都擋掉，其他類型的流量又全放行，那最下面還是留著AWS自己給的預設拒絕規則。
因為NACL是直接作用在整個子網路上，所以只要手滑搞錯，影響範圍恐怕一下就很大，有人說這也是為什麼後來比較少見有人大量用NACL。反倒是安全群組（Security Group），好像被用得更頻繁。有些中央網管單位可能還是會專門設特定NACL，把某些服務完全封死，不給例外。
安全群組呢，主要就是綁在EC2、RDS之類單一資源身上。它不像NACL那樣分明確允許和拒絕，其實只有「允許」而已。而且它是狀態式的，入站和出站各自有獨立的一套規則，看起來跟傳統防火牆差蠻多。
（又是一張TryHackMe的圖）
基本上，現在如果想管理資源層級的網路權限，大部分人都靠安全群組解決。你可以指定來源IP範圍，也能直接指定另一組安全群組ID當作來源。如果選的是安全群組ID，那意思大概就是：任何有掛這組ID的ENI都算合法來源。
AWS整理了一張比較表，把安全群組和NACL不同點列出來。（資料來源就不細說了）
接下來，看題目：
4.1
VPCRoom-Instances這個Security Group允許哪個CIDR區段進行SSH？答案大約是十六萬多台IP那種等級——172.18.0.0/16。
（VPC控制台 > 安全性 > Security Groups > VPCRoom-instances）
4.2
從on-prem內部網段到私有子網，被允許通過哪些連接埠範圍？看一下VPCRoom Private Subnet NACL，大致涵蓋從二十多號到四百多號端口吧——22-443。
（VPC主控台 > 虛擬私有雲 > 子網路 > VPCRoom=PrivateSubte-us-east-1b或1a）
---
再往下講一下VPC裡頭跟外頭那些事，有時候防禦AWS環境時蠻重要的一點，就是到底哪些服務住在VPC裡、哪些服務其實不歸它管。一堆EC2、RDS還有RedShift這些偏運算或儲存的大型資源，全都跑在VPC框架裡。不過像S3桶子、DynamoDB那種NoSQL資料庫，就沒綁定在VPC底下。很多新手剛開始可能會搞混，畢竟介面長得都有點像，但事實上兩者差別滿顯眼，只是不是每次一眼看出來而已。
（圖那些都是TryHackMe出的內容啦）
像在AWS主控台裡面設定NACL，大致上畫面就是那種感覺——假如現在有某個NACL把所有SSH流量都擋掉，其他類型的流量又全放行，那最下面還是留著AWS自己給的預設拒絕規則。
因為NACL是直接作用在整個子網路上，所以只要手滑搞錯，影響範圍恐怕一下就很大，有人說這也是為什麼後來比較少見有人大量用NACL。反倒是安全群組（Security Group），好像被用得更頻繁。有些中央網管單位可能還是會專門設特定NACL，把某些服務完全封死，不給例外。
安全群組呢，主要就是綁在EC2、RDS之類單一資源身上。它不像NACL那樣分明確允許和拒絕，其實只有「允許」而已。而且它是狀態式的，入站和出站各自有獨立的一套規則，看起來跟傳統防火牆差蠻多。
（又是一張TryHackMe的圖）
基本上，現在如果想管理資源層級的網路權限，大部分人都靠安全群組解決。你可以指定來源IP範圍，也能直接指定另一組安全群組ID當作來源。如果選的是安全群組ID，那意思大概就是：任何有掛這組ID的ENI都算合法來源。
AWS整理了一張比較表，把安全群組和NACL不同點列出來。（資料來源就不細說了）
接下來，看題目：
4.1
VPCRoom-Instances這個Security Group允許哪個CIDR區段進行SSH？答案大約是十六萬多台IP那種等級——172.18.0.0/16。
（VPC控制台 > 安全性 > Security Groups > VPCRoom-instances）
4.2
從on-prem內部網段到私有子網，被允許通過哪些連接埠範圍？看一下VPCRoom Private Subnet NACL，大致涵蓋從二十多號到四百多號端口吧——22-443。
（VPC主控台 > 虛擬私有雲 > 子網路 > VPCRoom=PrivateSubte-us-east-1b或1a）
---
再往下講一下VPC裡頭跟外頭那些事，有時候防禦AWS環境時蠻重要的一點，就是到底哪些服務住在VPC裡、哪些服務其實不歸它管。一堆EC2、RDS還有RedShift這些偏運算或儲存的大型資源，全都跑在VPC框架裡。不過像S3桶子、DynamoDB那種NoSQL資料庫，就沒綁定在VPC底下。很多新手剛開始可能會搞混，畢竟介面長得都有點像，但事實上兩者差別滿顯眼，只是不是每次一眼看出來而已。
哪些服務住在VPC裡？哪些在外面流浪？
其實VPC裡頭的資源嘛，常見會用NACLs或安全群組這些東西來擋住外面的人，基本上要直接碰到它們還真不容易。反過來，VPC以外的那些服務，大多就只靠IAM在防護，有點像是不同層級的守門員。
有時候你會發現，每個待在VPC裡的資源，好像都會分配到一張叫ENI的虛擬網卡。有些人說這東西本質上就是從VPC那邊租來的一份DHCP位址。ENI平常可以拔掉、裝到另一台機器去，偶爾遇到高可用轉移，也有人這樣搞。至於ENI是不是能同時跨兩個子網？聽說只能在同一個可用區才行，而且它綁在哪個子網就是哪個，不太能亂動。而且啊，你設定了安全群組，其實都是掛在這塊ENI上的。
想看清楚一整個VPC底下到底有多少資源，最簡單的方法大概就是列出所有ENI吧。不管是透過EC2管理介面還是AWS CLI都做得到，用CloudShell打指令也是有人這麼操作。
另外，有時候你得讓VPC內部的機器跟外面的某些特定服務講話，比如S3、DynamoDB什麼的，以前沒別招，只好把機器丟到公網或者加NAT Gateway，那種速度嘛……據說也就比一般慢不了多少，但價格好像不算便宜。後來AWS推出了所謂的VPC Endpoint和PrivateLink，大概幫大家省下不少麻煩。如果只是為了讓內部伺服器偷偷摸摸存取S3，不必再非得繞道公網出去。聽說NAT Gateway頻寬頂多數千兆左右，也有人嫌貴。
比較早期的是S3先支援Endpoint功能，所以現在如果要高頻寬拉資料，大部分架構師乾脆就全都透過Endpoint走，比起以前那種一定要開放對外連線（光想到風險跟帳單）就覺得安心許多。不過，要讓Endpoint生效，還需要記得去改一下路由表，把去指定服務的流量導向某種叫「受管前綴清單」的東西，而不是老方法填CIDR範圍。AWS怎麼把自家IP範圍塞進來？就靠Prefix List那套啦，看起來蠻抽象，但其實背後只是自家IP集合映射進你的VPC而已。
總之，如果你碰巧需要限制或乾脆關閉整個VPC對外上網能力，又不想犧牲必要功能，可能會考慮這類Endpoint或PrivateLink方案吧。不過每家公司情境不同，有人覺得方便，有人則觀望中。
有時候你會發現，每個待在VPC裡的資源，好像都會分配到一張叫ENI的虛擬網卡。有些人說這東西本質上就是從VPC那邊租來的一份DHCP位址。ENI平常可以拔掉、裝到另一台機器去，偶爾遇到高可用轉移，也有人這樣搞。至於ENI是不是能同時跨兩個子網？聽說只能在同一個可用區才行，而且它綁在哪個子網就是哪個，不太能亂動。而且啊，你設定了安全群組，其實都是掛在這塊ENI上的。
想看清楚一整個VPC底下到底有多少資源，最簡單的方法大概就是列出所有ENI吧。不管是透過EC2管理介面還是AWS CLI都做得到，用CloudShell打指令也是有人這麼操作。
另外，有時候你得讓VPC內部的機器跟外面的某些特定服務講話，比如S3、DynamoDB什麼的，以前沒別招，只好把機器丟到公網或者加NAT Gateway，那種速度嘛……據說也就比一般慢不了多少，但價格好像不算便宜。後來AWS推出了所謂的VPC Endpoint和PrivateLink，大概幫大家省下不少麻煩。如果只是為了讓內部伺服器偷偷摸摸存取S3，不必再非得繞道公網出去。聽說NAT Gateway頻寬頂多數千兆左右，也有人嫌貴。
比較早期的是S3先支援Endpoint功能，所以現在如果要高頻寬拉資料，大部分架構師乾脆就全都透過Endpoint走，比起以前那種一定要開放對外連線（光想到風險跟帳單）就覺得安心許多。不過，要讓Endpoint生效，還需要記得去改一下路由表，把去指定服務的流量導向某種叫「受管前綴清單」的東西，而不是老方法填CIDR範圍。AWS怎麼把自家IP範圍塞進來？就靠Prefix List那套啦，看起來蠻抽象，但其實背後只是自家IP集合映射進你的VPC而已。
總之，如果你碰巧需要限制或乾脆關閉整個VPC對外上網能力，又不想犧牲必要功能，可能會考慮這類Endpoint或PrivateLink方案吧。不過每家公司情境不同，有人覺得方便，有人則觀望中。
揭密VPC蟲洞：端點服務與PrivateLink的魔法
AWS 這邊有一套前置碼清單，幫忙管理那些對外公開的 IP，說真的，很多人根本沒空一直去改 VPC 路由表或安全群組。要看各種服務用哪些 CIDR，其實打一條指令就可以查得差不多了。不過現在 CloudFront（就是那個 CDN 啦）大概維護著四十多個範圍，不見得天天一樣，說不定有時候還會加減變動。
你要是有玩過 VPC Endpoint，大致知道它能跟 IAM 配合，只開放某些 S3 桶子或 DynamoDB 表能被用。可是在攻擊場景下，有人就可能偷偷塞一個 VPC endpoint，把資料流到自己管的 S3，也許在之後的 AWS 實作題會碰到這招。
VPC PrivateLink 聽起來像什麼專業玩意兒，其實就類似在你自己的 VPC 裡面插上一張 ENI，再跟 AWS 某些服務（或者別家客戶）連起來。這種方式讓使用者不用把流量丟出網際網路，就能接觸到 AWS 或合作夥伴提供的東西。有時候你打開控制台，看得到一大堆 PrivateLink 能支援的服務，數量好像快兩百種吧。有些人如果想全都弄起來，一個月下來帳單蠻驚人的——大概破千美金跑不掉。
順帶一提，如果真的仔細去翻 Route Table，你會發現那個 Endpoint 的目標不是什麼傳統 IP，而是以 vpce-* 開頭的一串字母數字。具體是哪一條路由、哪一個欄位，其實查一下控制台應該都能找到。
再說回 Service Name，像是 S3 這類常見服務，在 VPC Endpoint 控制台會看到 com.amazonaws.us-east-1.s3 這種格式。一開始看可能覺得很繞，但其實就是地區加上服務名。
至於 DNS 部分嘛——AWS 在每個 VPC 裡都有內建自家的 DNS 伺服器。一般來講，只要你沒有特別設置，VPC 裡面的主機預設都會拿那個 Amazon 提供的 DNS 去解析名字。IP 位址算出來挺有意思，就是拿你的 VPC IPv4 網段最底層那格再加二，不一定每次都記得住啦。
你要是有玩過 VPC Endpoint，大致知道它能跟 IAM 配合，只開放某些 S3 桶子或 DynamoDB 表能被用。可是在攻擊場景下，有人就可能偷偷塞一個 VPC endpoint，把資料流到自己管的 S3，也許在之後的 AWS 實作題會碰到這招。
VPC PrivateLink 聽起來像什麼專業玩意兒，其實就類似在你自己的 VPC 裡面插上一張 ENI，再跟 AWS 某些服務（或者別家客戶）連起來。這種方式讓使用者不用把流量丟出網際網路，就能接觸到 AWS 或合作夥伴提供的東西。有時候你打開控制台，看得到一大堆 PrivateLink 能支援的服務，數量好像快兩百種吧。有些人如果想全都弄起來，一個月下來帳單蠻驚人的——大概破千美金跑不掉。
順帶一提，如果真的仔細去翻 Route Table，你會發現那個 Endpoint 的目標不是什麼傳統 IP，而是以 vpce-* 開頭的一串字母數字。具體是哪一條路由、哪一個欄位，其實查一下控制台應該都能找到。
再說回 Service Name，像是 S3 這類常見服務，在 VPC Endpoint 控制台會看到 com.amazonaws.us-east-1.s3 這種格式。一開始看可能覺得很繞，但其實就是地區加上服務名。
至於 DNS 部分嘛——AWS 在每個 VPC 裡都有內建自家的 DNS 伺服器。一般來講，只要你沒有特別設置，VPC 裡面的主機預設都會拿那個 Amazon 提供的 DNS 去解析名字。IP 位址算出來挺有意思，就是拿你的 VPC IPv4 網段最底層那格再加二，不一定每次都記得住啦。
DNS在VPC裡扮演的關鍵角色你不可不知
常聽人提到VPC的網段，如果是那種一九二點一六八點十五開頭的，結尾是零，大致上就像是一個小型區域網吧。這時它預設給你的DNS伺服器位置，好像都是一九二點一六八點十五點二，基本沒變過。有些朋友說Amazon雲端這個DNS會幫忙查公開的網址，但如果你想自己弄一些私有的，比如公司內部用的，不知道是不是可以考慮Route53？差不多就是Amazon主打的一套DNS服務啦，好像有人覺得它滿穩定，而且全世界都能用，還有檢查主機健康狀況跟故障切換那些功能。不過細節之後再聊。
其實最重要的大概就是，你能自己建私人DNS紀錄，然後讓Amazon DNS來處理VPC裡面的機器查詢。記得，有些設定還能讓VPC裡那台DNS去回答外部網路（像辦公室內部）的查詢，也可能反過來，把請求丟回本地端的DNS伺服器。如果搞到安全面向，有人會提醒：這也算是一條側移路徑吧？萬一雲端被入侵了，就有機會滲透進企業本地網絡。
另外Route 53 Resolver附帶一些保護功能，比如說Resolver DNS防火牆、查詢日誌。前者類似設一道閘門，你可以決定哪些網址允許VPC裡的虛擬主機去問、哪些不行。如果配合公司的本地電腦一起連這顆Resolver，好像也能套用同樣規則。好處大概在於減少資料通過DNS偷偷流出（有人稱為exfiltration攻擊）。而且把DNS活動記錄下來，可以送到CloudWatch Log，再丟進安全資訊管理系統（SIEM）做更細緻分析。
只是要注意的是，比較進階那些Route53附加功能，多半都有額外收費，開啟時最好先瞭解費用怎麼計算，以免帳單爆增。如果你的VPC剛好已經設定了，把日誌送到某個叫“VPCResolverLogs”的log group，其實直接去CloudWatch Logs Console就能看到歷史紀錄。右上角那邊應該有個橙色框框，可以搜尋整包Log Group內容──只要耐心找一下，大致可以翻出需要的資訊。
至於你問task6.vpcroom.tryhackme.com在Route53控制台裡對應哪個IP？據說答案是169.254.169.254。但詳細情形嘛，有時候還是得親自登入介面確認比較保險。
其實最重要的大概就是，你能自己建私人DNS紀錄，然後讓Amazon DNS來處理VPC裡面的機器查詢。記得，有些設定還能讓VPC裡那台DNS去回答外部網路（像辦公室內部）的查詢，也可能反過來，把請求丟回本地端的DNS伺服器。如果搞到安全面向，有人會提醒：這也算是一條側移路徑吧？萬一雲端被入侵了，就有機會滲透進企業本地網絡。
另外Route 53 Resolver附帶一些保護功能，比如說Resolver DNS防火牆、查詢日誌。前者類似設一道閘門，你可以決定哪些網址允許VPC裡的虛擬主機去問、哪些不行。如果配合公司的本地電腦一起連這顆Resolver，好像也能套用同樣規則。好處大概在於減少資料通過DNS偷偷流出（有人稱為exfiltration攻擊）。而且把DNS活動記錄下來，可以送到CloudWatch Log，再丟進安全資訊管理系統（SIEM）做更細緻分析。
只是要注意的是，比較進階那些Route53附加功能，多半都有額外收費，開啟時最好先瞭解費用怎麼計算，以免帳單爆增。如果你的VPC剛好已經設定了，把日誌送到某個叫“VPCResolverLogs”的log group，其實直接去CloudWatch Logs Console就能看到歷史紀錄。右上角那邊應該有個橙色框框，可以搜尋整包Log Group內容──只要耐心找一下，大致可以翻出需要的資訊。
至於你問task6.vpcroom.tryhackme.com在Route53控制台裡對應哪個IP？據說答案是169.254.169.254。但詳細情形嘛，有時候還是得親自登入介面確認比較保險。
監控VPC活動的三種必備雷達系統
說到在VPC裡面監控網路流量，好像有那麼幾種不太一樣的方式能收集跟安全有關的訊息。有一種叫VPC Flow Logs，它記下來的大致是封包頭，沒有去動裡面的內容。這FlowLogs服務能把結果丟去CloudWatch Logs，也可以存進S3桶子。後者聽說成本比較低，而且對於那種跨很多AWS帳號、分布不同地區的公司來說，還能把日誌集中在某個地方管理，看起來方便不少。
如果隨便找一條日誌出來看，有好些欄位，不一定誰都會記得它們代表什麼意思。開頭就是Flow Log版本號，預設都是個「2」，然後是AWS帳號，再過去就是ENI編號。後面接著來源與目的IP、來源和目的Port，中間有個6，是指協定類型（大部分時候這邊會看到TCP）。再往下看，那兩個數字分別代表大約二十多包資料和七千多位元組傳輸量。最後幾項則是連線開始與結束時間（一串很長的數字，大概Unix時間格式）、ACCEPT或REJECT之類的動作，還有個OK，通常沒啥特別就會顯示這樣。
而且2019年的時候，好像AWS又丟出了一個新東西叫做VPC Traffic Mirroring。它算是一種針對單一ENI做流量鏡像，可以用於比較深入的封包檢查。不過要真的導向某個目標裝置，好像還需要Layer-3等級的路由才行，有點技術門檻。
另外，如果回頭聊一下DNS日誌，它被歸在CloudWatch的一部分，就是專門記錄那些機器到底發出了哪些查詢請求。有些人覺得滿實用，尤其是在追蹤內部流量的時候。
講到威脅偵測，其實Amazon GuardDuty這項服務也常被提起。據說它結合了自家的威脅情報跟機器學習，在網路層級主要依賴VPC FlowLogs和DNS Logs做分析。不見得所有場景都適用，但已經有人發現某些異常情況還滿容易被挖出來。
至於你問到CloudWatch Logs裡面存放VPC Flow Logs那個Log group名稱，大致上看到的是`/aws/vpcFlowLogs/VPCRoom`，當然每家公司可能命名略有不同，但差不了多少。
---
轉移話題稍微遠一些，如果考慮到企業怎麼把雲端連回地面上的私有網絡——也就是從雲端到本地，其實AWS提供了好幾條管道。有一種DirectConnect，專門為企業設計。如果公司剛好租在那些特定資料中心，他們甚至會拉條光纖直接從自己的機櫃通到你的設備，理論上速度相當快，可以接近百GB等級吧——但一般人應該很少遇得到。另外，有些人關心不同VPC之間要怎麼互通，也就是所謂「雲對雲」；方法挺多元，其中也包含ClientVPN這類AWS自己維護給終端用戶使用的服務。有時候想想，其實要搞懂整套架構並不是件很輕鬆的小事，每家公司根據需求選擇方案都不太一樣，就算你現在手邊沒碰過，以後八成也會聽聞相關案例。
如果隨便找一條日誌出來看，有好些欄位，不一定誰都會記得它們代表什麼意思。開頭就是Flow Log版本號，預設都是個「2」，然後是AWS帳號，再過去就是ENI編號。後面接著來源與目的IP、來源和目的Port，中間有個6，是指協定類型（大部分時候這邊會看到TCP）。再往下看，那兩個數字分別代表大約二十多包資料和七千多位元組傳輸量。最後幾項則是連線開始與結束時間（一串很長的數字，大概Unix時間格式）、ACCEPT或REJECT之類的動作，還有個OK，通常沒啥特別就會顯示這樣。
而且2019年的時候，好像AWS又丟出了一個新東西叫做VPC Traffic Mirroring。它算是一種針對單一ENI做流量鏡像，可以用於比較深入的封包檢查。不過要真的導向某個目標裝置，好像還需要Layer-3等級的路由才行，有點技術門檻。
另外，如果回頭聊一下DNS日誌，它被歸在CloudWatch的一部分，就是專門記錄那些機器到底發出了哪些查詢請求。有些人覺得滿實用，尤其是在追蹤內部流量的時候。
講到威脅偵測，其實Amazon GuardDuty這項服務也常被提起。據說它結合了自家的威脅情報跟機器學習，在網路層級主要依賴VPC FlowLogs和DNS Logs做分析。不見得所有場景都適用，但已經有人發現某些異常情況還滿容易被挖出來。
至於你問到CloudWatch Logs裡面存放VPC Flow Logs那個Log group名稱，大致上看到的是`/aws/vpcFlowLogs/VPCRoom`，當然每家公司可能命名略有不同，但差不了多少。
---
轉移話題稍微遠一些，如果考慮到企業怎麼把雲端連回地面上的私有網絡——也就是從雲端到本地，其實AWS提供了好幾條管道。有一種DirectConnect，專門為企業設計。如果公司剛好租在那些特定資料中心，他們甚至會拉條光纖直接從自己的機櫃通到你的設備，理論上速度相當快，可以接近百GB等級吧——但一般人應該很少遇得到。另外，有些人關心不同VPC之間要怎麼互通，也就是所謂「雲對雲」；方法挺多元，其中也包含ClientVPN這類AWS自己維護給終端用戶使用的服務。有時候想想，其實要搞懂整套架構並不是件很輕鬆的小事，每家公司根據需求選擇方案都不太一樣，就算你現在手邊沒碰過，以後八成也會聽聞相關案例。
跨雲連線全攻略：從地端到多VPC的通道搭建術
有些公司會把光纖線路分給好幾個帳號或好幾個VPC共用，這樣一來在組織裡管理起來也稍微方便點。比較小型的團隊可能沒那麼要求頻寬或延遲，他們會考慮AWS提供的Site to Site VPN。這種服務大致是AWS從雲端主動開一條IPSec加密隧道，終點連到你自己機房的路由器或防火牆那邊。操作時得先設定一個叫Customer Gateway的小東西，這算是AWS端要找的門牌號碼，接著再建VPN連線，把這個門牌跟AWS內部某個虛擬閘道綁在一起。Direct Connect和Site to Site VPN兩種方案，都得去VPC路由表裡設點規則，不然資料就不知道往哪送了。想讓本地網段能通進VPC，目標就要設成那個VGW。
說真的，如果有人想從雲端轉進機房搞事，這些隧道就是他們繞路的捷徑。不過換角度想，站在防守的人立場，比較穩妥的方法還是讓所有Site to Site VPN或DirectConnect都停在防火牆，再慢慢過濾權限設定嚴一點。有些合規單位會注意到：Site to Site VPN傳輸其實都有IPSec加密保護，但DirectConnect走的是專線，在出你自己機櫃後到AWS那頭，其實沒有自動加密。
說到多帳號策略，有些企業會將開發跟正式環境拆分給不同團隊、甚至不同區域去管控，一方面降低風險範圍，一方面也方便隔離責任。像有些團隊之間偶爾需要互通資源吧？AWS給了兩種方式讓VPC彼此打招呼。一種叫做VPC Peering，就是直接兩台VPC之間拉條私下通道（當然都是在AWS自家網路內部）。只要雙方CIDR不重疊，大致上都可以串起來，不管是不是同帳號、是不是跨區都行。如果公司有備援需求，比如異地災難復原，有時候也靠這招。但每次建立Peering，都得記得去改一下VPC裡的路由表，把對方網段指到peering終端口才行。
值得提醒的是——用Peering時不能指望它會自動順便幫你串第三方。例如A和B彼此Peering、B又跟C Peering，可惜A不能直接摸到C，只能透過B兜一圈再轉出去。其實VPN跟DirectConnect也是類似狀況，不太支援所謂「三角互通」。
有段時間大家覺得管理太多Peering關係很麻煩，就出了Transit Gateway。它比較像是一台專門處理各種VPC流量交換的大型總路由器，可以讓數十個甚至更多的VPC用單一路徑互聯，而且也能納入DirectConnect或Site to Site VPN等外部連線。
最後還有Client VPN這項服務，其實就是AWS替你架好OpenVPN，誰拿到權限就能自己開自己的VPN入口。對攻擊者或者偏重自主彈性的使用者，也許是挺方便快速的一種選擇；但如果公司原本管控嚴格，也可能變成旁門左道，被人繞過既有安全檢查。不過業界看法不一，有人覺得只是多了一層可選工具而已啦。
說真的，如果有人想從雲端轉進機房搞事，這些隧道就是他們繞路的捷徑。不過換角度想，站在防守的人立場，比較穩妥的方法還是讓所有Site to Site VPN或DirectConnect都停在防火牆，再慢慢過濾權限設定嚴一點。有些合規單位會注意到：Site to Site VPN傳輸其實都有IPSec加密保護，但DirectConnect走的是專線，在出你自己機櫃後到AWS那頭，其實沒有自動加密。
說到多帳號策略，有些企業會將開發跟正式環境拆分給不同團隊、甚至不同區域去管控，一方面降低風險範圍，一方面也方便隔離責任。像有些團隊之間偶爾需要互通資源吧？AWS給了兩種方式讓VPC彼此打招呼。一種叫做VPC Peering，就是直接兩台VPC之間拉條私下通道（當然都是在AWS自家網路內部）。只要雙方CIDR不重疊，大致上都可以串起來，不管是不是同帳號、是不是跨區都行。如果公司有備援需求，比如異地災難復原，有時候也靠這招。但每次建立Peering，都得記得去改一下VPC裡的路由表，把對方網段指到peering終端口才行。
值得提醒的是——用Peering時不能指望它會自動順便幫你串第三方。例如A和B彼此Peering、B又跟C Peering，可惜A不能直接摸到C，只能透過B兜一圈再轉出去。其實VPN跟DirectConnect也是類似狀況，不太支援所謂「三角互通」。
有段時間大家覺得管理太多Peering關係很麻煩，就出了Transit Gateway。它比較像是一台專門處理各種VPC流量交換的大型總路由器，可以讓數十個甚至更多的VPC用單一路徑互聯，而且也能納入DirectConnect或Site to Site VPN等外部連線。
最後還有Client VPN這項服務，其實就是AWS替你架好OpenVPN，誰拿到權限就能自己開自己的VPN入口。對攻擊者或者偏重自主彈性的使用者，也許是挺方便快速的一種選擇；但如果公司原本管控嚴格，也可能變成旁門左道，被人繞過既有安全檢查。不過業界看法不一，有人覺得只是多了一層可選工具而已啦。
恭喜完成！現在你已經具備VPC攻防基礎能力
有些公司會讓用戶自己動手去調整他們VPN的登入方式，像是可以選擇憑證共用、AWS自家的單一登入服務，或者AWS託管的微軟AD。這幾種作法裡面，雙重驗證、帳號管理還有記錄查詢那些事情，其實就不再由傳統IT部門掌控，而是交給那個負責AWS帳號的團隊。這樣一來，如果設置得不太妥當，Client VPN就可能會出現一些安全或合規上的風險。
如果要找一下你帳號裡設定好的VPN，那個客戶閘道器的IP位址，大致看起來像是一串數字，假如有看到什麼198開頭…後面好幾碼，就是那個東西。在VPC儀表板裡點進去找虛擬私人網路，再看看「客戶閘道器」那邊應該就能看到。
然後問到VPC Peering連線用來導流量的目標前綴碼，好像都會帶著個pcx-開頭。這部分蠻一致的，如果在介面上滑一下應該很容易發現。
說到最後一題嘛，其實也沒真正在問什麼內容，只是要你表態已經準備好繼續下一步了，所以基本上不用填答案。
對了，有人可能已經連續在TryHackMe刷題超過一年，也累積了一大堆分數與徽章，在全球排行也許排在兩百多名左右，在巴西區甚至挺靠前。有時候系統畫面還會跳出一些慶祝的小圖案提醒你戰績。不過這只是參考啦，每個人的狀況都不同。有興趣學更多雲端和資安相關知識，也許可以逛逛作者在Medium、GitHub或LinkedIn分享的新文章。而這些練習與內容主要都是TryHackMe和某位創作者花時間準備出來的——他們願意投入心力，大家就能試著提升自己的技能了。
如果要找一下你帳號裡設定好的VPN，那個客戶閘道器的IP位址，大致看起來像是一串數字，假如有看到什麼198開頭…後面好幾碼，就是那個東西。在VPC儀表板裡點進去找虛擬私人網路，再看看「客戶閘道器」那邊應該就能看到。
然後問到VPC Peering連線用來導流量的目標前綴碼，好像都會帶著個pcx-開頭。這部分蠻一致的，如果在介面上滑一下應該很容易發現。
說到最後一題嘛，其實也沒真正在問什麼內容，只是要你表態已經準備好繼續下一步了，所以基本上不用填答案。
對了，有人可能已經連續在TryHackMe刷題超過一年，也累積了一大堆分數與徽章，在全球排行也許排在兩百多名左右，在巴西區甚至挺靠前。有時候系統畫面還會跳出一些慶祝的小圖案提醒你戰績。不過這只是參考啦，每個人的狀況都不同。有興趣學更多雲端和資安相關知識，也許可以逛逛作者在Medium、GitHub或LinkedIn分享的新文章。而這些練習與內容主要都是TryHackMe和某位創作者花時間準備出來的——他們願意投入心力，大家就能試著提升自己的技能了。
