如何為 SSH 設置 AWS 網路訪問控制列表到私有子網
我正在做關於 AWS 的課程。我想要做的是設置一個帶有兩台 Linux 伺服器的 VPC。我已經設置了具有兩個子網的 VPC。我已經在每個伺服器中放置了一台伺服器。這個想法是一個子網是公共的，另一個是私有的。
我創建了兩個網路 ACL，並與每個子網關聯了一個。
我可以從我的機器通過 SSH 連接到公共子網中的伺服器。當我嘗試從該伺服器通過 SSH 連接到我的私有子網中的伺服器時，我遇到了連接超時。
我不確定我需要在兩個網路 ACL 中設置什麼規則才能使 SSH 正常工作。任何人都可以幫忙嗎？鑑於我正在學習，我會很感激解釋為什麼規則應該是，而不僅僅是規則應該是什麼。
我有一個名為 MyVPC 且 CIDR 10.0.0.0/16 的 VPC
我的第一個子網稱為 MyVPCSub1 CIDR
10.0.1.0/24 我的第二個子網稱為 MyVPCSub2 CIDR 10.0.2.0/24
我有一個名為 MyInternetRoute 的路由表，與 MyVPCSub1 關聯的路由是：
|Dest |Targ | |10.0.0.0/16 |local | |0.0.0.0/0 |igw |我有一個名為 MyPrivate 的路由表，與 MyVPCSub2 關聯的路由是：
|Dest |Targ | |10.0.0.0/16 |local |我有一個名為 MyWeb 的網路 ACL 與 MyVPCSub1 相關聯，其中包含以下規則：
入境：
| # | Type | Protocol | Ports | Source | A/D | 99 | HTTP | TCP | 80 | {My IP}/32 | D | 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A | 200 | HTTPS| TCP | 443 | 0.0.0.0/0 | A | 300 | SSH | TCP | 22 | {My IP}/32 | A | * | ALL | ALL | ALL | 0.0.0.0/0 | D出境：
| # | Type | Protocol | Ports | Source | A/D | 50 | ALL | ALL | ALL | 0.0.0.0/0 | A | 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A | 200 | HTTPS | TCP | 443 | 0.0.0.0/0 | A | 300 | Custom | TCP | 1024-65535 | 0.0.0.0/32 | A | * | ALL | ALL | ALL | 0.0.0.0/0 | D我有一個名為 MyPrivate 的網路 ACL 與 MyVPCSub2 相關聯，其中包含以下規則：
入境：
| # | Type | Protocol | Ports | Source | A/D | 100 | ALL | ALL | ALL | 0.0.0.0/0 | A | * | ALL | ALL | ALL | 0.0.0.0/0 | D出境：
| # | Type | Protocol | Ports | Source | A/D | 100 | ALL | ALL | ALL | 0.0.0.0/0 | A | * | ALL | ALL | ALL | 0.0.0.0/0 | D
首先是定義一些術語的含義。
NACLS - 網路訪問控制列表，是在子網級別應用的無狀態數據包過濾器*。*記住“無狀態”方面很重要，這意味著您需要明確所有進入和離開子網的流量。例如，使用“狀態完整”規則方法（這是 AWS 中的安全組所應用的），您可以簡單地為 SSH 指定 TCP/22 的入站流量，它將自動允許出站流量。對於 NACLS，情況並非如此，您需要在每個方向上指定一個規則以允許流量通過。
安全組 - 這些是狀態完整的規則組，可應用於 VPC 中的一個或多個實例。請注意，它們適用於實例級別。可以將安全組與傳統的全狀態防火牆進行比較，但由於它應用於單個實例級別，因此即使在同一子網中也可以將實例彼此隔離，這很好。而且因為它們是狀態完整的，如果你想允許流量進入伺服器（例如 TCP/22 用於 SSH），你不必擔心創建相應的出站規則，平台會自動處理，所以它們更容易管理——這也意味著出錯的機會更少。
有一個很好的表格比較了這兩者：VPC Security Comparison
該頁面上還有一個很好的圖表，顯示了根據流向應用流量的順序……所以檢查一下。
然後就子網而言，我們有：
公共子網 - 在 AWS 術語中，這只是一個附加了路由表的子網，該路由表通過附加的 Internet 網關具有 0.0.0.0/0 路由
私有子網 - 這是相反的，即它沒有通過連接的 Internet 網關的 0.0.0.0/0 路由。請注意，它仍然可以通過 NAT 網關或您環境中的類似代理擁有 0.0.0.0/0 路由，只是不是直接的。
問題是，當您擁有 NACLS 和安全組時 - 您使用哪個。AWS 將 NACL 描述為“您的 VPC 的可選安全層”。確實，通常安全組就足夠了，它們更靈活並提供相同的保護。以我的經驗，在一些典型的情況下，我看到使用了 NACLS：
- 已知不良行為者的黑洞 - 如果您受到來自特定 IP 範圍的攻擊，只需添加一個完全阻止 IP/子網源的 NACL，這是一種簡單的方法。
- 作為將控制權委派給團隊的一種方式 - 安全團隊應用廣泛的刷 NACL 配置（例如只允許來自受信任的公司網路的流量），然後允許操作/開發團隊配置他們自己的安全組規則。這樣，即使工程師試圖將其實例上的安全組開放到網際網路進行測試，NACL 也會阻止它。您可以使用 IAM 來限制可以修改 NACL 的人員，但授予團隊訪問權限以控制其他所有內容，它可以作為大型環境中錯誤配置錯誤的絕佳後盾。
AWS 還提供了一些關於此處可用的一些配置方案的指導：為您的 VPC 推薦的網路 ACL 規則
雖然我的指導通常是安全組提供適當的保護，更易於理解和配置，並且在其應用程序中更加靈活和精細。NACL 確實為您提供了人為錯誤或更高級配置的額外支持，但對於基本用途，它們通常不使用。因此，我假設為什麼 AWS 將它們稱為“可選”。
我會將 NACL 保留在其預設配置中（允許所有進出流量），而現在專注於安全組，因為使用 NACL 作為第二層只會增加額外的複雜性，這在您的場景中可能不需要。從學習的角度來看，很高興知道它們在那裡，它們是無狀態的，它們適用於子網級別，並且它們在路由決策之後和安全組之前應用於進入子網的流量。
關於您的具體情況，因為您使用的是 NACL，所以您需要記住它們是無狀態的。因此，需要考慮進出子網的所有流量——這就是安全組如此簡單的主要原因。所以在你的情況下，你有：
- 從您的 IP 到 TCP/22 上的公共伺服器的流量 - 是的 - 規則 #300 入站
- 在返回 SSH 流量的高埠上從公共伺服器返回流量 - 是的 - 規則 #50 出站（但不是規則 #300 - 見下文）
- 在 TCP/22 上從您的公共子網出站到您的私有子網的流量 - 是的 - 規則 #50 出站
- 來自公共網路的私有子網上的入站流量 - 是的 - 規則 #100 入站
- 將流量從您的私有伺服器返回到私有子網上的公共伺服器 - 是的 - 規則 #100 出站
- 將流量從您的私有伺服器返回到公共子網上的公共伺服器 - 啊 - 不，沒有規則允許高埠（ssh 客戶端在公共伺服器上使用的臨時埠來啟動到私有伺服器的連接）返回從私人伺服器進入。
您需要在您的出站公共子網 ACL 上添加一條類似規則 #300 的規則（但請注意，您的源 IP 格式稍有錯誤 - 見下文），但在綁定時，與私有子網的源一起使用。然後假設您的安全組配置良好，那麼您應該一切順利。
希望有幫助。
要添加 - 根據其他答案 - 公共子網的出站規則集上的規則 #300 格式錯誤。它應該是 0.0.0.0/0 而不是 0.0.0.0/32，但是在您的情況下，您並沒有達到這一點，因為第 50 條規則首先被擊中並且無論如何都允許所有流量 - 所以雖然它不起作用，但它是’實際上並沒有導致你的問題。