ELBはAWSのアウトバウンド応答トラフィックもルーティングしますか


8

パブリック/プライベートサブネットを持つAWS VPCでルーティングがどのように機能するかを理解しようとしています。

パブリックサブネットにELBとNATがあり、プライベートサブネットにWebサーバーがある、Amazonの推奨するセットアップがあります。http://blogs.aws.amazon.com/security/blog/tag/NATに従ってセキュリティグループ(SG)を構成しましたが、すべて期待どおりに機能します。すごい!

Amazon VPC構成のリファレンスアーキテクチャ

私がまだ理解していないのは、上記のアーキテクチャでHTTP応答がWebサーバーインスタンスからどのように返されるかです。

したがって、HTTP経由でパブリックインターネットからWebリクエストが送信され、80がELBにヒットし、ELBはそれをWebサーバーのプライベートIPに転送します。これで、Webサーバーは応答する必要があります。私が理解していることから、応答は別の上位TCPポート(1024〜65535)を介して行われます。NAT SGは、ポート80および443を介した送信トラフィックのみを許可します。したがって、この応答はどのようにしてパブリックインターネットに戻されますか。NATを通過できません。これは、ELBを介して応答が戻ることを意味しますか?Amazonの図では、ELBトラフィック方向の矢印が双方向であることを示しておらず、ELBのドキュメントには、ELBがステートフルNATのように動作することが記載されていません。そうですか?

回答:


11

図の矢印は、トラフィックフローではなく、接続確立の方向のみを示しています。

はい、戻りトラフィックはELBを経由します。

ただし、これはステートフルNATではなく、TCP接続プロキシです。ELBマシンは、構成されたリスニングポートでTCP接続を受け入れ、構成されている場合はSSLセッションを終了し、バックエンドサーバーへの新しいTCP接続を確立します。リスナーがHTTP用に構成されている場合、ELBはペイロード認識モードで動作し、HTTPリクエストを解析、ロギング、およびバックエンドに転送します。それ以外の場合は、ペイロードに依存せず、新しいTCP接続を1:1でバックエンドに確立します着信接続ごとに、「パイプを結びつける」(HTTPレベルの認識または変更なし)。

どちらの方法でも、アプリケーションへの着信接続のソースアドレスは、元のクライアントではなく、ELBノードのソースアドレスになります。これは、クライアントに戻るために応答トラフィックがELBに戻る方法です。

httpモードでは、ELBはX-Forwarded-Forヘッダーを追加(または追加)するため、アプリケーションは元のクライアントIPを識別できるだけでなくX-Forwarded-Proto: [ http | https ]、クライアント接続がSSLを使用するかどうかX-Forwarded-Portを示し、フロントエンドポートを示します。


更新:上記は、「ELBクラシック」またはELB / 1.0として現在知られているタイプのロードバランサーを指します(HTTPヘルスチェックで送信するユーザーエージェント文字列にあります)。

新しいレイヤー7バランサー、Application Load BalancerまたはELB / 2.0は、トラフィックフローに関して同様に動作します。レイヤー4(「透過」TCP)機能はALBから削除され、レイヤー7機能が大幅に強化されました。

最新タイプのロードバランサーであるネットワークロードバランサーは、レイヤー3バランサーです。他の2つとは異なり、これは動的NATと非常によく似ており、インバウンド(外部発信)接続のみを処理し、EIP-addr + portを介してsource-addr + portをinstance-private-ip:adde + portにマッピングします-EIPを使用「バランサー」にバインドされています。他の2種類のバランサーとは異なり、インスタンスはパブリックサブネット上にあり、独自のパブリックIPを使用する必要があります。

概念的には、ネットワークロードバランサーはインターネットゲートウェイの動作を実際に変更しているようです。つまり、それ自体は無効にしたり、置き換えたり、意味のある意味で障害を経験したりできない論理オブジェクトです。これは、「非表示」のEC2インスタンスで実際に動作するELBおよびALBとは対照的です。NLBは、すべての外観でネットワークインフラストラクチャ自体で動作します。


ありがとう。ペイロード認識、ペイロード非依存のモードについて詳しく教えてください。また、元の接続がSSL経由であったかどうかをウェブサーバーで確認できますか?
Ali

これらのポイントに対処するために、回答にいくつかの追加情報を追加しました。
マイケル-sqlbot

and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this. これを読んでとてもうれしい。この情報への参照を提供できますか?
フェリペアルバレス

1
結局のところ、@ FelipeAlvarezは全体像がかなり複雑です。これは最も直感的な構成ですが、Network Load Balancerは実際のネットワークインフラストラクチャと統合されており、ターゲットインスタンスからTCPストリームを(おそらくネットワークステートテーブルを介して)キャプチャし、それらを書き換えて期待どおりに機能させることができます。インスタンスはこのように構成されていません。ターゲットインスタンスには、VPCで宣言されたデフォルトルートが必要です。これは、リターンパケットでは無視されますが、まだ存在している必要があります。デフォルトルートがないと、ブラックホールが発生します。
マイケル-sqlbot 2018年

1

NLBのAWSドキュメントによると、それはレイヤー3ではなくレイヤー4です。また、バックエンドまたはターゲットサーバーはパブリックサブネット上にある必要はありません。実際には、ターゲットグループのIPアドレス範囲は、次のいずれかである必要があります。可能なターゲットタイプは次のとおりです。

インスタンスターゲットはインスタンスIDで指定されます。

ipターゲットはIPアドレスで指定されます。

ターゲットタイプがipの場合、次のCIDRブロックのいずれかからIPアドレスを指定できます。

ターゲットグループのVPCのサブネット

10.0.0.0/8(RFC 1918)

100.64.0.0/10(RFC 6598)

172.16.0.0/12(RFC 1918)

192.168.0.0/16(RFC 1918)

重要

パブリックにルーティング可能なIPアドレスを指定することはできません。

これがお役に立てば幸いです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.