Alterar o gateway padrão e o IP atribuído via script

Question

Eu preciso de alguns apontando na direção certa, já tentei várias coisas diferentes nos últimos dias sem sucesso. Eu sou novo em usar o bash e o linux em geral.

Estou tentando detectar quando o gateway muda (somente na inicialização) e atualizo a configuração de IP estático. Eu tenho parcialmente este trabalho em que na primeira inicialização não há configuração de IP estático em /etc/dhcpcd.conf . Na primeira inicialização, posso simplesmente fazer o ping de um endereço IP e, se tiver êxito, atualizar a configuração com base na saída de ip r . Isso funciona sem nenhum problema.

A segunda parte está detectando (novamente apenas na inicialização) que o gateway foi alterado (por exemplo, o usuário alterou o IP do roteador ou alterou o ISP que usa uma configuração diferente). Mesmo conceito - pingar um endereço externo, mas nesta instância o ping falha, pois as informações do gateway (e o ip estático) estão incorretas.

Por exemplo,
IP estático configurado como 192.168.1.110
Roteador configurado como 192.168.1.254
Usuário altera sua rede e seu roteador agora é 192.168.0.1
O PI do Raspberry é inicializado e possui configuração estática .1.110 e gateway .1.254 .

Após a falha, o script tenta adicionar um novo gateway e endereço IP (de uma lista de endereços IP comuns usados para gateways em um arquivo) e executar ping em um endereço externo. Se tiver êxito, atualize a configuração estática em /etc/dhcpcd.conf e reinicialize. Se não tiver êxito, tente o próximo endereço IP na lista até encontrar um gateway válido.

Até onde eu trabalhei, eu preciso adicionar uma nova rota, um novo gateway padrão e um ping. Adicionando estes trabalhos, mas o ping ainda falha (apesar de estar passando pelo endereço IP correto). Saída de vários comandos abaixo após a nova rota, gateway e endereço IP terem sido adicionados.

ip r
default via 192.168.0.1 dev eth0 
192.168.0.1 dev eth0 scope link 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.110 metric 202 

netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

ping -q -w 10 -c 1 -I 192.168.0.1 -r 1.1.1.1
Tue 25 Sep 14:07:00 UTC 2018 Testing new gateway...192.168.0.1
PING 1.1.1.1 (1.1.1.1) from 192.168.0.110 : 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9330ms

Qualquer ajuda ou apontar na direção correta, é bem-vinda.

    

Answer 1

Primeiro, acho que você pode estar tentando resolver um problema que não está presente ...

Você diz ...

User changes their network and their router is now 192.168.0.1

Isso não é algo que ocorre com muita frequência, a grande maioria (de acordo com uma pesquisa do "Guia do Tom" > 80% das pessoas nem mesmo mudam a senha!)

No entanto, o que você está tentando fazer seria melhor servido com o dhcp, pelo menos dessa forma você só precisa reconfigurar as coisas uma vez no servidor dhcp, e todos os dispositivos aprenderiam o novo layout de rede.

No entanto, se você está morto contra o dhcp, a solução, embora não seja simples, você pode lograr sua saída ...

Muitos anos atrás, eu era responsável por configurar a rede em um dispositivo de armazenamento conectado à rede. Eu inicialmente tentei usar o DHCP e se isso falhou devido a nenhuma resposta do servidor, ele se configurou com o endereço IP 0.0.0.0 e pegou alguns segundos (5 IIRC) do tráfego de rede com o tcpdump. Em seguida, fez algumas análises estatísticas para descobrir o espaço de endereço local (se você olhar para src e dst no cabeçalho ip, os endereços no espaço local serão mais comuns) e, em seguida, usando ping, descobriu um endereço IP não usado espaço. O endereço IP do roteador também foi estatisticamente derivado usando solicitações arp. Funcionou muito bem em redes bem traficadas, mas mal em redes com pouco tráfego. À medida que os switches de rede se tornaram mais comuns e o hub mais barato ficou para trás, ele parou de funcionar quando o switch filtrou o tráfego que não é destinado ao seu endereço MAC.

Oh, as memórias de um projeto divertido.