☰

Configurar el enrutamiento público versus privado en Ubuntu

tag-icon • tag-icon routing
Configurar el enrutamiento público versus privado en Ubuntu

He estado buscando por un tiempo y parece que no puedo encontrar una buena respuesta para esto, así que pensé en preguntar antes de pasar un par de días más golpeándome la cabeza contra el escritorio.

Tengo una caja de Ubuntu con dos interfaces físicas y una interfaz virtual.

  eno1 - 172.16.0.100
  eno2 - 172.16.0.101
eno1:0 - x.x.x.x

lo que me gustaría conseguir

  1. Para las respuestas a los paquetes entrantes, me gustaría que los paquetes salieran por la interfaz por la que entró su solicitud.

  2. Para los paquetes salientes, me gustaría que salieran de forma predeterminada el...

    a. eno1: para paquetes destinados a redes privadas (múltiples rangos 172.16.x.0 no contiguos) b. eno1:0 - para paquetes destinados a todas las demás redes

Configuración actual

lista de reglas ip

0:  from all lookup local 
32760:  from all to x.x.x.x lookup eno1:0 
32761:  from x.x.x.x lookup eno1:0 
32762:  from all to 172.16.0.101 lookup eno2 
32763:  from 172.16.0.101 lookup eno2 
32764:  from all to 172.16.0.100 lookup eno1 
32765:  from 172.16.0.100 lookup eno1 
32766:  from all lookup main 
32767:  from all lookup default

tabla de lista de rutas ip eno1:0

default via x.x.x.1 dev eno1

tabla de lista de rutas ip eno1

default via 172.16.0.1 dev eno1 
172.16.0.0/24 dev eno1  scope link  src 172.16.0.100

tabla de lista de rutas ip eno2

default via 172.16.0.1 dev eno2 
172.16.0.0/24 dev eno2  scope link  src 172.16.0.101

lista de rutas IP

default via 172.16.0.1 dev eno1 onlink 
x.x.x.0/23 dev eno1  proto kernel  scope link  src x.x.x.x 
172.16.0.0/24 dev eno2  proto kernel  scope link  src 172.16.0.101 
172.16.0.0/24 dev eno1  proto kernel  scope link  src 172.16.0.100

valores sysctl para eno1 y eno2

arp_filter=1
arp_ignore=1
arp_announce=2

Problemas

  1. Puedo llegar esporádicamente a eno1 y eno2 desde rangos fuera de sus subredes, pero no puedo llegar a eno1:0 en absoluto.
  2. Desde el cuadro no puedo acceder a Internet (IP públicas) en absoluto.

Respuesta1

Descubierta - o más bien redescubierta - la respuesta...

El problema es la creencia de Unix de que el host es la entidad de la red en lugar del puerto, lo que causa todo tipo de problemas de arp en servidores multitarjeta. Básicamente, necesitaba limitar las respuestas arp en una interfaz a las direcciones IP asociadas con esa interfaz; de lo contrario, Unix responderá en CUALQUIER interfaz independientemente de la IP, lo que realmente confunde muchísimo a todos los demás dispositivos en la subred.

Entonces... Arptables instalados

sudo apt-get -y install arptables

Limitó las respuestas en cada interfaz a las IP en la interfaz.

sudo arptables -n -v --line-numbers -L
Chain INPUT (policy DROP 6011K packets, 168M bytes)
1 -j ACCEPT -i eno1 -o * -d x.x.x.x , pcnt=2496 -- bcnt=69888 
2 -j ACCEPT -i eno1 -o * -d 172.16.0.100 , pcnt=294 -- bcnt=8232 
3 -j ACCEPT -i eno2 -o * -d 172.16.0.101 , pcnt=294 -- bcnt=8232 

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
1 -j ACCEPT -i * -o eno1 -s x.x.x.x , pcnt=2503 -- bcnt=70084 
2 -j ACCEPT -i * -o eno1 -s 172.16.0.100 , pcnt=295 -- bcnt=8260 
3 -j ACCEPT -i * -o eno2 -s 172.16.0.101 , pcnt=294 -- bcnt=8232 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

Y listo, todas las IP responden en sus puertos correctos.

¡Hombre! ¡Espero no olvidar esto otra vez!

información relacionada