CentOS7でipvsadmを用いたロードバランサーを構築したい

前提・実現したいこと

以下のサイトを参照してCentOS7でLVSを使用したロードバランサーを構築しました。
VirtualBox+CentOS7でロードバランサ構築

しかし、自端末（ホストOS）のブラウザからLBのアドレス（192.168.211.10）にアクセスしてもレスポンスが返ってきません。
どうすれば、LBのアドレスに接続して、Webサーバからのレスポンスを得られるようになりますか？

切り分け

上記サイトと同じく、LBにはipvsadminだけ導入し、keepalivedは導入していません。
Webサーバ１，２はnginxで動かしています。
Webサーバに直接接続すれば意図した結果になります。

構成

ホストOS：Windows10
ロードバランサー、WebサーバはVirtualBox+Vagrantで構築

構成（4/5修正）

Webサーバのeth2を取りました。

ホストOSのブラウザから「http://192.168.211.10」に接続したときのパケットの流れをtcpdumpコマンドでトレース

ホストOS(192.168.210.1)からのSYNパケットがLB、Webサーバに届いているように見えます。

[root@krtlbdev01 ~]# tcpdump -i any port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:33:34.651352 IP 192.168.210.1.55235 > krtlbdev01.http: Flags [S], seq 4072121208, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:34.651373 IP 192.168.210.1.55235 > 192.168.33.6.http: Flags [S], seq 4072121208, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:34.651391 IP 192.168.210.1.55236 > krtlbdev01.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:34.651395 IP 192.168.210.1.55236 > 192.168.33.5.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

[root@krtwebdev01 ~]# tcpdump -i any port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:33:34.654797 IP 192.168.210.1.55236 > krtwebdev01.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:35.799655 IP 192.168.210.1.55236 > krtwebdev01.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:37.799419 IP 192.168.210.1.55236 > krtwebdev01.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:41.799935 IP 192.168.210.1.55236 > krtwebdev01.http: Flags [S], seq 1394981027, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

[root@krtwebdev02 ~]# tcpdump -i any port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:33:34.656715 IP 192.168.210.1.55235 > krtwebdev02.http: Flags [S], seq 4072121208, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:34.903779 IP 192.168.210.1.55237 > krtwebdev02.http: Flags [S], seq 2643996327, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:35.749220 IP 192.168.210.1.55235 > krtwebdev02.http: Flags [S], seq 4072121208, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:33:35.948054 IP 192.168.210.1.55237 > krtwebdev02.http: Flags [S], seq 2643996327, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

その他必要な情報がありましたら教えてください。

行動規範の内容に同意します

回答1件

ベストアンサー

-m, --masquerading で振り分けているので、Webサーバーからの戻りパケットは 192.168.33.3 に届く必要があります。
Webサーバーの ip r によると、現状では以下の経路になっていて正しく通信できないのだと思います。

(ホストOS から HTTP リクエストを送出した場合)

  (行き:ホスト→LVS)  192.168.210.1 → 192.168.210.10
  (行き:LVS→Web)     192.168.210.1 → 192.168.33.5
	※D-NAT

  (戻り:   ←Web)     192.168.210.1 ← 192.168.33.5
	※Webサーバーは 192.168.210.0/24 に属しているので、eth2 から直接返す。

  (行き:ホスト←   )  192.168.210.1 ← 192.168.33.5
	※192.168.210.10 からの戻りじゃないので、破棄。

(外部ホストから HTTP リクエストを送出した場合)

  (行き:外部→LVS)    AAA.BBB.CCC.X → 192.168.210.10
  (行き:LVS→Web)     AAA.BBB.CCC.X → 192.168.33.5
	※D-NAT

  (戻り:   ←Web)     AAA.BBB.CCC.X ← 192.168.33.5
	※Webサーバーはデフォルトゲートウェイに返す。
	  2つ設定されているうち、metric の小さい 10.0.2.2 に返す。
	  外部ホストには届かないか、届いたとしても 192.168.210.10 からの戻りじゃないので、破棄。

-m, --masquerading にするのであれば、Webサーバーの IPアドレスは複数設定せず、LVS とつながるもの 1つのみにした方が簡単だと思います。

投稿2021/04/04 15:24

TaichiYanagiya

総合スコア12173

ths

2021/04/05 09:30

回答ありがとうございます。 Webサーバのeth2（192.168.210.0/24）を取りましたが、結果は変わりませんでした。戻りの通信、eth0の10.0.2.0/24から行こうとしているのでしょうか？

TaichiYanagiya

2021/04/05 11:59

> 戻りの通信、eth0の10.0.2.0/24から行こうとしているのでしょうか？だと思います。

ths

2021/04/05 12:41

https://kun432.hatenablog.com/entry/network-study-with-vyos 上記サイトを参考に ip route delete default via 10.0.2.2 を実施したら、目的の通信が実現できました。 vagrantのネットワークについてもう少し確認すべきでした。ありがとうございました。