##はじめに

AWSのNetwork Load Balancer（NLB）について調べていた際に、

「NLBはクライアントからの通信をEC2へ転送するが、戻りの通信はNLBを通らない」

という話を耳にしました。
ロードバランサーを経由しているにも関わらず、戻り通信だけが別経路になるという話に興味を持ち、実際にEC2上で通信を確認しながら調査してみました。

環境

今回調査をした構成に関しては、以下の通りです。

  User
   ↓
　NLB
 　↓
  EC2

NLBのターゲットグループはEC2を登録しており、Client IP Proservationが有効な状態でした。

検証

EC2上での通信を確認するとヘルスチェックに関しては、NLBのIPアドレスから送られてきていました。
しかし、実際にSSHを用いてダミーの通信を行うとEC2の通信ログは

送信元:クライアントグローバルIP
送信先:EC2

つまり、EC2側でNLBのIPではなく、クライアントにグローバルIPが確認できました。
そのため、

User → NLB →　EC2

EC2 → User

のように戻りの通信だけNLBを経由していないのではないかと考えました。

調査結果

実際に帰りの通信はEC2 → Userになっていたので、その通りなのかと改めて調べた結果

EC2からの戻り通信はNLBをスキップしているわけではありませんでした。

原因はNLBのClient IP Preservation機能でした。

Client IP Preservationとは

Client IP Preservationは、NLBからターゲットグループへ転送する際に、元のクライアントIPアドレスを保持する機能になります。

通常のロードバランサーではバックエンドサーバーに転送する際に転送元IPアドレスを書き換えることがあります。
しかし、NLBでClient IP Preservationが有効の場合には、EC2に到達するパケットの送信元IPはNLBでなく、実際のクライアントIPアドレスになります。

なのでEC2では

230.xx.xx.xx → EC2

のようにクライアントの実IPを確認できます

なぜ戻り通信が直接通信に見えるのか

EC2から見ると、接続相手はくクライアントIPアドレスです。

なので戻り通信に関しても

EC2 → User

へ送信しているように見えます。

ですが、これは

EC2からクライアントIPが見えている
だけで、
NLBを経由しないで通信している
ことを意味しているわけではないです。

AWSのNLBは接続を管理しており、Client IP Preservationを有効にしていても、通信はNLBの動作中で処理されています。

なので、

クライアントIPが見える = NLBをバイパスしている

というわけではありません。

補足

AWSでは、基本的に利用しない機能として、DSR(Direct Server Return)といった機能があるがこちらは、「戻り通信をLBを完全に通さない」仕組みになっている機能があるのですが、AWSよりもAzure Load Balancer,LVS,A10,F5 BIG-IPなどでよく使われる機能になります。

まとめ

今回の調査で得られた結論は以下の通りです。

EC2でクライアントIPが見えていたのはClient IP Preservationによるもの
Client IP Preservationは通信経路を変更する機能ではない
NLBからターゲットへ転送する際にクライアントIPを保持する機能である
戻り通信がNLBを経由せず直接クライアントへ送信されているわけではない

EC2でクライアントIPが見えると「NLBをバイパスして通信しているのでは？」と勘違いしやすいですが、実際にはClient IP Preservationによる見え方の違いだった、というのが今回の調査結果でした。