Ping IPV4 impossible vers localhost

Slain · Le 03/09/2024, à 13:26

Bonjour,

J'espère que c'est la bonne section - j'ai la nette impression que c'est la pile réseau qui est partie en vrille mais je peux me tromper

Je contextualise un peu : le serveur Ubuntu est une machine virtuelle qui a été migrée de la version 20.04 vers la 22.04 vers le mois de mai.

J'essaie de faire l'histoire un peu courte, nous n'arrivons pas à renouveler un certificat Let's encrypt expiré, le message d'erreur indique "likely firewall problem".
Le prestataire qui gère le pare-feu physique sur place n'a vu aucun log, comme si le trafic n'arrivait pas au pare-feu.
L'enregistrement public est pourtant bon (ping tools sur mon smartphone en 4G indique bien la bonne adresse IP publique).

J'ai lancé sudo netstat -tunlp, voici le résultat :

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      50870/nginx: master
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      3808/systemd-resolv
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      50705/sshd: /usr/sb
tcp6       0      0 :::80                   :::*                    LISTEN      50862/apache2
tcp6       0      0 :::22                   :::*                    LISTEN      50705/sshd: /usr/sb
udp        0      0 127.0.0.53:53           0.0.0.0:*                           3808/systemd-resolv

Je sais, netstat est déprécié, mais je travaille dans un environnement orienté vers l'industrie et tout le monde est plutôt partisan de "tant que ça tourne, on ne touche pas".
De ce que j'en comprends, Apache2 écoute bien sur le port 80, mais ça semble n'être que sur l'IPV6?

Déjà, un point qui m'étonne (on va dire que c'est du bonus), c'est que resolv écoute sur une adresse IP locale, pourtant le fichier /etc/resolv.conf n'est pas de cet avis :

nameserver 192.168.150.1
options edns0 trust-ad
search 192.168.150.1

D'ailleurs, à chaque fois que je redémarre la VM, je dois remodifier ce fichier /etc/resolv.conf

Bref, je reviens à ma configuration réseau, voici ce que donne 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: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:2b:ee:00 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 192.168.150.10/24 brd 192.168.150.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe2b:ee00/64 scope link
       valid_lft forever preferred_lft forever

Et ip route :

default via 192.168.150.1 dev ens33 proto static
192.168.150.0/24 dev ens33 proto kernel scope link src 192.168.150.10

Et là où je soupçonne fortement que le souci ne vient pas d'Apache, ni de Nginx, ni du pare-feu physique, c'est si je fais ping localhost ou ping 127.0.0.1 :

PING localhost (127.0.0.1) 56(84) bytes of data.
^C
--- localhost ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7180ms

Pourtant, localhost est bien connu dans /etc/hosts

cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 dmz

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Et si je fais par exemple un ping ip6-localhost :

PING ip6-localhost(ip6-localhost (::1)) 56 data bytes
64 bytes from ip6-localhost (::1): icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from ip6-localhost (::1): icmp_seq=2 ttl=64 time=0.069 ms
64 bytes from ip6-localhost (::1): icmp_seq=3 ttl=64 time=0.069 ms
^C
--- ip6-localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2059ms
rtt min/avg/max/mdev = 0.050/0.062/0.069/0.009 ms

Je passe en partie mes autres diagnostics : apt upgrade fonctionne, de même que ping www.google.fr (donc j'en déduis que la résolution DNS fonctionne), les routes ne semblent pas forcément déconnantes par rapport à celles affichées sur d'autres machines virtuelles en Ubuntu que nous avons et qui n'ont pas de souci (peut-être en partie parce qu'elle n'ont pas de site Web publiquement accessible!).
Par ailleurs, Ufw et IPTables sont inactifs (puisque le filtrage des accès se fait au niveau du pare-feu physique).

Bref, mes excuses pour ce gros pavé, je sèche gravement.
Bien sûr, nous n'avons pas de prestataire de maintenance sur la VM (sinon c'était pas marrant), tout ça a été développé en interne par des salariés qui ne sont plus là...
J'ai connaissance par exemple de la commande netsh winsock reset qui résoud pas mal de soucis sur les postes Windows, mais je n'ai trouvé aucun équivalent sous Ubuntu, ni même plus globalement dans le noyau Linux...

Si quelqu'un a une idée, je suis preneur...

Merci d'avance
Modération : déplacé vers la section Virtualisation et Émulation qui semble plus appropriée.

Dernière modification par Ayral (Le 03/09/2024, à 13:51)

jplemoine · Le 03/09/2024, à 14:18

Au début de /etc/resolv.conf, il y a normalement,un pavé qui commence par

/etc/resolv.conf a écrit :

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.

Slain a écrit :

je dois remodifier ce fichier /etc/resolv.conf

Et tu ne t'es pas dit que c'était peut-être pas la bonne manière de faire ?

Slain a écrit :

Bien sûr, nous n'avons pas de prestataire de maintenance sur la VM (sinon c'était pas marrant), tout ça a été développé en interne par des salariés qui ne sont plus là...

Et c'est peut-être là qu'est le problème. Il y a peut-être eu des "bricolages" qui ont fonctionné un certain temps.

- Apache n'écoute qu'en tcp6 : ça peut être soit un problème de configuration général, soit un problème de vhost.
- le ssh écoute sur toutes les cartes. Il n'y a apparemment pas de différenciation entre la patte admin et la patte prod... (il faudrait 2 cartes réseau ou au moins 2 passerelles)
- A partir où c'est du pro, je ne dépanne pas dans le cadre de ce forum. Il faut vraiment une prestation pour reprendre la VM et remettre "tout droit".

Slain a écrit :

J'essaie de faire l'histoire un peu courte, nous n'arrivons pas à renouveler un certificat Let's encrypt expiré, le message d'erreur indique "likely firewall problem".
Le prestataire qui gère le pare-feu physique sur place n'a vu aucun log, comme si le trafic n'arrivait pas au pare-feu.

En fait, il faudrait savoir si c'est le traffic sortant qui a un problème ou si le traffic de réponse.

Le renouvellement du certificat part de ton serveur vers Let's encrypt. Let's encrypt renvoie un fichier qui doit être positionné dans un répertoire caché.
Puis Let's encrypt interroge l'URL qui correspond au fichier (de mémoire sur le port 80). S'il retrouve le fichier avec le bon contenu, c'est bon, sinon, le processus s’arrête.
Autre "particularité" de ce serveur : il y a un nginx (serveur web comme Apache) qui répond sur tcp 443 (https).

Slain · Le 03/09/2024, à 15:35

jplemoine a écrit :

Au début de /etc/resolv.conf, il y a normalement,un pavé qui commence par
/etc/resolv.conf a écrit :
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
Et tu ne t'es pas dit que c'était peut-être pas la bonne manière de faire ?

La honte, avec le nombre de fois que j'ai ouvert le fichier je suis passé à côté à chaque fois.

Cela dit, Netplan est configuré pour utiliser le 192.168.150.1 en tant que serveur DNS, pourquoi est-ce que la VM reprend le 127.0.0.53 à chaque redémarrage?

jplemoine a écrit :

Et c'est peut-être là qu'est le problème. Il y a peut-être eu des "bricolages" qui ont fonctionné un certain temps.

Je pense que tu connais le cercle vicieux, on répond à un besoin en vitesse "entre deux portes" ou on règle un souci en urgence, la documentation passe au second plan, et à chaque départ d'un salarié on perd des infos "utiles".

jplemoine a écrit :

- Apache n'écoute qu'en tcp6 : ça peut être soit un problème de configuration général, soit un problème de vhost.

Je ne comprends pas trop où, mais en désactivant apache, en modifiant le fichier /etc/nginx/sites-enabled/default pour qu'il écoute sur le port 80, et en redémarrant nginx, j'ai pu avoir Nginx qui écoute sur l'IPV4 :

sudo netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      52439/nginx: master
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      52439/nginx: master
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      3808/systemd-resolv
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      50705/sshd: /usr/sb
tcp6       0      0 :::22                   :::*                    LISTEN      50705/sshd: /usr/sb
udp        0      0 127.0.0.53:53           0.0.0.0:*                           3808/systemd-resolv

Cependant, ma VM est toujours incapable pinguer localhost en IPV4, et cURL comme wget n'arrivent pas à se connecter sur le port 80.

jplemoine a écrit :

- le ssh écoute sur toutes les cartes. Il n'y a apparemment pas de différenciation entre la patte admin et la patte prod... (il faudrait 2 cartes réseau ou au moins 2 passerelles)

Là-dessus je plaide la limitation physique du serveur, je ne peux pas attribuer de 2eme carte réseau à cette VM.

jplemoine a écrit :

- A partir où c'est du pro, je ne dépanne pas dans le cadre de ce forum. Il faut vraiment une prestation pour reprendre la VM et remettre "tout droit".

Je respecte ton point de vue. Je garde à l'esprit que le forum d'entraide est gratuit, que tu es bénévole autant que les autres membres qui aident, et ça paraît totalement normal d'aider en priorité les gens qui découvrent Ubuntu, qui veulent monter un labo maison ou simplement s'autoformer.
J'espère toutefois qu'une bonne âme voudra bien m'aider à comprendre ce que j'ai pu rater et/ou que le fait d'écrire ce que j'ai testé, les comportements que ça a eu m'aidera à trouver ce qui cloche. Si ça peut aussi aider d'autres utilisateurs qui ont un souci similaire, ça sera encore mieux.

jplemoine a écrit :

En fait, il faudrait savoir si c'est le traffic sortant qui a un problème ou si le traffic de réponse.
Le renouvellement du certificat part de ton serveur vers Let's encrypt. Let's encrypt renvoie un fichier qui doit être positionné dans un répertoire caché.
Puis Let's encrypt interroge l'URL qui correspond au fichier (de mémoire sur le port 80). S'il retrouve le fichier avec le bon contenu, c'est bon, sinon, le processus s’arrête.

D'après le log de Certbot :

 Timeout during connect (likely firewall problem)

Cette erreur apparaît au moment où le processus doit récupérer le fichier caché.
Par ailleurs, bien que (maintenant) nginx écoute sur le port 80 sur l'IPV4, l'accès en http est KO.

jplemoine a écrit :

Autre "particularité" de ce serveur : il y a un nginx (serveur web comme Apache) qui répond sur tcp 443 (https).

ça m'a surpris aussi.
Cela dit, même en désactivant/arrêtant apache et en demandant à nginx d'écouter sur le port 80, ça ne résout pas mon souci.
Je dois reconnaître que je suis dans le brouillard pour le moment.

Slain · Le 03/09/2024, à 15:52

En complément, j'ai également lancé la commande sudo tcpdump -i enp2s1 port 80 en même temps que sudo certbot renew --dry-run, pour voir si des paquets passent par le port 80 (si je ne me suis pas trompé de syntaxe).
Le résultat me fait (très) peur :

0 packets captured
0 packets received by filter
0 packets dropped by kernel

La même sur le port 443 me donne toutefois des paquets (dont l'IP semble venir de chez Cloudflare pour Let's encrypt, donc il semblerait que j'avance).
Je suis quand même surpris que la communication se fasse sur le port 443 puisque Certbot essaie de récupérer un fichier en http:// ?

Est-ce pertinent de mettre le résultat de tcpdump sur le port 443?

Dans la même veine, est-ce pertinent de tester en demandant à mon site nginx de n'écouter que sur le port 443 pour voir si un mécanisme standard "force" le passage de http vers https?
Edit : j'ai testé ce point, aucun changement.

Dernière modification par Slain (Le 03/09/2024, à 15:55)

jplemoine · Le 03/09/2024, à 16:09

Le problème de dépanner un pro, c'est la responsabilité.
Imagine que tu te trompes dans une commande et que ça "casse le serveur". Qui est responsable ?
Moi, toi, l'admin du forum,...
On dépasse le cadre de l’entraide entre simple utilisateurs.
Quand je dépanne dans le cadre du GULL, on ne touche pas à l'ordinateur tant que la personne n'a pas signé une décharge.
Dans cette dernière, il est clairement dit que ni l'intervenant, ni l'association,... ne peut être tenu responsable.
Que la personne a fait des sauvegardes et qu'elle a envisagé qu'elle pouvait "tout" perdre.

Tant que de l'extérieur, on arrive pas à afficher le site (réponse sur le port 80), le renouvelement du certificat Let's encrypt ne pourra pas se faire.
Le problème, c'est que désactiver Apache au profit de nginx ne suffit pas. S'il n'y a pas vhost configuré pour le port 80 sur nginx, ça ne fonctionnera pas.

Il faut vraiment faire une description de l'existant (sans rien changer) et de la cible puis voir comment on peut faire, le temps (et donc le budget) et voir s'il ne vaut mieux pas repartit "à zéro" et reconstriure une infra digne de ce nom.

Slain a écrit :

Je pense que tu connais le cercle vicieux, on répond à un besoin en vitesse "entre deux portes" ou on règle un souci en urgence, la documentation passe au second plan, et à chaque départ d'un salarié on perd des infos "utiles".

C'est pour ça que l'on fait une partie de la doc AVANT d'intervenir...Et on intervient pas "entre deux portes" ou on règle un souci en urgence.
On passe par un mécanisme de tickets dans un ITSM (ou au moins, on regroupe les infos au même endroit).

Slain a écrit :

Là-dessus je plaide la limitation physique du serveur, je ne peux pas attribuer de 2ème carte réseau à cette VM.

Là encore, il y a des solution "petit budget" : c'est moins "hermétique" mais on peut définir 2 passerelles : on sépare alors les flux avec des routes statiques.
Cela permet de séparer les flux internes (port 22 ok) et externes (pas de réponse sur le port 22).

Slain · Le 03/09/2024, à 16:40

jplemoine a écrit :

Le problème de dépanner un pro, c'est la responsabilité.
Imagine que tu te trompes dans une commande et que ça "casse le serveur". Qui est responsable ?

Je n'avais pas pris en compte l'aspect responsabilité, pour le coup.
Cependant, je doute qu'un bénévole ou un admin de forum puisse être tenu responsable du fait qu'une entreprise n'ait pas fait/testé ses sauvegardes?

Moi, toi, l'admin du forum,...
On dépasse le cadre de l’entraide entre simple utilisateurs.
Quand je dépanne dans le cadre du GULL, on ne touche pas à l'ordinateur tant que la personne n'a pas signé une décharge.
Dans cette dernière, il est clairement dit que ni l'intervenant, ni l'association,... ne peut être tenu responsable.
Que la personne a fait des sauvegardes et qu'elle a envisagé qu'elle pouvait "tout" perdre.

jplemoine a écrit :

Tant que de l'extérieur, on arrive pas à afficher le site (réponse sur le port 80), le renouvelement du certificat Let's encrypt ne pourra pas se faire.
Le problème, c'est que désactiver Apache au profit de nginx ne suffit pas. S'il n'y a pas vhost configuré pour le port 80 sur nginx, ça ne fonctionnera pas.

Donc le fait d'ajouter ces lignes (décommentées) dans mon fichier /etc/nginx/sites-enables/default ne suffirait pas à tes yeux?

# server {
#     listen 80;
#     root /var/www/html;
#     index index.html;
# }

jplemoine a écrit :

C'est pour ça que l'on fait une partie de la doc AVANT d'intervenir...Et on intervient pas "entre deux portes" ou on règle un souci en urgence.
On passe par un mécanisme de tickets dans un ITSM (ou au moins, on regroupe les infos au même endroit).

Pour avoir travaillé dans des entreprises plus grandes que l'actuelle, tu prêches un convaincu sur le système de tickets.
Idem sur la documentation, c'est bien plus facile de s'y retrouver (parfois même dans son propre travail) quand il suffit de se rendre sur un dossier partagé et lire les noms de fichiers pour savoir où trouver ses infos.
Mais en PME, c'est souvent piloté par le budget le plus faible

jplemoine a écrit :

Là encore, il y a des solution "petit budget" : c'est moins "hermétique" mais on peut définir 2 passerelles : on sépare alors les flux avec des routes statiques.
Cela permet de séparer les flux internes (port 22 ok) et externes (pas de réponse sur le port 22).

Intéressant, et je pense que les routes statiques sont gérées par le prestataire (qui gère le pare-feu physique), ça me paraîtrait assez logique qu'ils bloquent le port 22 depuis des pays exotiques ou depuis les adresses IP inconnues...

jplemoine · Le 03/09/2024, à 17:00

Slain a écrit :

Donc le fait d'ajouter ces lignes (décommentées) dans mon fichier /etc/nginx/sites-enables/default ne suffirait pas à tes yeux?
# server {
#     listen 80;
#     root /var/www/html;
#     index index.html;
# }

Tout dépend ce qu'il y a dans /var/www/html et comment est configuré le daemon de renouvellement du certificat Let's encrypt.
Il faut qu'il dépose le fichier au bon endroit pour que ce soit lisible.

Slain a écrit :

Mais en PME, c'est souvent piloté par le budget le plus faible

Sauf que le "pilotage par le coût" ne fonctionne pas sur la durée.

J'ai peur qu'un jour, il y ait une attaque en règle et là, ça va faire très mal.

Slain a écrit :

ça me paraîtrait assez logique qu'ils bloquent le port 22 depuis des pays exotiques ou depuis les adresses IP inconnues...

Logique mais est-ce que c'est réellement fait ? Y a-t-il eu des "pentests" ?

Slain · Le 04/09/2024, à 07:44

jplemoine a écrit :

Tout dépend ce qu'il y a dans /var/www/html et comment est configuré le daemon de renouvellement du certificat Let's encrypt.
Il faut qu'il dépose le fichier au bon endroit pour que ce soit lisible.

Pour la partie /var/www/html, son contenu est plutôt succinct mais devrait suffire pour afficher une page d'accueil :

ls -alh /var/www/html/
total 24K
drwxr-xr-x 2 root root 4,0K juin  14 12:22 .
drwxr-xr-x 3 root root 4,0K oct.  20  2021 ..
-rw-r--r-- 1 root root  11K juin  14 12:22 index.html
-rw-r--r-- 1 root root  612 oct.  20  2021 index.nginx-debian.html

Je vais essayer de chercher un peu où se trouvent les fichiers de configuration de Let's encrypt, pour voir si j'y comprends un peu mieux.

En parallèle, ci-dessous le contenu du fichier /etc/apache2/sites-enabled/000-default.conf, qui m'a guidé pour ajouter l'écoute du port 80 sur la configuration de Nginx :

<VirtualHost *:80>
#        Listen 80
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

jplemoine a écrit :

Sauf que le "pilotage par le coût" ne fonctionne pas sur la durée.
J'ai peur qu'un jour, il y ait une attaque en règle et là, ça va faire très mal.

A nouveau tu prêches un convaincu sur la partie coûts, je fais partie de ceux qui essaient en général de trouver le meilleur rapport réponse au besoin / durée de vie / prix.

Pour le risque d'une attaque, le contexte depuis quelques années donne bien souvent à croire que la question n'est pas "si" mais plutôt "quand" l'attaque en question aura lieu.
J'ose espérer que ça ne sera pas à ce moment-là que nous découvrirons que notre prestataire n'était pas bon.

jplemoine a écrit :

Logique mais est-ce que c'est réellement fait ? Y a-t-il eu des "pentests" ?

En toute honnêteté, je n'ai pas l'historique ni la réponse à ces questions.

Je tiens à te remercier pour le temps passé sur ce sujet, et pour tous tes conseils.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/09/2024, à 13:26

Ping IPV4 impossible vers localhost

#2 Le 03/09/2024, à 14:18

Re : Ping IPV4 impossible vers localhost

#3 Le 03/09/2024, à 15:35

Re : Ping IPV4 impossible vers localhost

#4 Le 03/09/2024, à 15:52

Re : Ping IPV4 impossible vers localhost

#5 Le 03/09/2024, à 16:09

Re : Ping IPV4 impossible vers localhost

#6 Le 03/09/2024, à 16:40

Re : Ping IPV4 impossible vers localhost

#7 Le 03/09/2024, à 17:00

Re : Ping IPV4 impossible vers localhost

#8 Le 04/09/2024, à 07:44

Re : Ping IPV4 impossible vers localhost

Pied de page des forums