• =?utf-8?Q?Re=3A_Probl=C3=A8mes_d=27acc=C3=A8s_HTTP/S_sur_les_serv?= =?u

    From Pierre Malard@21:1/5 to All on Tue Sep 10 19:40:01 2024
    --Apple-Mail=_D1BC4E29-BD6F-42C6-9DDE-18AC50718897
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;
    charset=utf-8

    Bonsoir,,

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

    Bonjour,

    Pour l'erreur wget :

    wget Connexion terminée par expiration du délai d'attente.

    Une solution proposée ici :

    https://forum.ubuntu-fr.org/viewtopic.php?id=708391

    Oui, mais là c’est le proxy qui n’y arrive pas aussi…


    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 <http://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

    « On ne peut pas pousser à fond l'éducation politique et l'éducation
    tout court de masses sans l'accompagner d'un développement
    économique, culturel et social parallèle. »
    Romain Gary - "Les racines du ciel"
    |\ _,,,---,,_
    /,`.-'`' -. ;-;;,_
    |,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 <--


    --Apple-Mail=_D1BC4E29-BD6F-42C6-9DDE-18AC50718897
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/html;
    charset=utf-8


    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pierre Malard@21:1/5 to All on Tue Sep 10 16:00:01 2024
    --Apple-Mail=_754E698D-DD2D-43B5-930E-9C51166B7501
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;
    charset=utf-8

    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 <http://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 <--


    --Apple-Mail=_754E698D-DD2D-43B5-930E-9C51166B7501
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/html;
    charset=utf-8

    <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Merci<br id="lineBreakAtBegi
  • From Pierre Malard@21:1/5 to All on Tue Sep 10 20:00:01 2024
    --Apple-Mail=_3ADA0C7B-3BE8-496B-857E-E706CB7E7CEB
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;
    charset=utf-8

    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 :

    $ nslookup security.debian.org
    Server: 172.16.1.1
    Address: 172.16.1.1#53

    Non-authoritative answer:
    Name: security.debian.org
    Address: 151.101.130.132
    Name: security.debian.org
    Address: 151.101.2.132
    Name: security.debian.org
    Address: 151.101.66.132
    Name: security.debian.org
    Address: 151.101.194.132

    nslookup ftp.fr.debian.org
    Server: 172.16.1.1
    Address: 172.16.1.1#53

    Non-authoritative answer:
    ftp.fr.debian.org canonical name = debian.proxad.net.
    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 :

    Utiliser wget avec un proxy : https://stackoverflow.com/questions/11211705/how-can-i-set-a-proxy-for-wget

    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 <http://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 <--


    --Apple-Mail=_3ADA0C7B-3BE8-496B-857E-E706CB7E7CEB
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/html;
    charset=utf-8


    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)