着信IPアドレスと同じ送信元IPアドレスで応答しますか?

着信IPアドレスと同じ送信元IPアドレスで応答しますか?

私のシステムには、同じインターフェイスに2つの異なるIPアドレスがあります。両方のIPが同じネットワークに接続されています。これらの1つはデフォルトパスに設定されます。これに対する副作用は、パケットがデフォルトパスではなくIPを介して着信した場合、デフォルトパスインターフェイスを介して応答が再送信されることです。この問題を解決する方法はありますか?要求元と同じIPアドレスから応答が送信されると予想します。

出力ip address

`5: eth-access: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 96:52:79:33:7a:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.12/28 scope global eth-access
       valid_lft forever preferred_lft forever
    inet 192.168.0.13/28 scope global secondary eth-access
       valid_lft forever preferred_lft forever `

以下は、誤った送信元IPで発生したSNMP要求の詳細です。要求はIP「13」から来ますが、応答は「12」から来ます。

17:55:24.692149 IP (tos 0x0, ttl 63, id 35960, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.0.116.55421 > 192.168.0.13.161:  { SNMPv2c C="Test" { GetNextRequest(26) R=361171477  .1.3.6.1.2.1.1 } }
17:55:24.693519 IP (tos 0x0, ttl 64, id 22807, offset 0, flags [DF], proto UDP (17), length 133)
    192.168.0.12.161 > 192.168.0.116.55421:  { SNMPv2c C="Test" { GetResponse(83) R=361171477  .1.3.6.1.2.1.1.1.0="SunOS Node1 5.11 pn-tpOS-2.6.1-2060112460 i86pc" } }

この問題を解決するために、「13」IP用に別々のIPテーブルを作成しました。しかし、それは問題を解決できませんでした。

echo 252 snmp >> /etc/iproute2/rt_tables
ip rule add from 192.168.0.13 table snmp
ip route add default via 1192.168.0.1 dev eth-access src 192.168.0.13 table snmp
ip route add 192.168.0.0/28 dev eth-access src 192.168.0.13 table snmp

以下はシステムの出力です。

# ip rule list
0:      from all lookup local
32765:  from 192.168.0.13 lookup snmp
32766:  from all lookup main
32767:  from all lookup default

# ip route list table snmp
default via 192.168.0.1 dev eth-access  src 192.168.0.13
192.168.0.0/28 dev eth-access  scope link  src 192.168.0.13

要求と同じ送信元IPアドレスを使用できるようにする方法はありますか? 1つのインターフェイスに同じサブネットの2つのIPがある場合。

編集:明確にするには:サーバーが要求の宛先IPと同じ送信元IPで要求に応答していることを確認する必要があります。つまり、要求が宛先 IP 192.168.0.13 から来る場合、応答は送信元 IP 192.168.0.13 でなければなりません。現在のSNMP要求に対する応答は、要求がIPアドレス192.168.0.13から来るとき、送信元IPとしてIPアドレス192.168.0.12を使用する。

編集:解決策最後に、このテストを実行するツールがこの応答を受け入れることができることに気づきました。テストに応答を許可しない他のサーバーでSNMPwalkコマンドを使用します。 (ソースアドレスが異なるため、そうです。)しかし、実際のSNMPツールはより寛大であるようで、変更なしに私の側から応答を受け入れます。これがどのように機能するのかよくわかりませんが、共有したいと思いました。みんなの助けに感謝します。

関連情報