【現象】
ssh通信 にてサーバにアクセスしようとしたが、なぜかつながらない
切り分けとしてサーバの全インターフェースで “tcpdump” をした時に以下の通信がされていた
PC → SV-eth1 → SV-eth0 → PC
PC → SV-eth0 → SV-eth0 → PC
eth1アクセス 時に戻りのルートが別インターフェースから出ていってる
つまり、サーバでフォワーディングしているよう
eth0 アクセス 時はなぜか、同じインターフェースから戻っている
共通している事は、必ずデフォルトゲートウェイ指定のインターフェースから戻っている
因みにこの時、ssh通信で eth0 にアクセスできるが eth1 にはアクセスできない
【調査対象】
１．フォワーディングされているわけ
２．eth1 に ssh通信 が出来ないわけ
それぞれ順番に対応していく
【環境】
昔のことなのでうろ覚え・・・
PC：不明 OS：WindowsXP
SV：不明 OS：Red Hat Enterprise Linux ver5.x
SW：Catalyst3560 IOS：不明
forword(図)
※L3は各ポートでVLANを切り、VLAN同士でルーティングさせている
【要件/状況】
・デフォルトゲートウェイの設定ははずせない
・L3SW から切り分けは行えない
【設定】
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
~省略~
# vi /proc/sys/net/ipv4/ip_forward
0
【対応】
１．戻りが eth0(デフォルトゲートウェイ経由) になってしまうので、eth1 にもデフォルトゲートウェイを設定する
①route add default gw 192.168.1.1 eth1
②# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
~省略~
→ ”tcpdump -i ethx” にて確認
なぜか以下のように両方のインターフェースからフォワーディングされるようになった
PC → SV-eth1 → SV-eth0 → PC
PC → SV-eth0 → SV-eth1 → PC
尚、ssh通信 は eth0 にも出来なくなった
③設定を元に戻す
route add default gw 192.168.1.1
２．デフォルトゲートウェイのルートよりスタティックルートで対応させる
→ すでにルートが入っている
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth1
３．ルート情報の優先度について確認
→ Metric値 は全て同じなので、上位にあるものが優先される
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 192.168.1.1 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
４．”ifdown eth0″ にて eth0 を停止する
→ ssh 通信はなぜか成功
PC → SV-eth1 → SV-eth1 → PC
【結論】
本現象は昔に対応したものなので、詳細な情報は思い出せない
実はこの環境は、客先にあるものなので障害切り分けはほとんどできなかった
自社にて「VMware」を使った検証環境での確認が手一杯だった(しかも、他人の環境)
自社では上記の環境はすべて Linux系 の OS ですべて対応 (PC、SV、L3SW)
そのせいかもしれないが、フォワーディングは改善されなかったが、ssh通信 ができないことはなかった
Ciscoスイッチ は
「ポートに VLAN を割り当てると、例えSRCアドレスでも、その割り当てた VLANが所属するネットワーク以外のパケットは破棄」
しているんじゃないかと・・・
そうじゃないと VLAN の意味をなさないわけだし・・・
結局、この環境以下のような仕様となった
・ssh通信 は eth0 のみ
・フォワーディングについては改善しなかった
この事象、機会があったら、検証環境を作り再現させたい
