Por que nic com máscara de sub-rede incorreta ainda pode pingar o modo de gate?

Question

Primeiro, minha configuração de rede era assim:

$ ip a
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 3c:97:0e:bd:b1:68 brd ff:ff:ff:ff:ff:ff
    inet 10.66.65.2/24 brd 10.66.65.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:eff:febd:b168/64 scope link 
       valid_lft forever preferred_lft forever

$ ip r
default via 10.66.65.254 dev em1  proto static 
10.66.65.0/24 dev em1  proto kernel  scope link  src 10.66.65.2  metric 1

desta forma, a máscara de sub-rede da rede está incorreta. Eu não tenho acesso à internet, mas posso fazer ping no gateway 10.66.65.254.

Depois eu libero a tabela de rotas e o endereço IP do em1 e reinicio o nic. E eu tenho uma nova tabela de rotas e ip:

$ ip a s dev em1
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 3c:97:0e:bd:b1:68 brd ff:ff:ff:ff:ff:ff
    inet 10.66.65.2/23 brd 10.66.65.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:eff:febd:b168/64 scope link 
       valid_lft forever preferred_lft forever
$ ip r
default via 10.66.65.254 dev em1  proto static 
10.66.64.0/23 dev em1  proto kernel  scope link  src 10.66.65.2  metric 1

e eu posso acessar a internet agora.

O que eu acho que aconteceu antes de eu mudar de reiniciar as nics é como: o pacote para a internet tem um destino de dizer 172.1.1.1 e 10.66.65.2 como fonte, então ele procura a tabela de rotas e sai em pensamento em1, então o gateway recebeu o pacote, mas quando o pacote está voltando para em1, o gateway não pode encontrar uma entrada de rota apropriada para 10.66.65.2/24, então descartou o pacote, então não consigo acessar a internet.

Mas eu estou querendo saber por que eu posso pingar o gateway, por que ele é capaz de enviar pacotes para mim desta vez?

Obrigado

    

Answer 1

Sua máscara estava bem para começar, pelo menos até o ponto de contato com o gateway. Na verdade, esta linha,

   inet 10.66.65.2/24

garante que o seu gateway e você pertençam à sub-rede same e, na verdade, você fez acessar seu gateway e recebeu uma resposta. Portanto, a razão pela qual você não pode acessar a Internet deve ser procurada em outro lugar. Duas possibilidades: 1) o seu gateway estava off-line, 2) o seu DNS não estava corretamente configurado em /etc/resolv.conf.

No entanto, observe também que, após liberar suas informações de rede, a sub-rede recebida automaticamente do DHCP, 10.66.65.0/23 , é mais ampla do que a acima . Ele contém completamente 10.66.65.0/24 , de modo que você conseguiu se conectar ao seu gateway mesmo quando tinha a sub-rede menor, mas você perdeu a possibilidade de vincular para outras máquinas na sua LAN. Então, além de corrigir o arquivo /etc/resolv.conf , você pode querer mudar a sub-rede para a versão correta mais ampla. Você pode fazer isso invocando DHCP da seguinte forma:

ip link set dev em1 down
ip addr flush dev em1
ip link set dev em1 up
dhclient -v em1

A opção -v (verbose) imprime na saída padrão as várias etapas da negociação com o servidor DHCP, mas não está disponível em todas as versões dhclient .

Se você tiver uma NIC com um endereço IP estático, poderá alterar a sub-rede da seguinte forma:

ip link set dev em1 down
ip addr flush dev em1
ip link set dev em1 up
ip addr add 10.66.65.2/23 dev em1

e é isso.

    

Answer 2

O host 10.66.65.2 com um / 2 4 significa que 10.66.6 5 .0 a 10.66.65.255 estão na mesma sub-rede, então é claro que acho que o roteador 10.66.65.254 estava na mesma sub-rede.

O host 10.66.65.2 com / 2 3 significa que 10.66.6 4 .0 a 10.66.65.255 estão na mesma sub-rede, portanto, é claro acho que o roteador 10.66.65.254 estava na mesma sub-rede.

Se a sub-rede / 23 estivesse correta, isso significaria que algumas transmissões de sub-rede teriam sido mal gerenciadas pelo seu host, e isso significaria que seu host teria que confiar no gateway para encaminhar quadros que deveria direcionados diretamente para os hosts 10.66.6 4 .x. Ou, mais provavelmente, o gateway teria enviado avisos redirecionamento ICMP para seu host, informando que poderia endereçar esses pacotes diretamente para seus hosts de destino na camada de link.

A configuração incorreta da máscara de sub-rede provavelmente não foi a origem de sua falha em obter conectividade com a Internet.