Potresti fornire la tua esperienza per capire come procedere
a configurare la separazione del traffico di rete su due interfacce di rete?
Da quanto ho capito finora, le route statiche vengono utilizzate per il traffico di rete che
non è progettato per utilizzare un gateway predefinito. Il gateway predefinito viene utilizzato per
tutto il traffico che non è destinato alla rete locale e per il quale non è stata specificata una
route preferita in una tabella di routing.
Lo scenario è il seguente.
- Ogni computer della rete dispone di due schede di rete.
- L'interfaccia di produzione per ciascuno è
eth0(GW =10.10.10.1). - L'interfaccia di gestione per ciascuno è
eth1(GW =192.168.100.1). - Il traffico di produzione e di gestione dovrebbe essere totalmente separato.
Ho pubblicato, di seguito, le cose che ho provato con Debian Wheezy.
E il mio problema è che, anche se ho host impostati in modo tale che
comunicano su entrambe le interfacce, host individuali sembrano "sentire"
il traffico sull'interfaccia sbagliata. Ad esempio:
Ospita 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)
Dall'host 140, eseguo questo comando:tcpdump -i eth0 . In una sessione
separata sull'host 140, eseguo 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
Perché vedo l'output sopra su eth0 ? Penso che dovrei vedere solo il traffico per 10.10.10.140.
Lo vedo anche su eth1 , come previsto:
19:18:47.805408 IP 192.168.100.50 > 192.168.100.140: ICMP echo request, id 1605, seq 247, length 64
Se eseguo il ping dall'host 50 (stesso ifconfig risultati – solo un ultimo quad diverso),
quindi eth0 è silenzioso e vedo l'eco dell'ICMP su eth1 , come previsto.
Vorrei capire come configurare ciascuna interfaccia per gestire solo
il traffico di cui è responsabile in due principali varietà di Linux.
Penso di essere quasi arrivato, ma mi manca qualcosa che appena posso' non sembra trovare.
- Debian Wheezy (7.x) o Debian Jessie (8.x)
- Enterprise Linux (6.x) (RedHat/CentOS/Scientific/Oracle).
So che una soluzione per Debian dovrebbe andare bene sia per Wheezy che per Jessie,
e che una soluzione per un EL dovrebbe essere la stessa per tutte le versioni EL 6.x.
Vorrei evitare di usare uno script RC per eseguire comandi, optando invece
per utilizzare i file di configurazione.
In Debian i file di configurazione rilevanti che conosco sono:
/etc/network/interfaces
In EL 6.x, i file di configurazione rilevanti di cui sono a conoscenza sono:
/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
La mia Debian 8 "Jessie" /etc/network/interfaces file:
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
Penso netstat -anr potrebbe illustrare il problema:
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
Risposta accettata:
Mi piacerebbe saperne di più su questo argomento per perfezionare la configurazione in modo che sia la migliore possibile, ma ecco cosa ho finora. Anche senza abilitare il filtro ARP su tutte le interfacce di rete (net.ipv4.conf.all.arp_filter = 0 ), come menzionato da @spuk,
il traffico sembra essere completamente separato in questa configurazione.
Il file, /etc/iproute2/rt_tables , è lo stesso in EL 6.x e DEB 7/8, almeno. Questo è il file che crea una tabella di routing denominata per route statiche.
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
252 mgmt
Sopra, il numero del percorso statico denominato, 252, è essenzialmente arbitrario; oppure, ogni route statica ottiene il proprio numero univoco compreso tra 1 e 252.
Il file, /etc/network/interfaces in DEB 7/8, almeno:
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
Il risultato di ip route show su 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
Il /etc/sysconfig/network di EL 6.x file:
NETWORKING=yes
HOSTNAME=localhost.localdomain
GATEWAY=10.10.10.1
Sopra, GATEWAY è il percorso predefinito. Di seguito, se BOOTPROTOCOL fosse impostato su DHCP, il percorso predefinito verrebbe acquisito da DHCP.
THE EL 6.x /etc/sysconfig/network-scripts/ifcfg-eth0 file, senza “HWADDR” e “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
THE EL 6.x /etc/sysconfig/network-scripts/ifcfg-eth1 file, senza “HWADDR” e “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 file:
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 file:
from 192.168.100.0/24 lookup mgmt
Il risultato di ip route show su 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
default via 10.10.10.1 dev eth0
Aggiornamento per RHEL8
Questo metodo sopra descritto funziona con RHEL 6 e RHEL 7 così come i derivati, ma per RHEL 8 e derivati, è necessario prima installare network-scripts per utilizzare il metodo sopra descritto.
dnf install network-scripts
L'installazione produce un avviso che network-scripts verrà rimosso in una delle prossime versioni principali di RHEL e NetworkManager fornisce ifup /ifdown anche gli script.
Aggiornamento per Ubuntu 20.04 LTS
La creazione di una tabella di routing denominata va bene, ma non è richiesta con netplan , che comunque non utilizzerà il nome. Tuttavia il numero della tabella di routing denominata da rt_tables può essere utilizzato per netplan . Le NIC corrispondenti sono enps03 (eth0 ) e enp0s8 (eth1 ).
network:
version: 2
ethernets:
enp0s3:
addresses:
- 10.10.10.140/24
dhcp4: false
dhcp6: false
gateway4: 10.10.10.1
nameservers:
addresses:
- 1.2.3.4
- 1.2.3.5
search:
- your-search-domain-name.com
enp0s8:
dhcp4: false
dhcp6: false
addresses:
- 192.168.100.140/24
routes:
- to: 192.168.100.0/24
via: 192.168.100.1
table: 252
routing-policy:
- from: 192.168.100.0/24
table: 252
Ciò si traduce nei seguenti percorsi da ip r s .
default via 10.10.10.1 dev enp0s3 proto static
10.10.10.0/24 dev enp0s3 proto kernel scope link src 10.10.10.140
192.168.100.0/24 dev enp0s8 proto kernel scope link src 192.168.100.140