[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problèmes d'accès HTTP/S sur les serveurs à plusieurs résolution de nom

Salut,

Le problème n’est ni la résolution du nom qui se passe bien, ni le fait de passer par un proxy. Si c’était un problème de résolution de nom la commande wget n’indiquerait pas l’IP pointée, pas plus que le « tcptraceroute ».
Dans mon cas le proxy (non activé ici) est aussi touché par le problème.

En fait ce n’est pas lié à Wget. C’est lié à tout appel HTTP quelque soit l’outil utilisé sur le serveur (navigateur, APT, Wget, Curl, …). C’est effectivement gênant même avec la gestion des paquets puisque c’est le cas aussi pour le site security.debian.org. Heureusement que le site miroir « fr » ne répond que sur une adresse :

Server: 172.16.1.1
Address: 172.16.1.1#53

Non-authoritative answer:
Address: 151.101.130.132
Address: 151.101.2.132
Address: 151.101.66.132
Address: 151.101.194.132

Server: 172.16.1.1
Address: 172.16.1.1#53

Non-authoritative answer:
ftp.fr.debian.org canonical name = debian.proxad.net.
Address: 212.27.32.66

Mais cela ne vient peut-être pas de là en fait !

Toujours est-il qu’un simple reboot règle temporairement le problème. Il doit y avoir un autre service concerné.

Merci à vous

Le 10 sept. 2024 à 18:06, Bernard Bass <bernard.bass@visionduweb.com> a écrit :


Le 10 sept. 2024 15:55, Pierre Malard <pierre.malard@teledetection.fr> a écrit :
Merci

Le 10 sept. 2024 à 09:21, Michel Verdier <mv524@free.fr> a écrit :

Le 10 septembre 2024 Pierre Malard a écrit :

Depuis quelques mois nous avons des problèmes d’accès aux serveur ayant
plusieurs IP. C’est notamment le cas sur :

Quels sont ces problèmes ?

Voilà un exemple :
# wget --tries=2  --timeout=1  --no-check-certificate  https://huggingface.co/models
--2024-09-10 10:07:17--  https://huggingface.co/models
Résolution de huggingface.co (huggingface.co)… 18.161.111.80, 18.161.111.71, 18.161.111.116, ...
Connexion à huggingface.co (huggingface.co)|18.161.111.80|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.71|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.116|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.103|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:9800:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:7c00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:2000:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:da00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:3000:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:2e00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:3e00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:d800:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Nouvel essai.

--2024-09-10 10:07:22--  (essai :  2)  https://huggingface.co/models
Connexion à huggingface.co (huggingface.co)|18.161.111.80|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.71|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.116|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|18.161.111.103|:443… échec : Connexion terminée par expiration du délai d'attente.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:9800:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:7c00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:2000:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:da00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:3000:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:2e00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:3e00:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Connexion à huggingface.co (huggingface.co)|2600:9000:23d1:d800:17:b174:6d00:93a1|:443… échec : Ne peut attribuer l'adresse demandée.
Abandon.

Bon que les IPv6 ne passent pas c’est un filtrage de notre hébergeur mais les autres…

Il arrive bien jusqu’au serveur hugginface.co sur le port 443 :
# tcptraceroute huggingface.co 443
Selected device eth0, address 172.16.1.1, port 43031 for outgoing packets
Tracing the path to huggingface.co (18.161.111.103) on TCP port 443 (https), 30 hops max
 1  172.16.0.254  0.349 ms  0.373 ms  0.161 ms
 2  * * *
 3  195.221.109.201  0.986 ms  1.360 ms  1.234 ms
 4  vl1923-be6-ren-nr-montpellier-rtr-091.noc.renater.fr (193.51.185.108)  2.730 ms  1.760 ms  1.876 ms
 5  et-3-1-7-ren-nr-marseille1-rtr-131.noc.renater.fr (193.51.180.100)  3.540 ms  3.285 ms  3.484 ms
 6  et-0-1-0-ren-nr-marseille2-rtr-131.noc.renater.fr (193.51.177.127)  3.633 ms  3.471 ms  3.604 ms
 7  99.83.65.50  4.244 ms  3.780 ms  4.401 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  server-18-161-111-103.mrs52.r.cloudfront.net (18.161.111.103) [open]  3.560 ms  3.934 ms  1013.534 ms

Un NMap confire que le port 443 est bien ouvert :
# nmap -sS huggingface.co
Starting Nmap 7.93 ( https://nmap.org ) at 2024-09-10 10:16 CEST
Nmap scan report for huggingface.co (18.161.111.116)
Host is up (0.0037s latency).
Other addresses for huggingface.co (not scanned): 18.161.111.103 18.161.111.71 18.161.111.80 2600:9000:23d1:4e00:17:b174:6d00:93a1 2600:9000:23d1:6c00:17:b174:6d00:93a1 2600:9000:23d1:4800:17:b174:6d00:93a1 2600:9000:23d1:5600:17:b174:6d00:93a1 2600:9000:23d1:a800:17:b174:6d00:93a1 2600:9000:23d1:b600:17:b174:6d00:93a1 2600:9000:23d1:d400:17:b174:6d00:93a1 2600:9000:23d1:7200:17:b174:6d00:93a1
rDNS record for 18.161.111.116: server-18-161-111-116.mrs52.r.cloudfront.net
Not shown: 998 filtered tcp ports (no-response)
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.86 seconds



Le seul moyen trouvé pour rétablir une connexion est de redémarrer le
serveur. Mais cela ne solutionne rien car ça ne dure pas une journée.

Peut-être faire un restart des couches 1 à 1 pour identifier le point de
blocage : resolv, dns, firewall, réseau.

Je dois bien avouer que la différence entre « resolv » et « dns » ne me saute pas aux yeux. On ne s’appuie pas sur des services comme « NetworkManager » ou autre. Comme il s’agit de serveurs on en a aucun besoin de changer d’IP toutes les 5mn. Du coup on est retourné vers la gestion dans /etc/nework/interfaces et une gestion de résolution DNS manuelle dans un vrai fichier /etc/resolv.conf pointant sur notre serveur DNS.

J’ai essayé de fournir 8.8.8.8 comme résolveur de noms dans /etc/resolv.conf sans plus de succès.
Pour ce qui est d’un pare-feu, il n’y en a pas en local et, comme je l’écrivais, on a regardé comment était configuré le routeurs/pare-feu par lequel on passe. Il n’y a aucun blocage ni ré-écriture de paquet. D’ailleurs, s’il y avait un blocage, ça n’arriverai certainement pas à destination.

Pour ce qui est du réseau il fonctionne bien. D’ailleurs le « tcptraceroute » le montre. Il n’y a aucun problème pour atteindre la destination.

Je viens de faire le test sur notre serveur DNS qui présentait les mêmes symptôme. Là, je sais comment vider le cache DNS et je l’ai fait pour le forcer à ré-interpréter la résolution du nom depuis la racine. Cela ne change absolument rien !
Par contre, un reboot remet tout au carré. Qu’est-ce qui merde ?

Je ne comprends rien à ce phénomène. Que les serveurs sortent avec la même IP ou pas, selon les cas ça passe ou pas sur ces sites. Le seul critère commun que l’ai trouvé c’est que ce sont tous des sites déclarés avec plusieurs IP sur le nom DNS déclaré. Mais il me semble que ça devrait fonctionner quand même.


Si vous avez une idée nous sommes preneurs car là, on sèche.

Il faudrait plus d'infos pour pouvoir t'aider
Peut-être les logs autour du moment où ça bloque


-- 
Pierre Malard

   « SPAM : Spieced Pork and Meat »
                                       Pierre Dac (Londres, 1944)
Extrait de « Pierre DAC parle au Français » sur Radio Londres, le 24 mars 1944, dans Drôle de guerre, éditions Omnibus (2008), pages 93 à 96. (https://www.epi.asso.fr/revue/articles/a1602d.htm)

   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



-- 
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France

Tél : +33 626 89 22 68

  « La mondialisation de l'économie a, « en moyenne », eu pour conséquence
     l'augmentation du niveau de vie « moyen ».
     Un homme avec la tête dans un four et les jambes dans un congélateur a,
     « en moyenne », une température corporelle idéale... »
                                         Philippe Val - France Inter 09/04/2001
   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply to: