Network don't work/Le réseau marche pas

[1Poireau]

Hi everyone,
I don’t know why but the internet stopped working today on my server, even if i reboote. I don’t know where to start troubleshooting so can you help me ?
I have these logs also if you want:

Salut tout le monde,
Je ne sais pas pourquoi mais la connexion internet à arrêtée de fonctionner aujourd’hui sur mon serveur, même après un reboot. Je ne sais pas où commencer pour debugger tout ça donc pouvez-vous m’aider ?
J’ai aussi ces logs si vous voulez:

[1Poireau]

Note:
I have also recently setup a Pi-Hole on a Raspberry why is my default DNS on my network, but i don’t think that’s the problem because the other devices on my network seems to work. I have also shutdown it while troubleshooting but still don’t have internet

J’ai aussi récemment configuré un Pi-Hole sur mon Raspberry qui est le DNS par défaut de mon réseau, mais je ne pense pas c’est le problème car les autres appareils marchent bien. Je l’ai d’ailleurs éteint lors de mon debuggage au cas où et ça marche toujours pas

[tierce]

Dans ta première capture d’écran il est dit : No default rout for IPv4…

Sauf erreur de ma part, le principe est le suivant.

Lorsque ta machine démarre, son interface réseau câblée (ex: eth0, enp3s0, …) étant très probablement configurée pour recevoir une adresse IP (v4 via DHCP, v6 via NPD ou les deux).

Restons concentré·e sur l’ipv4, en supposant que ton Pi-Hole soit le serveur DHCP et si ce n’est pas le cas, c’est probablement ton modem/routeur.

Est-ce que ta machine à reçu une adresse ?

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:24:8c:1e:67:46 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.9/24 brd 192.168.1.255 scope global enp3s0
       valid_lft forever preferred_lft forever
    inet6 fe80::224:8cff:fe1e:6746/64 scope link 
       valid_lft forever preferred_lft forever

Dans l’exemple ci-dessus, l’interface enp3s0 a reçu une ip 192.168.1.9/24.

Est-ce que ta machine dispose d’une « route vers Internet ou route par défaut » ?

$ ip r s
default via 192.168.1.1 dev enp3s0 onlink 
169.254.0.0/16 dev enp3s0 scope link metric 1000 
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.9

Dans l’exemple ci-dessus, la defaut (qui pourrait aussi s’appeler 0.0.0.0) dit qu’il faut passer par 192.168.1.1 pour aller « vers Internet ». Et cette adresse IP est censée être celle de ton Pi-Hole ou de ton modem/routeur.

C’est ce qui s’appelle la passerelle ou gateway en anglais.

Est-ce que les deux machines savent se parler ?

$ ping -c3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.799 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.731 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.736 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.731/0.755/0.799/0.030 ms

Dans l’exemple ci-dessus, ta machine envoie un paquet ICMP vers la passerelle et cette dernière lui répond et les réponses arrivent en quelques micro secondes.

$ ping -c3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.9 icmp_seq=1 Destination Host Unreachable
From 192.168.1.9 icmp_seq=2 Destination Host Unreachable
From 192.168.1.9 icmp_seq=3 Destination Host Unreachable

--- 192.168.1.99 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2027ms
pipe 3

Dans l’exemple ci-dessus, étant le genre de réponse si la passerelle est injoignable (unreachable en anglais).

Est-ce que ta machine peut aller vers Internet ?

Imaginons essayer d’atteindre l’ip 80.67.172.144 (qui est l’adresse de yunohost.org).

J’utilise directement l’adresse IP pour voir si ta machine parvient à atteindre Internet sans faire appel à la résolution de nom (DNS).

$ ping -c3 80.67.172.144
PING 80.67.172.144 (80.67.172.144) 56(84) bytes of data.
64 bytes from 80.67.172.144: icmp_seq=1 ttl=51 time=32.8 ms
64 bytes from 80.67.172.144: icmp_seq=2 ttl=51 time=32.7 ms
64 bytes from 80.67.172.144: icmp_seq=3 ttl=51 time=32.8 ms

--- 80.67.172.144 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 32.692/32.762/32.802/0.050 ms

Dans l’exemple ci-dessus, il y a bien une réponse du serveur et donc ta machine a bien accès à Internet.

Est-ce que la résolution de nom (DNS) fonctionne ?

En effet, une machine peut très bien avoir accès à Internet, mais son serveur de nom DNS serait injoignable ou dysfonctionnel.

Pour ce faire, je vais reprendre la commande précédente, mais en demandant d’atteindre yunohost.org au lieu de son IP.

$ ping -c3 yunohost.org
PING yunohost.org (80.67.172.144) 56(84) bytes of data.
64 bytes from yunohost.org (80.67.172.144): icmp_seq=1 ttl=51 time=33.1 ms
64 bytes from yunohost.org (80.67.172.144): icmp_seq=2 ttl=51 time=33.0 ms
64 bytes from yunohost.org (80.67.172.144): icmp_seq=3 ttl=51 time=32.9 ms

--- yunohost.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 32.946/33.000/33.056/0.044 ms

Dans l’exemple ci-dessus, le serveur de nom fonctionne et parviens donc à faire la résolution de nom en trouvant l’adresse IP du domaine yunohost.org, d’envoyer des paquets et de les recevoir.

Si ta machine a bien une IP, une passerelle et qu’elle sait atteindre Internet mais que la résolution de nom ne fonctionne pas, c’est une autre étape…

[1Poireau]

Alors merci beaucoup d’avoir pris le temps d’argumenter autant ta réponse, alors voici ce que j’obtiens:

Et le 192.168.0.254 est mon routeur, qui fait le DHCP

[tierce]

L’interface enp37s0 n’a pas d’adresse ip sur le réseau 192.168.0.0/24.

Ça ne peut donc pas fonctionner.

Tu peux utiliser la commande suivante pour faire une demande d’adresse sur ton réseau pour l’interface enp37s0 de la machine concernée.

$ sudo dhclient -4 -v -i enp37s0

-4 pour demander une IPv4, -v pour être verbeux et afficher un peu de blabla et -i pour définir l’interface qui fait la demande d’adresse IP.

Et voir ce que donnent les messages.

Et éventuellement vérifier le contenu du fichier de configuration du réseau de la machine concernée.

$ cat /etc/network/interfaces

[1Poireau]

Alors au final le problème ne venait pas de Yunohost directement, mais plutôt du fait que mon serveur soit branché à un CPL et malgré le fait que les voyants semblaient indiquer que tout était ok, il s’était déconnecté du réseau tout seul.

Mais merci quand même, et désolé d’avoir fait perdre de ton temps pour un problème au final si bête…