☰

Configurando roteamento público versus privado no Ubuntu

tag-icon • tag-icon routing
Configurando roteamento público versus privado no Ubuntu

Estou procurando há um tempo e não consigo encontrar uma boa resposta para isso, então pensei em perguntar antes de passar mais alguns dias batendo a cabeça na mesa.

Eu tenho uma caixa Ubuntu com duas interfaces físicas e uma interface virtual.

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

O que eu gostaria de conseguir

  1. Para respostas aos pacotes recebidos, gostaria que os pacotes saíssem na interface pela qual sua solicitação chegou.

  2. Para pacotes de saída, gostaria que eles saíssem por padrão em ...

    a. eno1 - para pacotes destinados a redes privadas (múltiplos intervalos 172.16.x.0 não contíguos) b. eno1:0 – para pacotes destinados a todas as outras redes

Configuração atual

lista de regras de 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

tabela de lista de rotas ip eno1:0

default via x.x.x.1 dev eno1

tabela de lista de rotas ip eno1

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

tabela de lista de rotas 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 rotas 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 e eno2

arp_filter=1
arp_ignore=1
arp_announce=2

Problemas

  1. Posso acessar eno1 e eno2 esporadicamente de intervalos fora de suas sub-redes, mas não consigo acessar eno1:0.
  2. Da caixa não consigo acessar a internet (IPs públicos).

Responder1

Descobriu - ou melhor, redescobriu - a resposta...

O problema é a crença do Unix de que o host é a entidade da rede e não a porta que causa todos os tipos de problemas de arp em servidores multi-homed. Então, basicamente, eu precisava limitar as respostas arp em uma interface aos endereços IP associados a essa interface, caso contrário, o Unix responderá em QUALQUER interface, independentemente do IP - o que realmente confunde todos os outros dispositivos na sub-rede.

Então... arptables instalados

sudo apt-get -y install arptables

Limitou as respostas em cada interface aos IPs da interface

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)

E pronto, todos os IPs estão respondendo nas portas corretas.

Homem! Espero não esquecer isso de novo!

informação relacionada