Oddzielny ruch sieciowy na dwóch interfejsach sieciowych

11

Czy mógłbyś pożyczyć swoją wiedzę na temat konfigurowania separacji ruchu sieciowego na dwóch interfejsach sieciowych?

Jak rozumiem do tej pory, trasy statyczne są używane do ruchu sieciowego, który nie jest zaprojektowany do korzystania z domyślnej bramy. Brama domyślna jest używana dla całego ruchu, który nie jest przeznaczony dla sieci lokalnej i dla którego nie określono preferowanej trasy w tabeli routingu.

Scenariusz jest następujący.

  • Każdy komputer w sieci ma dwie karty sieciowe.
  • Interfejs produkcyjny każdego z nich to eth0(GW = 10.10.10.1).
  • Interfejs zarządzania dla każdego z nich to eth1(GW = 192.168.100.1).
  • Ruch produkcji i zarządzania powinien być całkowicie oddzielony.

Poniżej zamieściłem informacje o tym, czego próbowałem z Debian Wheezy. I moim problemem jest to, że chociaż mam hosty skonfigurowane w taki sposób, że komunikują się na obu interfejsach, poszczególne hosty wydają się „słyszeć” ruch na niewłaściwym interfejsie. Na przykład:

Host 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)

Od przyjmującym 140, I wykonanie tego polecenia: tcpdump -i eth0. W osobnej sesji na hoście 140 wykonuję 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

Dlaczego widzę powyższe wyjście włączone eth0? Myślę, że powinienem widzieć ruch tylko 10.10.10.140. Widzę to również eth1zgodnie z oczekiwaniami:

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

Jeśli pinguję z Hosta 50 (te same ifconfigwyniki - tylko inny ostatni quad), eth0to milczy i widzę echa ICMP włączone eth1, zgodnie z oczekiwaniami.

Chciałbym zrozumieć, jak skonfigurować każdy interfejs do obsługi tylko ruchu, za który jest odpowiedzialny w dwóch głównych odmianach systemu Linux. Chyba już tam jestem, ale brakuje mi czegoś, czego po prostu nie mogę znaleźć.

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

Wiem, że rozwiązanie dla Debiana powinno być dobre zarówno dla Wheezy, jak i Jessie, i że rozwiązanie dla EL powinno być takie samo dla wszystkich wersji EL 6.x. Chciałbym uniknąć używania skryptu RC do wykonywania poleceń, zamiast tego wybieram pliki konfiguracyjne.

W Debianie odpowiednie pliki konfiguracyjne, o których wiem, to:

  • /etc/network/interfaces

W wersji EL 6.x odpowiednie pliki konfiguracyjne, o których wiem, to:

  • /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

Mój /etc/network/interfacesplik „Jessie” Debiana 8 :

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

Myślę, że netstat -anrmoże to zilustrować problem:

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
Krzysztof
źródło
czekiptabels -L -t nat
PersianGulf

Odpowiedzi:

7

Chciałbym dowiedzieć się więcej na ten temat, aby udoskonalić konfigurację, aby była jak najlepsza, ale oto, co mam do tej pory. Nawet bez włączania filtrowania ARP na wszystkich interfejsach sieciowych ( net.ipv4.conf.all.arp_filter = 0), jak wspomniano w @spuk, ruch wydaje się być całkowicie oddzielony w tej konfiguracji.

Plik /etc/iproute2/rt_tables,, jest co najmniej taki sam w EL 6.x i DEB 7/8. Jest to plik, który tworzy nazwaną tabelę routingu dla tras statycznych.

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

Powyżej liczba nazwanej trasy statycznej 1 jest zasadniczo dowolna; lub każda trasa statyczna otrzymuje swój własny unikalny numer od 1 do 252.

Plik /etc/network/interfacesw DEB 7/8 co najmniej:

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

Wynik ip route showna Debianie:

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

Plik EL 6.x /etc/sysconfig/network:

NETWORKING=yes
HOSTNAME=localhost.localdomain
GATEWAY=10.10.10.1

Powyżej GATEWAY jest domyślną trasą. Poniżej, gdyby BOOTPROTOCOL ustawiono na DHCP, domyślna trasa zostałaby pozyskana z DHCP.

/etc/sysconfig/network-scripts/ifcfg-eth0Plik EL 6.x , bez „HWADDR” i „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-eth1Plik EL 6.x , bez „HWADDR” i „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

Plik 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

Plik EL 6.x /etc/sysconfig/network-scripts/rule-eth1:

from 192.168.100.0/24 lookup mgmt

Wynik ip route showna 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
Krzysztof
źródło
4

Nie przeczytałem do końca całego twojego postu (przepraszam, nie mogę w tej chwili naprawdę spędzić czasu), ale uważam, że może to być związane ze sposobem, w jaki Linux implementuje model hosta IP :

... Implementacja IPv4 w Linuksie domyślnie przyjmuje model słabego hosta. ...

Z tej samej strony:

... Jeśli stos IP jest zaimplementowany ze słabym modelem hosta, akceptuje on każdy lokalnie przeznaczony pakiet, niezależnie od interfejsu sieciowego, na którym pakiet został odebrany. ...

Oznacza to, że w systemie Linux adresy IP „należą do hosta”, a nie ściśle „do interfejsu”. Możesz zmienić to zachowanie za pośrednictwem arp_filter, rp_filter, arp_announce, arp_ignoresysctls (GOT z LVS: ARP Problem , widać tutaj ). Zobacz także ip-sysctl.txt .

spuk
źródło
Ten artykuł działał dobrze dla mnie: sivel.net/2006/12/linux-multi-homing
Richard Gomes