##はじめに
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による見え方の違いだった、というのが今回の調査結果でした。