web-dev-qa-db-ja.com

Amazon EC2：OpenVPNサーバーはブリッジパケットをクライアントからVPCサブネットにルーティングしません

Amazon EC2VPCのLinuxサーバーにブリッジされたOpenVPNセットアップがあります。 （ドキュメントに何時間も費やし、同様の問題を読んでいます。ここでは、openVPNフォーラムですが、まだ運がありません。）

ブリッジインターフェースは稼働しており、両方のサブインターフェースが含まれています。

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0e7c15e787b0       no              eth0
                                                        tap0

VPNサーバーでのルーティングは明らかに問題ありません。 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

I can WindowsクライアントとMacクライアントの両方からVPNサーバーのIPにpingを実行しますが、VPCサブネット上の他のIPにはpingを実行しません。 （これらの他のIPは問題ありません。VPNサーバーからping可能です。）

ブリッジインターフェイスでtcpdumpしたときbr0VPNサーバー上でそれ見る Windowsクライアントからの「ARPwho-has」リクエスト。ただし、VPCサブネットには入りません！宛先IPのtcpdumpは、ARPの到着を認識しません。 Windowsのarpキャッシュは埋められないままです。 （10.0.0.128はWindowsクライアント、10.0.0.58はVPNサーバー、10.0.0.180はサブネット上の他のIP、以下の出力はVPNサーバーからのものです。）

root@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

[コオロギ]

ソース/宛先を無効にしました。 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             anywhere

https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

私はしませんthink認証、証明書、圧縮、アドレスプール、接続設定など、明らかに多くのことが機能しているため、完全な構成をダンプする必要があります。 Amazon VPCは単にパケットの転送を拒否しますか？これを行うには、実際には仮想クラウドを使用する必要がありますか？

翌日のその他の実験：VPCは明らかに真のレイヤー2サブネットのように動作していません。特に、ARP who-has放送は実際には放送されません！存在しないIP（たとえば.5）を.180からpingすると、.58は要求を認識しません。 VPCは明らかにARPブロードキャストを最適化し、それを.5にのみ送信しています管理コンソール/ APIを介してVPCで.5が設定されている場合。去るtcpdump -vv -i eth0 arpしばらくの間、すべてのホストについて、ホストとゲートウェイ間のトラフィックのみが表示されます。

さらに、サブネット上のブロードキャストアドレスへのpingはまったく機能しません。これは、Amazon VPNFAQによってバックアップされています。

そのため、VPCは、独自の「仮想イーサネットスイッチ」に存在しないため、不明なMACアドレス.129の認識を拒否している可能性があります。私はおそらくこれを1週間かそこらで答えとしてシフトするでしょう。独自のVPNでVPCを拡張するには、正式な「VPCゲートウェイ」を経由する必要があります。これは、ローミングラップトップのシナリオではなく、専用のハードウェアルーターと静的IPに裏打ちされた企業イントラネットの拡張としてのみ機能するように設計されています。 mを目指しています。

linuxamazon-ec2iptablesopenvpnbridge
4
BaseZen

VPNはブリッジではなくルーティングされる必要があり、VPNクライアントが存在するサブネットはVPCスーパーネットの境界外にある必要があります。

次に、VPNクライアントサブネットの静的ルートをVPCルーティングテーブルに追加します。そのルートの宛先は、vpnサーバーインスタンスのインスタンスIDとして指定されます。

VPCネットワークは、仮想のソフトウェア定義ネットワークです。これは純粋なレイヤー2ネットワークではありませんが、ほとんどの点で、非常にうまくエミュレートします。ただし、ブロードキャストはそのような方法の1つではありません。

お気づきのように、あるインスタンスから別のインスタンスへのARPトラフィックの1：1の相関関係はありません。 ARPへの応答who-hasは、IPが割り当てられたインスタンスからのものではありません。それはネットワークから来ています。宛先インスタンスが実際に着信リクエストを認識している場合、送信したリクエストは実際には認識されていません。

VPCは、かなり説得力のある理由、スケーラビリティ、セキュリティのためにこのように設計されました。

VPCのスーパーネットのスコープ内のIPアドレスがインスタンス上にあると予想されるという事実は、これの副作用です。利用可能なハードウェアVPNソリューションを使用している場合でも、そのリンクの反対側にあるVPCスーパーネット内にプライベートアドレスを設定することはできません...したがって、これは追加料金を支払うために組み込まれた制限ではありません...これは設計の一部にすぎません。

推奨される表示：VPC/A Day in the Life of a Billion Packets（CPN401）

http://m.youtube.com/watch?v=Zd5hsL-JNY4

5
Michael - sqlbot