今回紹介するのはロードバランサーがぶら下がっているグループ間の話しです。
サーバーAから、サーバーB,Cにある仮想IPへアクセスする場合に必要となります。
もちろん実IPを使用する場合には必用ありません :x001:
なぜソースNATをしていないければ通信できないか
サーバーAから、サーバーC,Dに設定してある仮想IPへアクセスする場合の流れ
①サーバーAから仮想IP:20.10へ
パケットの送信元IP:10.1 送信先IP:20.10
②仮想IP:20.10からサーバーCへ振り分けられたとする
パケットの送信元IP:10.1 送信先IP:20.1
③サーバーCからサーバーAへ
パケットの送信元IP:20.1 送信先IP:10.1 ←直接サーバーAへ戻っている!
①サーバーAから仮想IP:20.10へ
パケットの送信元IP:10.1 送信先IP:20.10
②仮想IP:20.10からサーバーCへ振り分けられたとする
パケットの送信元IP:10.1 送信先IP:20.1
③サーバーCからサーバーAへ
パケットの送信元IP:20.1 送信先IP:10.1 ←直接サーバーAへ戻っている!
サーバーCからサーバーAへの戻りで、直接サーバー間へのルートになってしまい、仮想IP(ロードバランサー)がスキップされています。
このためデータ通信ができなくなるのです。
これは、同じネットワーク(セグメント)にサーバーがあるワンアームと呼ばれる構成の場合に、同じセグメントに属するサーバーのバーチャルホストに向けて通信をしようとした場合に発生します。
本当はロードバランスのために仮想IPを経由しているのですが、同じネットワークに属するために、送信元IPが変更されないのです。
そのためパケットの戻りが直接送信元サーバーへ帰ってしまうのです。
ソースNATを使うと
サーバーAから、サーバーC,Dに設定してある仮想IPへアクセスする場合の流れ
①サーバーAから仮想IP:20.10へ
パケットの送信元IP:10.1 送信先IP:20.10
②仮想IP:20.10からサーバーCへ振り分けられたとする
パケットの送信元IP:20.10 送信先IP:20.1
③サーバーCから仮想IP:20.10へ
パケットの送信元IP:20.1 送信先IP:20.10
④仮想IP:20.10からサーバーAへ
パケットの送信元IP:20.10 送信先IP:10.1
①サーバーAから仮想IP:20.10へ
パケットの送信元IP:10.1 送信先IP:20.10
②仮想IP:20.10からサーバーCへ振り分けられたとする
パケットの送信元IP:20.10 送信先IP:20.1
③サーバーCから仮想IP:20.10へ
パケットの送信元IP:20.1 送信先IP:20.10
④仮想IP:20.10からサーバーAへ
パケットの送信元IP:20.10 送信先IP:10.1
行きと帰りのルートが同じになり、無事通信できるはずです。