¿Podría prestar su experiencia para comprender cómo
configurar la separación del tráfico de red en dos interfaces de red?
Según tengo entendido hasta ahora, las rutas estáticas se usan para el tráfico de red que
no está diseñado para usar una puerta de enlace predeterminada. La puerta de enlace predeterminada se utiliza para
todo el tráfico que no está destinado a la red local y para el cual no se ha especificado
una ruta preferida en una tabla de enrutamiento.
El escenario es el siguiente.
- Cada computadora en la red tiene dos tarjetas de red.
- La interfaz de producción para cada uno es
eth0
(GW =10.10.10.1). - La interfaz de administración para cada uno es
eth1
(GW =192.168.100.1). - El tráfico de producción y administración debe estar totalmente separado.
A continuación, publiqué las cosas que probé con Debian Wheezy.
Y mi problema es que, aunque tengo hosts configurados de tal manera que
se comunican en ambas interfaces, hosts individuales parecen "escuchar"
tráfico en la interfaz incorrecta. Por ejemplo:
Anfitrión 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)
Desde el host 140, ejecuto este comando:tcpdump -i eth0
. En una sesión
separada en el host 140, ejecuto 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
¿Por qué veo el resultado anterior en eth0
? ? Creo que solo debería ver tráfico para 10.10.10.140.
También veo esto en eth1
, como se esperaba:
19:18:47.805408 IP 192.168.100.50 > 192.168.100.140: ICMP echo request, id 1605, seq 247, length 64
Si hago ping desde el Host 50 (el mismo ifconfig
resultados:solo un último cuádruple diferente),
luego eth0
está en silencio, y veo los ecos de ICMP en eth1
, como se esperaba.
Me gustaría entender cómo configurar cada interfaz para manejar solo
el tráfico del que es responsable en dos variedades principales de Linux.
Creo que casi he llegado, pero me falta algo que simplemente puedo. Parece que no encuentro.
- Debian Wheezy (7.x) o Debian Jessie (8.x)
- Linux empresarial (6.x) (RedHat/CentOS/Scientific/Oracle).
Sé que una solución para Debian debería ser buena tanto para Wheezy como para Jessie,
y que una solución para EL debería ser la misma para todas las versiones de EL 6.x.
Me gustaría evitar usar un script RC para ejecutar comandos, optando en su lugar
por usar los archivos de configuración.
En Debian, los archivos de configuración relevantes que conozco son:
/etc/network/interfaces
En EL 6.x, los archivos de configuración relevantes que conozco son:
/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
Mi Debian 8 “Jessie” /etc/network/interfaces
archivo:
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
Creo que netstat -anr
podría ilustrar el 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
Respuesta aceptada:
Me encantaría saber más sobre este tema para refinar la configuración para que sea lo mejor posible, pero esto es lo que tengo hasta ahora. Incluso sin habilitar el filtrado ARP en todas las interfaces de red (net.ipv4.conf.all.arp_filter = 0
), como lo menciona @spuk,
el tráfico parece estar completamente separado en esta configuración.
El archivo, /etc/iproute2/rt_tables
, es lo mismo en EL 6.x y DEB 7/8, al menos. Este es el archivo que crea una tabla de enrutamiento con nombre para rutas estáticas.
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
252 mgmt
Arriba, el número de la ruta estática nombrada, 252, es esencialmente arbitrario; o bien, cada ruta estática obtiene su propio número único entre 1 y 252.
El archivo, /etc/network/interfaces
en DEB 7/8, al menos:
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
El resultado de ip route show
en 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
archivo:
NETWORKING=yes
HOSTNAME=localhost.localdomain
GATEWAY=10.10.10.1
Arriba, GATEWAY es la ruta predeterminada. A continuación, si BOOTPROTOCOL se configurara en DHCP, la ruta predeterminada se adquiriría de DHCP.
EL EL 6.x /etc/sysconfig/network-scripts/ifcfg-eth0
archivo, sin "HWADDR" y "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
EL EL 6.x /etc/sysconfig/network-scripts/ifcfg-eth1
archivo, sin "HWADDR" y "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
archivo:
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
archivo:
from 192.168.100.0/24 lookup mgmt
El resultado de ip route show
en 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
Actualización para RHEL8
Este método descrito anteriormente funciona con RHEL 6 y RHEL 7, así como con los derivados, pero para RHEL 8 y derivados, primero debe instalar network-scripts
para utilizar el método descrito anteriormente.
dnf install network-scripts
La instalación produce una advertencia de que network-scripts
se eliminará en una de las próximas versiones importantes de RHEL y que NetworkManager proporciona ifup
/ifdown
guiones también.
Actualización para Ubuntu 20.04 LTS
La creación de una tabla de enrutamiento con nombre está bien, pero no es necesaria con netplan
, que no usará el nombre de todos modos. No obstante, el número de la tabla de enrutamiento nombrada de rt_tables
el archivo se puede usar para netplan
. Las NIC correspondientes son enps03
(eth0
) y 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
Esto da como resultado las siguientes rutas desde 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