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ż eth1
zgodnie 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 ifconfig
wyniki - tylko inny ostatni quad), eth0
to 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/interfaces
plik „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 -anr
moż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
iptabels -L -t nat
Odpowiedzi:
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.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/interfaces
w DEB 7/8 co najmniej:Wynik
ip route show
na Debianie:Plik EL 6.x
/etc/sysconfig/network
: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-eth0
Plik EL 6.x , bez „HWADDR” i „UUID”:/etc/sysconfig/network-scripts/ifcfg-eth1
Plik EL 6.x , bez „HWADDR” i „UUID”:Plik EL 6.x
/etc/sysconfig/network-scripts/route-eth1
:Plik EL 6.x
/etc/sysconfig/network-scripts/rule-eth1
:Wynik
ip route show
na EL 6.x:źródło
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 :
Z tej samej strony:
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_ignore
sysctls (GOT z LVS: ARP Problem , widać tutaj ). Zobacz także ip-sysctl.txt .źródło