Estou lutando para fazer a rede funcionar em uma VM linux. Como é após a configuração, eu tenho isso ifconfig
:
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.19.190.144 netmask 255.255.0.0 broadcast 172.19.255.255
inet6 fe80::215:5dff:febe:6707 prefixlen 64 scopeid 0x20<link>
ether 00:15:5d:be:67:07 txqueuelen 1000 (Ethernet)
RX packets 30629 bytes 3428768 (3.2 MiB)
RX errors 0 dropped 409 overruns 0 frame 0
TX packets 351 bytes 53232 (51.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 78 bytes 6600 (6.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 78 bytes 6600 (6.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
E esta tabela de roteamento:
# ip route
default via 172.19.190.1 dev eth0 proto static metric 100
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.190.144 metric 100
Com essa configuração, posso pingar o gateway e os hosts externos da Internet, mas não consigo pingar os hosts na sub-rede 172.19.180.x, obtendo "host inacessível".
Quando eu faço manualmente
# ip route add 172.19.0.0/16 via 172.19.190.1 dev eth0
Então tudo funciona como esperado. Eu agora adiciono esta linha em /etc/sysconfig/network-scripts/route-eth0
:
172.19.0.0/16 via 172.19.190.1
Após a reinicialização, minha tabela de roteamento fica assim:
# ip route
default via 172.19.190.1 dev eth0 proto static metric 100
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.190.144 metric 100
172.19.0.0/16 via 172.19.190.1 dev eth0 proto static metric 100
E novamente não consigo acessar a sub-rede 172.19.180.x. A diferença entre isso e a adição manual ip route add
é que a última linha tem proto static metric 100
no final, enquanto que com a forma manual não.
O que preciso fazer para que tudo funcione em uma reinicialização?
ATUALIZAÇÃO: aqui está meu ifcfg-eth0
arquivo:
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth0
UUID=.... (masked)
DEVICE=eth0
ONBOOT=yes
IPADDR=172.19.190.144
PREFIX=16
GATEWAY=172.19.190.1
DNS1=172.19.190.240
DNS2=172.19.190.242
ATUALIZAÇÃO2:
Se eu remover a segunda rota ( ... src 172.19.190.144...
) e deixar apenas um padrão, tudo funcionará corretamente. Então a pergunta se torna: de onde vem a segunda rota e como me livrar dela?
O problema é que você tem duas rotas para
172.19/16
. Como eles têm o mesmo comprimento de máscara de rede (16 bits), o segundo substitui o terceiro.A terceira via:
foi adicionado pelo
/etc/sysconfig/network-scripts/route-eth0
. O segundo:tem um
proto kernel
, então ele foi adicionado pelo script que configurou o endereço IP da sua interface .A seguir, estou supondo que você está usando o Fedora. O prefixo de máscara de rede/rede que você usou para configurar seu endereço IP é muito grande. Você precisa adicionar ao arquivo
/etc/sysconfig/network-scripts/ifcfg-eth0
uma linha como:Resposta à atualização 2: Quando você adiciona um endereço IP, digamos 1.2.3.4, a uma interface, algumas rotas também são adicionadas. As rotas exatas dependem da ferramenta:
ip addr
irá forçá-lo a especificar o prefixo de rede (tamanho da máscara de rede) de 1.2.3.4 ou reclamar com veemência. Se você executar:ip addr add dev eth0 1.2.3.4/24
, você ganha uma1.2.3.4/24 dev eth0
rota como bônus (+ 2 rotas que você não vê, porque elas estão nalocal
tabela de roteamento, cf.ip route show table local
).ifconfig
assumirá que sua rede tem um prefixo de 24 se você não especificar uma máscara de rede e adicionar uma1.2.3.4/24 dev eth0
rota.Portanto, uma resposta direta à sua pergunta é: a
PREFIX=16
linha/etc/sysconfig/network-scripts/ifcfg-eth0
fez com que a segunda rota aparecesse.