Os hosts na sub-rede só podem acessar a sub-rede de hosts diretamente

Question

Recentemente, configurei o Proxmox como um host de virtualização. É apenas KVM + Debian em uma boa distribuição linux. Minha rede doméstica é 192.168.12.0/24. Eu queria usar 192.168.14.0/24 como a sub-rede para todas as minhas VMs na máquina proxmox. Eu uso o DHCP para configurar quase todos os meus hosts. Se eu quiser um 'static-ip' eu geralmente configuro uma reserva DHCP para o dispositivo manualmente. Então, eu queria que minhas VMs obtivessem endereços DHCP na sub-rede 192.168.14.0/24.

Quando instalei o Proxmox, criei uma ponte chamada vmbr0 , que é preenchida com eth0 . O endereço IP da ponte é 192.168.12.12 .

Eu adicionei uma ponte em /etc/network/interfaces chamado vmbr14 em ponte com eth0.14 . Eu dei um IP de 192.168.14.12 . Eu também modprobe'd no módulo 8021q e adicionei a /etc/modules .

Meu servidor DHCP está em outra máquina 192.168.12.95 com uma interface eth0 . Eu adicionei outra interface chamada eth0.14 e dei o IP de 192.168.14.95 . Eu atualizei /etc/dhcp/dhcpd.conf com outro pool para a sub-rede 192.168.14.0 . A rota padrão especificada é 192.168.14.12 , a máquina Proxmox. O DHCP funcionou imediatamente sem problemas.

Para obter os hosts na rede 192.168.12.0/24 para saber como rotear 192.168.14.0/24 , fui ao meu gateway da Internet ( 192.168.12.2 ) e adicionei uma rota da seguinte forma

192.168.14.0    192.168.12.12   255.255.255.0   UG    1      0        0 eth2

A caixa proxmox já tem o encaminhamento ativado para IPv4

ericu@basov:~$ cat /proc/sys/net/ipv4/ip_forward 
1

Depois disso, as coisas simplesmente funcionaram. Eu posso SSH e pingar minhas VMs da minha área de trabalho sem problemas.

Mas nas próprias VMs, não consigo alcançar 192.168.12.95 only 192.168.14.95 . Fiz um ping em uma das VMs para 192.168.12.95 e o pacote capturado usando tcpdump

ericu@katz:~$ sudo tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:50:16.007898 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 18, length 64
18:50:17.010380 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 19, length 64
18:50:18.012969 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 20, length 64
18:50:19.015433 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 21, length 64
18:50:20.018043 IP 192.168.14.130 > 192.168.12.95: ICMP echo request, id 11498, seq 22, length 64

Os pacotes obviamente chegam à máquina, mas não tenho ideia do que acontece depois disso. A máquina simplesmente não responde. O TCP também não funciona.

ericu@katz:~$ sudo tcpdump -n tcp port 3000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:53:21.048128 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 665263 ecr 0,nop,wscale 7], length 0
18:53:22.051442 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 666264 ecr 0,nop,wscale 7], length 0
18:53:24.060540 IP 192.168.14.130.58499 > 192.168.12.95.3000: Flags [S], seq 2306774687, win 14600, options [mss 1460,sackOK,TS val 668268 ecr 0,nop,wscale 7], length 0

Se eu tentar acessar o IP de 192.168.14.95 das VMs, tudo funcionará bem.

Se eu ifdown eth0.14 na máquina 192.168.12.95 for alcançável pelas VMs. Obviamente, isso não é prático, pois o servidor DHCP precisa estar acessível.

Por que as máquinas na sub-rede 192.168.14.0/24 só alcançam a máquina usando o endereço 192.168.14.95 e não o endereço 192.168.12.95 ?

A é a tabela de roteamento em 192.168.12.95

ericu@katz:~$ ip route show
default via 192.168.12.2 dev eth0  metric 100 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.95 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.95 
ericu@katz:~$ 

Esta é a tabela de roteamento em 192.168.14.130

[ericu@squid3 ~]$ ip route show
default via 192.168.14.12 dev ens18  proto static  metric 1024 
192.168.14.0/24 dev ens18  proto kernel  scope link  src 192.168.14.130 
[ericu@squid3 ~]$ 

Para solucionar esse problema, criei uma VM na minha área de trabalho. Eu editei /etc/network/interfaces como segue

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp


auto eth0.14
iface eth0.14 inet static
    address 192.168.14.14
    netmask 255.255.255.0

A máquina obteve um endereço DHCP no eth0 de 192.168.12.172 . De 192.168.12.130 , ainda não consegui acessá-lo usando 192.168.12.172 . Na VM de teste, mudei /etc/iproute2/rt_tables para se parecer com o seguinte

#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
14 vlan14

Eu então executei os seguintes comandos

root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
192.168.14.0/24 dev eth0.14  proto kernel  scope link  src 192.168.14.14 
root@ubuntuvmdesktop:/home/ericu# ip route del 192.168.14.0/24 dev eth0.14 src 192.168.14.14
root@ubuntuvmdesktop:/home/ericu# ip route show
default via 192.168.12.2 dev eth0 
192.168.12.0/24 dev eth0  proto kernel  scope link  src 192.168.12.172 
root@ubuntuvmdesktop:/home/ericu# ip route add 192.168.14.0/24 dev eth0.14 src 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route add default via 192.168.14.12 dev eth0.14 src 192.168.14.14 table  vlan14
RTNETLINK answers: Network is unreachable
root@ubuntuvmdesktop:/home/ericu# ip rule add from 192.168.14.14 table vlan14
root@ubuntuvmdesktop:/home/ericu# ip route show table vlan14
192.168.14.0/24 dev eth0.14  scope link  src 192.168.14.14 

Depois de fazer isso, a VM com IP pode acessar a máquina usando 192.168.14.14 e 192.168.12.172

[ericu@squid3 ~]$ nc -v 192.168.12.172 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.12.172:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ nc -v 192.168.14.14 22
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.14.14:22.
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
^C
[ericu@squid3 ~]$ 

Portanto, esta é pelo menos uma maneira de corrigir o problema. No entanto, eu realmente não entendo o que isso faz. Eu entendo que eu adicionei uma tabela de roteamento separada chamada 'vlan14' para a máquina. Meu palpite é que usar ip rule add de alguma forma direciona o tráfego destinado a 192.168.14.14 para sua própria tabela de roteamento. Isso isola o roteamento das duas sub-redes em sua própria tabela de roteamento? No entanto, todas as alterações de rota que fiz usando ip route não persistem durante a reinicialização. Parece que preciso atualizar /etc/network/interfaces para indicar, de alguma forma, que as rotas devem entrar nessa tabela de roteamento alternativa.

Alguém pode explicar como funciona a tabela de roteamento separada? Alguém poderia explicar como alterar minha configuração para que as alterações feitas usando o comando ip sejam persistentes nas reinicializações?

    

Answer 1

Todo o roteamento do linux é feito por meio de tabelas de roteamento.

Uma instalação padrão sem modificações terá uma tabela "principal", uma tabela "padrão" e uma tabela "local". A tabela "principal" é mostrada se você executar ip route show sem opções adicionais; a tabela "local" é para os endereços de loopback ( 127.0.0.0/8 , ff00::/8 ). A tabela "padrão" é usada como último recurso e geralmente está vazia.

você pode adicionar instruções de roteamento especiais que se aplicam a destinos selecionados por um comando ip rule . Você adiciona regras com prioridade, os números mais baixos são correspondidos primeiro. Por padrão, estas são as regras padrão:

$ ip rule show
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

Um uso típico para regras é se você tiver um sistema multi-homed, ou seja, um sistema com mais de uma conexão à Internet. Nesta configuração, você precisa garantir que os pacotes de resposta sejam enviados pela mesma interface (por exemplo, conexão com a Internet) do pacote original. Normalmente, isso significa garantir que os pacotes com um determinado endereço de origem sejam enviados da interface correspondente:

# ip rule add from 1.2.3.4 pref 30000 lookup first
# ip rule add from 5.6.7.8 pref 30000 lookup second
# ip route add table first  default via 1.2.3.254 dev if1 src 1.2.3.4
# ip route add table second default via 5.6.7.254 dev if2 src 5.6.7.8

Agora, adicione uma rota padrão que passa pela conexão preferida (por exemplo, o volume mais rápido ou mais barato):

# ip route add table default via 5.6.7.254 dev if2 src 5.6.7.8

Anexe uma segunda rota padrão para quando a interface preferida for desativada:

# ip route add table default via 1.2.3.254 dev if1 src 1.2.3.4

Você precisará garantir que, quando a interface preferida voltar, sua rota padrão seja novamente a primeira da tabela. Eu geralmente faço isso adicionando essa rota, excluindo a outra e anexando-a novamente; provavelmente tem uma maneira melhor ...

Você pode usar seletores diferentes em ip rule add , por exemplo faça depender de uma marca de firewall que foi definida no pacote por iptables . Use ip rule add help para o que você pode colocar lá; Isso se aplica em geral a todos os comandos ip (por exemplo, ip help , ip route help ).

O Guia de Roteamento Avançado do Linux descreve tudo sobre esse assunto.

Para fazer sua configuração de rota manual se aplicar após as reinicializações etc., adicione-as às definições de interface /etc/network/interfaces com post-up adicionado na frente, elas serão executadas depois que a interface aparecer. man interfaces descreve todas as coisas possíveis que você pode colocar no arquivo interfaces .