サーバをダブルNICにすると想定していない通信経路で応答する場合がありますが、大抵はマルチホーミング設定で解決します。ちょうどCentOS6.8で設定する機会があったのでメモとして残しておきます。
一般的なダブルNICの通信経路について
NIC2枚差し=IPアドレスが2つの場合、デフォルトゲートウェイが設定されているNICから応答パケットを返します。イメージとしてはこんな感じです。
PC2(192.168.2.17)からサーバのeth1(192.168.1.200)に対してpingを打った時のtcpdumpを見ると 一見、eth1のIPアドレスから帰ってきているように見えるのですが・・・
[risca@PC2 ~]$ tcpdump -n -i eth0 icmp 22:17:21.968920 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 23862, seq 114, length 64 22:17:21.969353 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 23862, seq 114, length 64 22:17:22.968930 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 23862, seq 115, length 64 22:17:22.969579 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 23862, seq 115, length 64 ...
サーバのeth1はicmp echo requestを受け取っていますが応答はしていません。
[risca@server ~]$ tcpdump -n -i eth1 icmp 22:17:20.264921 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 48175, seq 193, length 64 22:17:21.264936 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 48175, seq 194, length 64 22:17:22.264881 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 48175, seq 195, length 64 22:17:23.264745 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 48175, seq 196, length 64 ...
その一方eth0を確認するとicmp echo replyの応答だけを行っています。
[risca@server ~]$ tcpdump -n -i eth0 icmp 22:17:20.955671 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 63794, seq 438, length 64 22:17:21.955492 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 63794, seq 439, length 64 22:17:22.955533 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 63794, seq 440, length 64 22:17:23.955514 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 63794, seq 441, length 64 ...
なおeth1と同一ネットワークからの通信に対してはeth1から応答しています。
[risca@server ~]$ tcpdump -n -i eth1 icmp 22:18:35.184290 IP 192.168.1.100 > 192.168.1.220: ICMP echo request, id 50961, seq 1, length 64 22:18:35.185760 IP 192.168.1.220 > 192.168.1.100: ICMP echo reply, id 50961, seq 1, length 64 22:18:36.186003 IP 192.168.1.100 > 192.168.1.220: ICMP echo request, id 50961, seq 2, length 64 22:18:36.186021 IP 192.168.1.220 > 192.168.1.100: ICMP echo reply, id 50961, seq 2, length 64 ...
この状態でも直ちに困るようなことはないと思いますが、例えばeth0がダウンすると192.168.1.0/24ネットワーク以外からはeth1にアクセスできなくなることが予想されます。また送信元IPアドレスによってはeth1に対するアクセスの応答経路がeth0とeth1に分散してしまい管理しづらくなることも予想できます。
マルチホーミング設定の通信経路
このような場合でも、デフォルトゲートウェイとは関係なく、受信したポートから応答するのがマルチホーミング設定です。
設定ファイルと内容はこんなところ
## iproute2のルーティングルール「gatway1」を追加する # vi /etc/iproute2/rt_tables# # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep + 201 gateway1## IPv4の転送を有効化の設定を行う # vi /etc/sysctl.conf- net.ipv4.ip_forward = 0 + net.ipv4.ip_forward = 1## sysctl.confを反映させIPv4の転送を有効化する # sysctl -p /etc/sysctl.conf net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 1 ...（省略） ## eth1のルーティングファイル作成 ##「192.168.1.0/24ゾーンを参照する元ホストがeth0の192.168.1.220の通信はgateway1を利用する」 ##「gateway1のデフォルトルートは192.168.1.254」 # vi /etc/sysconfig/network-scripts/route-eth1+ 192.168.1.0/24 dev eth1 src 192.168.1.220 table gateway1 + default via 192.168.1.254 table gateway1## eth1のルールファイル作成 ##「192.168.1.220からの転送要求はgateway1ルールに従う」 # vi /etc/sysconfig/network-scripts/rule-eth1+ from 192.168.1.220 table gateway1## ルーティング設定を反映するためnetworkサービスを再起動する # service network restart
サーバのマルチホーミング設定後に、eth0とeth1のtcpdumpを見てeth1から応答することを確認します。
[risca@server ~]$ tcpdump -n -i eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
[risca@server ~]$ tcpdump -n -i eth1 icmp 23:12:46.488815 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 568, seq 134, length 64 23:12:46.488842 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 568, seq 134, length 64 23:12:47.488727 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 568, seq 135, length 64 23:12:47.488752 IP 192.168.1.220 > 192.168.2.17: ICMP echo reply, id 568, seq 135, length 64 23:12:48.488884 IP 192.168.2.17 > 192.168.1.220: ICMP echo request, id 568, seq 136, length 64 ...
