aws vpc到vpc與openvpn的連接
我在
us-east-1
(VPC1
和VPC2
) 中有 2 個 VPC,並且與 VPC 對等。我在其中執行 openVPNVPC1
以連接到這兩個 vpc。現在我不得不再次在ap-southeast-1
(VPC3
和VPC4
) 中製作 2 個新的 VPC,它們都是 VPC 配對的。我按照本教程設置us-east-1
和ap-southeast-1
(連接VPC1
的和VPC3
)之間的連接。我現在能夠連接到 中的所有實例VPC1
,VPC2
但VPC3
無法連接到VPC4
. 我只能VPC4
從VPC3
. 我openvpn
在 VPC1(ovpn1
和ovpn2
)中有兩個實例。ovpn1
用於從我的辦公室連接並ovpn2
連接到openvpn
正在執行的第三個實例VPC3
.VPC4
我已經驗證了in 的路由表us-east-1
,它看起來很好。這也是我在 ovpn 實例上的路由表
VPC1
。Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 * 255.255.240.0 U 0 0 0 eth0 10.2.0.0 169.254.255.2 255.255.0.0 UG 0 0 0 tun0 10.3.0.0 169.254.255.2 255.255.255.0 UG 0 0 0 tun0 169.254.255.2 * 255.255.255.255 UH 0 0 0 tun0
VPC CIDR 塊如下
VPC1 -> 10.0.0.0/16 VPC2 -> 10.2.0.0/16 VPC3 -> 10.3.0.0/24 VPC4 -> 10.1.0.0/16
我錯過了什麼連接
VPC4
對等連接不支持跨 VPC 傳輸路由 IP 流量。
對等連接不會為您提供與 VPN 或您可能熟悉的其他網路到網路互連所期望的相同級別的連接。
考慮文件中的這個例子(為了清楚起見,進行了輕微的重新格式化),誠然,它並沒有準確地描述你的情況,但有助於理解手頭的更大問題。
pcx-aaaabbbb
您在 VPC A 和 VPC B ( ) 之間以及在 VPC A 和 VPC C ( )之間有一個 VPC 對等連接pcx-aaaacccc
。VPC B 和 VPC C 之間存在 VPC 對等連接。
您不能通過 VPC A 將數據包直接從 VPC B 路由到 VPC C。
這是 VPC 對等設計的一部分——它是一個僅影響兩個 VPC 中的實例的功能——它們可以相互訪問。VPC 中的其他資源,例如 NAT 和 Internet 網關、VPC 服務端點(用於 S3)、Direct Connect 和硬體 VPN 不會通過對等互連公開。
tl;dr:VPC 對等不支持直接對等 VPC 中 EC2 實例之外的任何 IP 路由或連接。
因此,上面的解釋並不是一個完美的解釋,因為在記錄的範例中,所有三個 VPC 當然都在同一個區域中,但類似的原則適用於您的配置。
問題不在於 VPC-1 無法通過通往 VPC-3 的隧道到達 VPC-4(流量可能到達也可能不到達),而是 VPC-4 絕對沒有辦法發送回复。VPC-4 無法在 VPC-3 到 VPC-3 (VPC-1) 外部的途中傳輸 VPC-3。
同樣,這也是我提出關於 VPC-2 和 VPC-3 之間連接性問題的動機。VPC-2 無法在訪問 VPC-3 中的地址的途中傳輸 VPC-1。
發往遠端網路的傳入流量永遠不會到達隧道伺服器,因為沒有跨 VPC 傳輸的機制,並且到隧道伺服器的流量(儘管可能沒有明確記錄)仍然是傳輸的情況。
如果您在 VPC-1 和外部公司數據中心之間有一個 VPC 硬體 VPN,您也會遇到同樣的問題。無論是否有任何對等互連,該 VPN 連接都不會提供從外部數據中心到 VPC-1 邊界之外的任何東西的訪問。AWS Direct Connect 也是如此。
僅從 API/Console 介面的角度分析這一點,考慮如何通過對等連接發送流量:您通過使用對等連接 ID 作為目標創建路由表條目來創建將外部 IP 前綴從一個 VPC 發送到另一個 VPC 的路由.
但是當該流量到達對等 VPC 時會發生什麼?它應用了哪個路由表?
這是一個棘手的問題,因為沒有公開的路由表適用於通過 VPC 對等連接傳入的流量——該傳入流量唯一可用的路由是使實例可訪問的隱式本地路由。
發往實例(或在實例上執行的服務,如 RDS)以外的流量——當它到達對等 VPC 時——無處可去,並被丟棄。
合理的解決方法是嘗試通過對等連接將流量路由到充當路由器的實例…與將流量路由到 NAT 實例的方式非常相似——通過將路由表中的目標設置為實例-id 或其關聯的彈性網路介面 (ENI)。
在上面提到的文件頁面的底部,我們發現了這樣一個練習的一句話限制:
同樣,如果 VPC A 有一個 NAT 設備為 VPC A 中的私有子網中的實例提供 Internet 訪問,則 VPC B 中的實例無法使用 NAT 設備訪問 Internet。
對於不熟悉典型 VPC 配置的人來說,這可能不太清楚,但這種限制實際上更準確地解釋了為什麼原始問題中提出的配置不起作用。
您可以通過在子網的路由表中創建路由來配置子網以使用 NAT 實例,以將特定的外部前綴(通常為 0.0.0.0/0,但它可能是一個子集)發送到實例本身或其彈性網路介面,憑身份證。
但在區域內,如果您嘗試通過路由表將流量路由到對等 VPC 中實例的 ENI,則會失敗:
Error: route table rtb-xxxxxxxx and interface eni-xxxxxxxx belong to different networks (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue; Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
因此,直覺的解決方法也不可用。
我能找到的唯一三個解決方案是:
- 更多隧道,就像您已經在 VPC-1 和 VPC-3 之間建立的一樣。您基本上需要在所有需要交換流量的 VPC 之間建立一個完整的 OpenVPN(或其他隧道解決方案),而不是您已對等的 VPC。這是我實施的解決方案。在每個可用區中,我都有一個 OpenVPN 伺服器,該伺服器具有通往國外所有其他可用區的隧道。您不一定需要為每個可用區提供一個 - 每個 VPC 只需一個即可滿足要求,但每對可用區之間的隧道將提供彈性,防止由於失去一個可用區而隔離整個 VPC。
- 來自隧道伺服器的源 NAT。 這個太亂了。您在 VPC-1 和 VPC-3 之間有一條隧道,並且 VPC-3 與 VPC-4 對等,因此您可以通過 VPC- 中的 VPC 路由表將流量從 VPC-1 路由到 VPC-1 中的隧道伺服器1,然後通過隧道將其發送到 VPC-3,在那裡它可以通過
iptables
配置假定 VPC-3 中隧道實例的源 IP 地址。VPC-3 中的隧道機器可以在 VPC-4 中訪問的任何內容都將可以被 VPC-1 中允許訪問隧道伺服器的任何內容訪問。- VPC-3 中的服務代理或 NAT 伺服器,可從 VPC-1 訪問,它們要麼對 TCP 連接進行第 4 層轉發,要麼對 VPC-1 地址和 VPC-4 地址之間的流量進行源和目標 NAT,以便 VPC-4 看到流量來自 VPC-3 地址,VPC-1 看到流量來自 VPC-3 地址。這與上述類似,但通過安全組提供了更好的訪問控制,因為它不是前一個選項所需的全有或全無訪問……但仍然是一個混亂的解決方案。
最乾淨的配置將是所有 VPC(或所有可用區,同一 VPC 內的可用區或任何直接對等的可用區除外)之間的全網狀隧道。