HOME»応用情報技術者試験掲示板»平成30年秋期 午後問5 設問1について
投稿する
アプライアンス製品のロードバランサだと、ツーアーム構成を取れることが多く、Webサーバのデフォルトゲートウェイがロードバランサになるのが一般的です。その場合、基本的には送信元IPアドレスを変換しなくてもWebサーバ等に転送したパケットはロードバランサ自身に戻ってきます。
そうすると、ロードバランサがコネクションを管理することが可能になります。
一方、今回の問題のような、ワンアーム構成だと、WebサーバのデフォルトゲートウェイがL3SWになってしまい、送信元IPアドレスを変換しない限り、直接クライアントに戻ってしまいます。
そうなると、ロードバランサもコネクション管理ができない、クライアントも送信元IPアドレスがWebサーバのパケットが届くので破棄する…という不具合が発生します。
こうした不具合を解消するため、送信元IPアドレスを変換するか(SNATと呼ばれたりします)、宛先IPアドレスを仮想IPアドレスに変換する(DSR方式の一部)機能が、負荷分散装置には実装されています。
今回の問題では、前者送信元IPアドレスを変換することで、負荷分散した通信を自分に戻るようにする機能が使われていると考えて間違いないと思います。
お二人とも丁寧に回答いただき、ありがとうございます。
モヤモヤが晴れました。
ありがとうございました。
»[3155] 平成30年秋期 午後問6について 投稿数:5
»[3154] 令和3年度春期午後問5 設問1(2)について 投稿数:4
平成30年秋期 午後問5 設問1について [3157]
ロメオさん(No.1)
ロードバランサについての問題です。
クライアン → ロードバランサ → webサーバで、
ロードバランサ → webサーバの通信は、
送信元ip;クライアント、宛先IP;webサーバ
だと思っていましたが、回答では、
送信元ip;ロードバランサ、宛先IP;webサーバ
となっています。ネットワークの書籍を確認しましたが、
送信元ipがロードバランサに付け替えられるという記述はありませんでした。
こういう機能も存在するのでしょうか。
教えてください。
クライアン → ロードバランサ → webサーバで、
ロードバランサ → webサーバの通信は、
送信元ip;クライアント、宛先IP;webサーバ
だと思っていましたが、回答では、
送信元ip;ロードバランサ、宛先IP;webサーバ
となっています。ネットワークの書籍を確認しましたが、
送信元ipがロードバランサに付け替えられるという記述はありませんでした。
こういう機能も存在するのでしょうか。
教えてください。
2022.02.20 12:10
GinSanaさん(No.2)
★AP プラチナマイスター
クライアントがアクセスするので設定した宛先は最初はどのサーバに振り分けられるのかわからんわけですから、仮想IPを与えたロードバランサに通信を仕向けてからロードバランサが決めたサーバのIPに書き換えますよね。
docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-target-groups.html
Network Load Balancers のターゲットグループ
docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-target-groups.html
Network Load Balancers のターゲットグループ
ロードバランサーは、データパケットの宛先 IP アドレスを書き換えてから、ターゲットインスタンスに転送します。
2022.02.20 15:07
GinSanaさん(No.3)
★AP プラチナマイスター
質問が送信元IPの話だったのを忘れていました。
IDCFクラウド | ネットワーク
ロードバランサー経由のHTTPアクセスについて、アクセス元のIPアドレスは確認できますか?
IDCFクラウド | ネットワーク
ロードバランサー経由のHTTPアクセスについて、アクセス元のIPアドレスは確認できますか?
ロードバランサーを経由すると、送信元のIPアドレスがロードバランサーのプライベートIPアドレスに変換されます。
2022.02.20 15:41
GinSanaさん(No.4)
★AP プラチナマイスター
図解がないのでなんとなく参考が不親切なので、
www.infraexpert.com/study/loadbalancer11.html
XFF ( X-Forwarded-For )
の構成を参考にしてください。
www.infraexpert.com/study/loadbalancer11.html
XFF ( X-Forwarded-For )
の構成を参考にしてください。
2022.02.20 15:55
犬。さん(No.5)
>ロメオさん、GinSanaさん
アプライアンス製品のロードバランサだと、ツーアーム構成を取れることが多く、Webサーバのデフォルトゲートウェイがロードバランサになるのが一般的です。その場合、基本的には送信元IPアドレスを変換しなくてもWebサーバ等に転送したパケットはロードバランサ自身に戻ってきます。
そうすると、ロードバランサがコネクションを管理することが可能になります。
一方、今回の問題のような、ワンアーム構成だと、WebサーバのデフォルトゲートウェイがL3SWになってしまい、送信元IPアドレスを変換しない限り、直接クライアントに戻ってしまいます。
そうなると、ロードバランサもコネクション管理ができない、クライアントも送信元IPアドレスがWebサーバのパケットが届くので破棄する…という不具合が発生します。
こうした不具合を解消するため、送信元IPアドレスを変換するか(SNATと呼ばれたりします)、宛先IPアドレスを仮想IPアドレスに変換する(DSR方式の一部)機能が、負荷分散装置には実装されています。
今回の問題では、前者送信元IPアドレスを変換することで、負荷分散した通信を自分に戻るようにする機能が使われていると考えて間違いないと思います。
2022.02.21 09:55
ロメオさん(No.6)
>GinSanaさん、犬。さん
お二人とも丁寧に回答いただき、ありがとうございます。
>ワンアーム構成だと、WebサーバのデフォルトゲートウェイがL3SWになってしまい、送信元IPアドレスを変換しない限り、直接クライアントに戻ってしまいます。
モヤモヤが晴れました。
ありがとうございました。
2022.02.21 10:38
その他のスレッド
»[3156] 令和3年春期午後問5設問3(1)について 投稿数:18»[3155] 平成30年秋期 午後問6について 投稿数:5
»[3154] 令和3年度春期午後問5 設問1(2)について 投稿数:4