Окремий мережевий трафік на двох мережевих інтерфейсах

Чи можете ви надати свій досвід для розуміння того, як рухатися щодо налаштування поділу мережевого трафіку на два мережевих інтерфейси?

Як я розумію поки що, статичні маршрути використовуються для мережевого трафіку, який не призначений для використання шлюзу за замовчуванням. Шлюз за замовчуванням використовується для всього трафіку, який не призначений для локальної мережі і для якого не вказаний бажаний маршрут у таблиці маршрутів.

Сценарій такий.

• Кожен комп'ютер у мережі має дві мережеві карти.
• Інтерфейс виробництва для кожного становить eth0(GW = 10.10.10.1).
• Інтерфейс управління для кожного становить eth1(GW = 192.168.100.1).
• Виробничий та управлінський трафік слід повністю розділити.

Нижче я опублікував, що я спробував із Debian Wheezy. І моя проблема полягає в тому, що, хоча у мене хости створені таким чином, що вони спілкуються на обох інтерфейсах, окремі хости, здається, "чують" трафік на неправильному інтерфейсі. Наприклад:

Господар 140

eth0      Link encap:Ethernet  HWaddr 08:00:27:d1:b6:8f
          inet addr:10.10.10.140  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fed1:b68f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1341 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2530 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:641481 (626.4 KiB)  TX bytes:241124 (235.4 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:ad:14:b6
          inet addr:192.168.100.140  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fead:14b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5257 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:602485 (588.3 KiB)  TX bytes:1022906 (998.9 KiB)

Від хоста 140, я виконати цю команду: tcpdump -i eth0. В окремому сеансі на хості 140 я виконую ping 192.168.100.50.

19:17:29.301565 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 10, length 64
19:17:30.301561 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 11, length 64
19:17:31.301570 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 12, length 64
19:17:32.301580 IP 192.168.100.140 > 192.168.100.50: ICMP echo request, id 1400, seq 13, length 64

Чому я бачу вищезазначений вихід eth0? Я думаю, що я повинен бачити трафік лише 10.10.10.140. Я також бачу це eth1, як очікувалося:

19:18:47.805408 IP 192.168.100.50 > 192.168.100.140: ICMP echo request, id 1605, seq 247, length 64

Якщо я пінгую від Host 50 (ті ж ifconfigрезультати - просто інший останній квадратик), то eth0мовчить, і я бачу, як ICMP лунає eth1, як очікувалося.

Я хотів би зрозуміти, як налаштувати кожен інтерфейс для обробки лише трафіку, за який він відповідає у двох основних різновидах Linux. Я думаю, що я майже там, але мені не вистачає того, чого я просто не можу знайти.

• Debian Wheezy (7.x) або Debian Jessie (8.x)
• Enterprise Linux (6.x) (RedHat / CentOS / Scientific / Oracle).

Я знаю, що рішення для Debian має бути корисним і для Wheezy, і для Jessie, і що рішення для EL має бути однаковим для всіх версій EL 6.x. Я хотів би уникати використання сценарію RC для виконання команд, замість цього використовуючи файли конфігурації.

У Debian відповідні файли конфігурації, про які я знаю:

• /etc/network/interfaces

У EL 6.x відповідні файли конфігурації, про які я знаю:

• /etc/sysconfig/network
• /etc/sysconfig/network-scripts/ifcfg-eth0
• /etc/sysconfig/network-scripts/ifcfg-eth1
• /etc/sysconfig/network-scripts/route-eth0
• /etc/sysconfig/network-scripts/route-eth1
• /etc/sysconfig/network-scripts/rule-eth0
• /etc/sysconfig/network-scripts/rule-eth1

/etc/network/interfacesФайл мого Debian 8 "Jessie" :

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Production interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
  address 10.10.10.140
  netmask 255.255.255.0
  gateway 10.10.10.1

# Management interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
  address 192.168.100.140
  netmask 255.255.255.0

Я думаю, це netstat -anrможе ілюструвати проблему:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.10.1      0.0.0.0         UG        0 0          0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1

Я хотів би дізнатися більше про цю тему, щоб уточнити конфігурацію як найкращу, яка вона може бути, але ось що я маю досі. Навіть не вмикаючи фільтрацію ARP на всіх мережевих інтерфейсах ( net.ipv4.conf.all.arp_filter = 0), як згадує @spuk, трафік, здається, повністю розділений у цій конфігурації.

Файл, /etc/iproute2/rt_tablesє, як мінімум, в EL 6.x та DEB 7/8, принаймні. Це файл, який створює іменовану таблицю маршрутизації для статичних маршрутів.

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
1 mgmt

Вище число названих статичних маршрутів 1 по суті є довільним; або кожен статичний маршрут отримує власне унікальне число між 1 і 252.

Файл, /etc/network/interfacesу DEB 7/8, щонайменше:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
  iface lo inet loopback

# The production network interface
# The 'gateway' directive is the default route.
# Were eth0 configured via DHCP, the default route would also be here.
auto eth0
allow-hotplug eth0
iface eth0 inet static
  address 10.10.10.140
  netmask 255.255.255.0
  gateway 10.10.10.1

# The management network interface
# The 'gateway' directive cannot be used again because there can be
# one, and only one, default route. Instead, the 'post-up' directives
# use the `mgmt` static route.
auto eth1
allow-hotplug eth1
iface eth1 inet static
  address 192.168.100.140
  netmask 255.255.255.0
  post-up ip route add 192.168.100.0/24 dev eth1 src 192.168.100.140 table mgmt
  post-up ip route add default via 192.168.100.1 dev eth1 table mgmt
  post-up ip rule add from 192.168.100.140/32 table mgmt
  post-up ip rule add to 192.168.100.140/32 table mgmt

Результат роботи ip route showна Debian:

default via 10.10.10.1 dev eth0
10.10.10.0/24 dev eth0  proto kernel  scope link  src 10.10.10.140
192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.140

Файл EL 6.x /etc/sysconfig/network:

NETWORKING=yes
HOSTNAME=localhost.localdomain
GATEWAY=10.10.10.1

Вище GATEWAY - це маршрут за замовчуванням. Нижче, як BOOTPROTOCOL встановлено на DHCP, маршрут за замовчуванням буде отриманий від DHCP.

/etc/sysconfig/network-scripts/ifcfg-eth0Файл EL 6.x , без "HWADDR" та "UUID":

DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTOCOL=none
IPADDR=10.10.10.140
NETMASK=255.255.255.0
NETWORK=10.10.10.0
BROADCAST=10.10.10.255

/etc/sysconfig/network-scripts/ifcfg-eth1Файл EL 6.x , без "HWADDR" та "UUID":

DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTOCOL=none
IPADDR=192.168.100.140
NETMASK=255.255.255.0
NETWORK=192.168.100.0
BROADCAST=192.168.100.255

Файл EL 6.x /etc/sysconfig/network-scripts/route-eth1:

192.168.100.0/24 dev eth1 table mgmt
default via 192.168.100.1 dev eth1 table mgmt

Файл EL 6.x /etc/sysconfig/network-scripts/rule-eth1:

from 192.168.100.0/24 lookup mgmt

Результат ip route showна EL 6.x:

192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.160
10.10.10.0/24 dev eth0  proto kernel  scope link  src 10.10.10.160
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via 10.10.10.1 dev eth0

Я не перечитав всієї вашої публікації (вибачте, зараз не можу реально витратити час), але я вважаю, що це може бути пов’язано із способом, яким Linux реалізує хост-модель IP :

... Реалізація IPv4 в Linux налаштована на слабку модель хоста. ...

З тієї ж сторінки:

... Якщо стек IP реалізований із слабкою моделлю хоста, він приймає будь-який локально визначений пакет незалежно від мережевого інтерфейсу, на якому пакет був отриманий. ...

Тобто в Linux за замовчуванням IP-адреси "належать хосту", а не строго "інтерфейсу". Ви можете змінити цю поведінку з допомогою arp_filter, rp_filter, arp_announce, arp_ignoreпараметри ядра (отримали від LVS: ARP - Проблемний , бачив тут ). Також див. Ip-sysctl.txt .