Amazon EC2：OpenVPN 伺服器不會將橋接數據包從客戶端路由到 VPC 子網
我在 Amazon EC2 VPC 中的 Linux 伺服器上設置了橋接 OpenVPN。（花了幾個小時在文件上，閱讀類似的問題，在這裡，openVPN 論壇，還沒有運氣。）
橋接介面已啟動並包含兩個子介面：
# brctl show bridge name bridge id STP enabled interfaces br0 8000.0e7c15e787b0 no eth0 tap0VPN伺服器上的路由顯然沒問題；我可以通過 SSH 連接、ping 通、響應來自客戶端的 VPN 請求：
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 br0 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0我可以從 Windows 和 Mac 客戶端 ping 到 VPN 伺服器的 IP，但不能 ping 到 VPC 子網上的任何其他 IP。（其他 IP 沒問題；它們可以從 VPN 伺服器 ping 通。）
當我在VPN 伺服器
tcpdump上的網橋介面上時，它會看到來自 Windows 客戶端的“ARP who-has”請求。但是它們不會進入 VPC 子網！在目標 IP 上看不到 ARP 到達。Windows arp 記憶體仍未填充。（10.0.0.128 是 Windows 客戶端；10.0.0.58 是 VPN 伺服器；10.0.0.180 是子網上的另一個 IP；下面的輸出來自 VPN 伺服器。）br0``tcpdumproot@vpn:# tcpdump -i br0 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes 21:00:21.092367 ARP, Request who-has 10.0.0.180 tell 10.0.0.128, length 28$$ crickets $$ 我已禁用源/目標。檢查 VPN 伺服器唯一網路介面上的 EC2 控制台。
我已經按照橋接 HOWTO 中的建議設置了 IP 表，並且通常完全按照這些說明進行操作。
# iptables -L INPUT -v Chain INPUT (policy ACCEPT 9 packets, 1008 bytes) pkts bytes target prot opt in out source destination 38 12464 ACCEPT all -- tap0 any anywhere anywhere 10447 1297K ACCEPT all -- br0 any anywhere anywhere # iptables -L FORWARD -v Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 918 167K ACCEPT all -- br0 any anywhere anywherehttps://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
我認為我不需要轉儲完整的配置，因為顯然很多工作都在起作用：身份驗證、證書、壓縮、地址池、連接設置。Amazon VPC 是否只是拒絕轉發數據包，而我真的應該在一個稍微不那麼虛擬的雲上來執行此操作？
第二天的更多實驗：VPC 顯然不像真正的第 2 層子網。特別是，ARP
who-has廣播實際上並不廣播！當我從 .180 ping 一個不存在的 IP（比如 0.5）時，.58 看不到請求。如果已通過管理控制台/API 在 VPC 中配置了.5，則 VPC 顯然正在優化 ARP 廣播並將其僅發送到 .5 。保留tcpdump -vv -i eth0 arp一段時間僅顯示所有主機的主機和網關之間的流量。此外，ping 子網上的廣播地址根本不起作用。這得到了 Amazon VPN 常見問題的支持。
因此 VPC 可能拒絕辨識 .129 的未知 MAC 地址，因為它不存在於它自己的“虛擬乙太網交換機”中。我可能會在一周左右的時間內將此作為答案。要使用您自己的 VPN 擴展 VPC，它必須通過正式的“VPC 網關”，該網關僅設計為由專用硬體路由器和靜態 IP 支持的公司 Intranet 的擴展，而不是漫遊筆記型電腦場景 I’米的目標。
您的 VPN 需要路由，而不是橋接，並且您的 VPN 客戶端所在的子網必須在 VPC 超網的範圍之外。
然後，您在 VPC 路由表中為 VPN 客戶端子網添加一個靜態路由，該路由的目標指定為您的 vpn 伺服器實例的實例 ID。
VPC 網路是一個虛擬的、軟體定義的網路。它不是一個純粹的第 2 層網路，但在大多數方面，它可以很好地模擬一個。然而，廣播並不是其中一種方式。
如果您注意到，從一個實例到另一個實例的 ARP 流量並沒有 1:1 的相關性。您對 ARP 的響應
who-has並非來自分配了 IP 的實例。它來自網路。如果目標實例實際看到傳入的請求，它實際上並沒有看到您發送的請求。VPC 以這種方式設計是出於一些非常令人信服的原因，其中包括可擴展性和安全性。
VPC 超網範圍內的 IP 地址預計會出現在實例上，這一事實只是其副作用。即使您使用可用的硬體 vpn 解決方案，您仍然不能在該連結另一側的 VPC 超網中擁有私有地址……所以這不是一個限制讓您支付額外費用……這只是設計的一部分。
推薦觀看：VPC/十億包生命中的一天（CPN401）