UbuntuネットワークAでeth4が構成されている場合、eth0でネットワークAからのパケットを無視する
2つの構成済みネットワークインターフェイスを備えたUbuntu12.04（最終ベータ版、最新）サーバーがあります。
root@mac:/home/sysadm# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1e:4f:28:fd:7b
inet addr:172.18.8.10 Bcast:172.18.8.255 Mask:255.255.255.0
inet6 addr: fe80::21e:4fff:fe28:fd7b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3362 errors:0 dropped:0 overruns:0 frame:0
TX packets:8561 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:273506 (273.5 KB) TX bytes:3174766 (3.1 MB)
Interrupt:38 Memory:dc000000-dc012800
eth4 Link encap:Ethernet HWaddr 00:02:c9:09:a4:c8
inet addr:xxx.yy.4.235 Bcast:xxx.yy.5.255 Mask:255.255.254.0
inet6 addr: fe80::202:c9ff:fe09:a4c8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59277 errors:0 dropped:52 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5138237 (5.1 MB) TX bytes:6462 (6.4 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1412 errors:0 dropped:0 overruns:0 frame:0
TX packets:1412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:107356 (107.3 KB) TX bytes:107356 (107.3 KB)
root@mac:/home/sysadm# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.18.8.254 0.0.0.0 UG 100 0 0 eth0
xxx.yy.4.0 0.0.0.0 255.255.254.0 U 0 0 0 eth4
172.18.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
ご覧のとおり、eth0は172.18.8.0/24ネットワーク（ "8-net"）にあり、eth4はxxx.yy.4.0/23ネットワーク（ "4-net"）にあります。これらのネットワークは両方ともルーターを介して接続されています。多くのマシンが両方のネットワーク上にあり（一度に1台）、問題なく通信できます。 4-net上の2番目のマシンが172.18.8.10と通信しようとすると、パケットがドロップされたように見えます。 SSH試行のtcpdumpは以下のとおりです。
root@mac:/home/sysadm# ufw allow from any to any port 1022
Rule added
Rule added (v6)
root@mac:/home/sysadm# sshd -de -p 1022
sshd re-exec requires execution with an absolute path
root@mac:/home/sysadm# which sshd
/usr/sbin/sshd
root@mac:/home/sysadm# /usr/sbin/sshd -de -p 1022
debug1: sshd version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private Host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private Host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private Host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-de'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='1022'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 1022 on 0.0.0.0.
Server listening on 0.0.0.0 port 1022.
debug1: Bind to port 1022 on ::.
Server listening on :: port 1022.
^Z
[1]+ Stopped /usr/sbin/sshd -de -p 1022
root@mac:/home/sysadm# bg
[1]+ /usr/sbin/sshd -de -p 1022 &
root@mac:/home/sysadm# tcpdump -nvlli eth0 'Host xxx.yy.4.29'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:16:33.370081 IP (tos 0x0, ttl 63, id 29087, offset 0, flags [DF], proto TCP (6), length 60)
xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xdc29 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3473994833 ecr 0,nop,wscale 7], length 0
18:16:36.369860 IP (tos 0x0, ttl 63, id 29088, offset 0, flags [DF], proto TCP (6), length 60)
xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xd071 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3473997833 ecr 0,nop,wscale 7], length 0
18:16:42.369300 IP (tos 0x0, ttl 63, id 29089, offset 0, flags [DF], proto TCP (6), length 60)
xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xb901 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3474003833 ecr 0,nop,wscale 7], length 0
完全を期すために：
root@mac:/home/sysadm# ufw status
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
1022 ALLOW Anywhere
22 ALLOW Anywhere (v6)
1022 ALLOW Anywhere (v6)
接続を確立しているノードでタイムアウトが発生します。他のプロトコルも影響を受けます。エコー要求がタイムアウトします。ただし、8ネット上のノードと、4ネットではない他のすべてのネットワークは、問題なく通信できます。ログには何も表示されません。他の「UFWBLOCK」エントリは/ var/log/syslogに存在しますが、関連するエントリは存在しません。
つまり、マシンには、ネットワーク8のeth0とネットワーク4のeth4の2つのインターフェイスがあります。ネットワーク4の他のノードはeth0と通信できませんが、他のすべてのネットワークのノードは通信できます。論理的な反対も当てはまります。eth4と通信しようとしているネットワーク8ノードでタイムアウトが発生します。これは機能ですか、それともバグですか？ 2つのインターフェイスを備えたマシンで論理的に間違ったインターフェイスと通信できると期待すべきではありませんか？
重要な場合、これはDell PowerEdgeR900です。 eth0は統合ポート「NetXtremeIIBCM5708ギガビットイーサネット」であり、eth4はMellanoxTechnologiesのアドインカード「MT26448 [ConnectX EN 10GigE、PCIe 2.0 5GT/s]」の2つのポートの1つです。
EDIT：ファイアウォールが無効になっている場合でも問題は解決しません。 tcpdumpは、応答が送信されずに着信するパケット（エコー要求）を引き続き表示します。
EDIT：その他の出力：これは、リモートホスト 'xxx.yy.4.29'に関連するeth4トラフィックのダンプです。 xxx.yy.4.29から、172.18.8.10とxxx.yy.4.235にpingを実行しました。これが出力です。
root@mac:/home/sysadm# tcpdump -nvlli eth4 'Host xxx.yy.4.29'
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes
20:25:04.401449 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has xxx.yy.4.235 tell xxx.yy.4.29, length 46
20:25:04.401492 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.235 is-at 00:02:c9:09:a4:c8, length 28
20:25:04.401647 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
xxx.yy.4.29 > xxx.yy.4.235: ICMP echo request, id 32312, seq 1, length 64
20:25:04.401706 IP (tos 0x0, ttl 64, id 42264, offset 0, flags [none], proto ICMP (1), length 84)
xxx.yy.4.235 > xxx.yy.4.29: ICMP echo reply, id 32312, seq 1, length 64
20:25:05.401200 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
xxx.yy.4.29 > xxx.yy.4.235: ICMP echo request, id 32312, seq 2, length 64
20:25:05.401211 IP (tos 0x0, ttl 64, id 42265, offset 0, flags [none], proto ICMP (1), length 84)
xxx.yy.4.235 > xxx.yy.4.29: ICMP echo reply, id 32312, seq 2, length 64
20:25:09.402234 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has xxx.yy.4.29 tell xxx.yy.4.235, length 28
20:25:09.402383 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.29 is-at 78:2b:cb:90:95:98, length 46
20:25:09.402747 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.29 is-at 78:2b:cb:90:95:98, length 46
編集：これは単なるテストマシンです。 4ネットインターフェイスを介して8ネット通信をルーティングする必要がある現実のシナリオを想像することはできません。解決策の利点が問題を解決する努力の価値がない場合、これがどのように既知の問題になるかがわかります。
ここでおそらく表示されているのは リバースパスフィルタリング です。カーネルは、パケットが「間違った」インターフェイスから来ているように見えるため、パケットを破棄しています。 RPFが有効になっているかどうかを確認するには、cat /proc/sys/net/ipv4/conf/eth0/rp_filterを実行します（eth4についても同様です）。これを無効にするには、それらのファイルに0をエコーします。
RPFが無効になっている場合でも、@ NathanGが言ったように、ルーティングは少し奇妙になります（応答パケットは、受信したものとは異なるインターフェイスから送信されます）。ルーターがあまり賢くない場合（つまり、RPFやその他のなりすまし保護がない場合）でも、これは機能するはずです。
これを適切に設定するために必要なのは、送信元アドレスに基づいた ポリシールーティング です（つまり、送信元アドレスに基づいてパケットを異なる方法でルーティングするようにカーネルに指示します）。これを行うには、複数のルーティングテーブルを設定し、いくつかのルールを追加して、使用するテーブルを選択します。
まず、いくつかのテーブルに名前を付けます（これを行う必要があるのは1回だけです）。
echo "14 net4" >> /etc/iproute2/rt_tables
echo "18 net8" >> /etc/iproute2/rt_tables
次に、これらの新しいテーブルにルートを追加します（このマシンは、eth0またはeth4のいずれかのルーターを介してインターネットにアクセスできると想定しています）。
ip route add xx.yy.4.0/23 dev eth4 table net4
ip route add default via xx.yy.4.1 table net4
ip route add 172.18.8.0/24 dev eth0 table net8
ip route add default via 172.18.8.254 table net8
最後に、いくつかのルールを追加して、パケットのソースアドレスに基づいて適切なテーブルを選択します。
ip rule add from xx.yy.4.0/23 lookup net4
ip rule add from 172.18.8.0/24 lookup net8
これはルーティングの問題のようです。 4-netからeth0に着信パケットがある場合、システムは応答を求めています。 4-netの唯一のルートはeth4ですが、元のIPアドレス（eth0）から応答する必要があります。トラフィックがeth0から4-netに出ることができるように、ルートを追加してみてください。route add -net xx.yy.4.0 netmask 255.255.254.0 metric 100 dev eth0
メートル法の線は、これが4-netへの優先ルートにならないようにします（eth4に何かが起こらない限り）