web-dev-qa-db-fra.com

ifconfig non mis à jour avec la nouvelle adresse fournie par DHCP

J'ai une machine que j'ai configurée en tant que routeur à l'aide du serveur Ubuntu 17.10.

J'ai trois ports Ethernet: l'un que j'utilise en tant que WAN [appelé ici: $ {WAN}], et les deux autres que j'ai pontés en tant que réseau local.

Mon adresse WAN est fournie par le fournisseur de services Internet via DHCP.

/etc/network/interface:

auto ${WAN}
iface ${WAN} inet dhcp

J'ai ddclient installé, j'ai donc configuré un script pour tester qui fonctionne, voici sa sortie [légèrement modifié pour des raisons de sécurité]:

=================================================
WAN IP: via 'ip -4 addr show ${WAN}'
24.163.176.94
174.109.187.251
=================================================
External IP: via 'curl http://icanhazip.com'
174.109.187.251
=================================================
nslookup of mylan.us.to:
174.109.187.251

Notez les deux adresses IP répertoriées via ip -4 addr show ${WAN}. Habituellement, mon FAI me fait passer de manière aléatoire entre ces deux adresses IP. Au moment de l'exécution de ce script, l'adresse IP correcte est l'adresse 174.109.187.251. Cela m’a amené à vérifier ce que ifconfig a montré:

${WAN}: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 24.163.176.94  netmask 255.255.248.0  broadcast 24.163.185.255
        ether 90:fb:a6:88:a1:7a  txqueuelen 1000  (Ethernet)
        RX packets 823978  bytes 141634338 (141.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 93505  bytes 16976560 (16.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Vous remarquerez que inet affiché via ifconfig est l'adresse ancienne.

J'ai essayé de redémarrer le réseau via:

Sudo service networking restart

J'ai également redémarré la machine. La ifconfig donne toujours la mauvaise adresse IP et ip -4 addr show ${WAN} continue d'afficher les deux IP.

À part ces deux problèmes, tout le reste semble bien fonctionner. NAT est un NAT, le LAN est transféré via un réseau WAN, ddclient est mis à jour avec l'adresse IP correcte, etc.

Ubuntu étant très novice, j’ai atteint la limite de mes compétences en matière de débogage; vous ne savez donc pas pourquoi cette ancienne adresse IP reste fidèle?

MODIFIER:

Sudo ifdown ${WAN}
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp1s0/90:fb:a6:88:a1:7a
Sending on   LPF/enp1s0/90:fb:a6:88:a1:7a
Sending on   Socket/fallback
DHCPRELEASE on ${WAN} to 142.254.207.161 port 67 (xid=0x7948571c)

Puis sur:

Sudo ifup ${WAN}
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/${WAN}/90:fb:a6:88:a1:7a
Sending on   LPF/${WAN}/90:fb:a6:88:a1:7a
Sending on   Socket/fallback
DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0x92b2b512)
DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0x92b2b512)
DHCPREQUEST of 174.109.187.251 on ${WAN} to 255.255.255.255 port 67 (xid=0x12b5b292)
DHCPOFFER of 174.109.187.251 from 69.134.11.87
DHCPACK of 174.109.187.251 from 69.134.11.87
bound to 174.109.187.251 -- renewal in 28592 seconds.

Pourtant, dans syslog:

5924:Nov 16 17:23:30 router systemd-networkd[528]: enp1s0: DHCPv4 address 24.163.176.94/21 via 24.163.72.1

Pourquoi la différence?

Pour le commentateur qui a déclaré que/etc/network/interfaces était obsolète:

cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ${WAN}:
      dhcp4: yes
networkingserverdhcpifconfig
1
user760856

Selon la documentation, IFUPDOWN n’est pas préinstallé sur Ubuntu 17.10, mais j’ai dû l’installer à un moment de ma configuration (même si je ne me souviens pas de l’avoir fait).

En conséquence, j'avais IFUPDOWN en train de faire une demande de client DHCP ET networkd en faisant une deuxième demande de client DHCP. IFUPDOWN recevrait une adresse IP de mon FAI et networkd en recevait une autre.

Étant donné que je suis plus familier avec la méthode de configuration du réseau IFUPDOWN (ainsi que pour chaque "création d'un routeur HOW-TO" utilisant cette méthode), j'ai décidé de choisir strictement IFUPDOWN.

AVANT DE PROCÉDER À ENLIMINER LE RÉSEAU NETPLAN, CONFIRMEZ QUE VOUS AVEZ ICI INSTALLÉ: Sudo apt-get install ifupdown

J'ai ensuite désactivé netplan via les étapes suivantes:

cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ${WAN}:
      dhcp4: yes

J'ai modifié ceci pour:

/etc/netplan/01-netcfg.yaml
    # This file describes the network interfaces available on your system
    # For more information, see netplan(5).
    network:
      version: 2
      renderer: networkd
      ethernets:

... redémarré, ce qui corrigeait le problème que je rencontrais avec les deux adresses IP fournies par DHCP, qui m'a confirmé qu'IFUPDOWN fonctionnait désormais correctement, comme prévu.

J'ai vérifié cela de trois manières:

  • ip -4 addr show ${WAN} | grep -oP '(?<=inet\s)\d+(\.\d+){3}' - ne vois qu'une adresse fournie par DHCP que j'attends
  • curl http://icanhazip.com - voir l'adresse que j'attends
  • route - voir l'adresse que j'attends dans la chaîne.

J'ai ensuite désactivé netplan conformément au wiki netplan: https://wiki.ubuntu.com/Netplan en modifiant ma configuration grub: /etc/default/grub ligne de changement:

GRUB_CMDLINE_LINUX="ipv6.disable=1 netcfg/do_not_use_netplan=true"

... exécuté: Sudo update-grub, puis redémarrez la machine.

J'ai ensuite exécuté:

journalctl -p err
Nov 17 11:09:42 router systemd[1]: Failed to start Raise network interfaces.

Comme je n'aime pas voir les erreurs, j'ai émis: Sudo rm /lib/systemd/system-generators/netplan [qui n'est qu'un lien symbolique vers /lib/netplan/generate], puis redémarré.

'journalctl -p err', pas d'erreur.

grep netplan /var/log/syslog
Nov 17 13:12:07 router kernel: [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-16-generic root=UUID=1e26c91e-0805-44f7-9ae3-3a707fa0d311 ro ipv6.disable=1 netcfg/do_not_use_netplan=true

... pas d'erreur.

Donc, autant que je sache, netplan est effectivement désactivé (même si dans les versions précédentes, vous pouviez le désinstaller complètement avec apt-get, ce qui n’est plus possible en 17.10).

0
user760856