Problème de connectivité DNS (MAJ Debian 4.0)

Bonjour,

Tout d’abord, je vous adresse un grand salut cordial.

Je viens vers vous car j’ai besoin de mettre à jour ma debian 4.0. Je suis hébérgé chez Nuxit, et j’ai suivi leur tuto pour cela. J’ai bien les bons dépôts :

[code]cat /etc/apt/sources.list

deb http://archive.debian.org/debian etch main contrib non-free
deb http://archive.debian.org/debian-volatile etch/volatile main contrib non-free
deb http://archive.debian.org/debian-security etch/updates main contrib non-free[/code]

Mais lorsque je fais une apt-get update, je reste bloqué sur 0% [Connecting to ftp.de.debian.org]

Je suis débutant en SSH, et j’essaie de me debrouiller comme un grand en suivant les tutos. Mais là j’ai besoin d’un coup de main. En vous remerciant.

Les adresses en question (archive.debian.org/debian etc) répondent bien pourtant.

Que te renvoie dig archive.debian.org ou au pire nslookup archive.debian.org si dig n’est pas installé ?

Et tant qu’on y est :
ping archive.debian.org
traceroute archive.debian.org
ls -lA /etc/apt/sources.list.d/
ls -lA /var/lib/apt/lists/

Le tout à exécuter sur ton serveur en SSH, bien sûr.

Faut dire que etch ça commence à dater sérieusement aussi…

Voici ce que me renvoie l’un comme l’autre :

;; global options: printcmd ;; connection timed out; no servers could be reached

C’est vrai, je suis à la bourre dans mes majs… mais mieux vaut tard que jamais :slightly_smiling:

debian.org/releases/etch/

[quote]Informations sur la version « Etch »

La version 4.0r9 de Debian GNU/Linux (connue sous le nom d’Etch) a été publiée le 22 mai 2010. La version 4.0 a été initialement publiée le 8 avril 2007.

La version 4.0 de Debian GNU/Linux a été remplacée par la version 5.0 de Debian GNU/Linux (“Lenny”). Les mises à jour de sécurité sont arrêtées depuis la fin février 2010. [/quote]
debian.org/releases/lenny/

[quote]
Informations sur la version « Lenny » de Debian

La version 5.0.10 de Debian GNU/Linux (connue sous le nom de Lenny) a été publiée le 10 mars 2012. La version 5.0.0 a été initialement publiée le 14 février 2009. Cette version comprend de nombreuses modifications décrites dans notre communiqué de presse et les notes de publication.

La version 5.0 de Debian GNU/Linux a été remplacée par la version 6.0 de Debian (“Squeeze”). Les mises à jour de sécurité sont arrêtées depuis le 6 février 2012. [/quote]
debian.org/releases/squeeze/

[quote]
Informations sur la version « Squeeze » de Debian

La version 6.0.8 de Debian (connue sous le nom de Squeeze) a été publiée le 20 octobre 2013. La version 6.0.0 a été initialement publiée le 6 février 2011. Cette version comprend de nombreuses modifications décrites dans notre communiqué de presse et les notes de publication.

La version 6.0 de Debian a été remplacée par la version 7.0 de Debian “Wheezy”). [/quote]

debian.org/releases/

Hum… pas de DNS du tout ? :119

cat /etc/resolv.conf

et

dig archive.debian.org @8.8.8.8

Lorsque je tape la commande, j’ai trois ip successives…

l’une du type : 127.xx.xx.xx
l’autre : 94.xx.xx.xx
enfin : 37.xx.xx.xx

Pour l’autre commande :

; <<>> DiG 9.3.4-P1.2 <<>> archive.debian.org @8.8.8.8 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached

Donne quand même les IP de tes DNS, qu’on puisse confirmer de l’extérieur qu’ils marchent bien (ou alors si tu veux pas, fais toi-même un dig archive.debian.org @94/37.xx.xx.xx mais depuis ta machine perso, pas depuis le serveur).

Enfin vu que le 8.8.8.8 fonctionne bien chez moi (serveurs Google, l’avantage pour les tests c’est que c’est facile à retenir) y’a l’air d’y avoir un problème plus gênant. Une histoire de firewall ? iptables -S (sur ton serveur)

Essaye aussi un ping 8.8.8.8 pour voir (toujours sur ton serveur). Et traceroute 8.8.8.8 tant qu’à faire.

Voilà

nameserver 127.0.0.1
nameserver 94.247.176.247
nameserver 37.0.73.73

N’oublie pas de regarder si j’ai pas édité mes messages entre le moment où tu les lis et celui où tu réponds, j’ai tendance à rajouter des trucs au fur et à mesure que j’y pense… :wink:

Bon aucun des deux DNS publics ne sont configurés en récursif, donc ils refusent la demande :

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33796 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available
Mais au moins ils répondent quand même, le problème est certainement quelque part sur ta machine (ou sur le réseau auquel elle est connectée, mais j’en doute un peu). J’attends tes réponses aux autres questions que j’avais rajoutées le temps que tu répondes.

Le 127.0.0.1 forcément il marche vu que c’est le mien. :mrgreen:

Alors le ping : 83 packets transmitted, 83 received, 0% packet loss, time 82009ms rtt min/avg/max/mdev = 21.814/25.009/64.048/6.624 ms
le traceroute :

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets 1 94.xx.xx.xx (94..xx.xx.xx) 0.064 ms 0.091 ms 0.029 ms

Normalement le traceroute complet c’est mieux hein (pour voir à quel moment ça se met à déconner :wink:) mais bon si ça ping, et c’est le cas, ça n’a pas d’importance en fait.

Désolé !

Ca commence à la ligne 2 en fait.

Pour iptables :

iptables v1.3.6: Unknown arg `-s' Try `iptables -h' or 'iptables --help' for more information.

iptables -Savec un S majuscule pour l’option.

J’avais déjà essayé même avec la maj

Au passage, je me suis permis d’éditer ton titre de sujet pour qu’il corresponde mieux à ton problème, et attirer plus facilement ceux qui pourraient t’aider.

Bon ton iptables doit être du même calibre que etch, c’est à dire antédiluvien. Fais toujours voir iptables -L mais j’ai plus de mal à lire ce format que je trouve incomplet, faut espérer que ça donnera déjà des pistes.

Voila ce que j’ai

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ok, tu n’as pas de firewall en place donc c’est pas ça non plus…

Mon impression c’est que ton hébergeur filtre les requêtes DNS vers l’extérieur de son réseau. Ça ou il y a un problème sur ta machine trop profond pour que je sois capable de voir d’où ça vient.

Le plus simple ça serait de demander confirmation au support technique de ton hébergeur. Demande leur s’ils filtrent les requêtes DNS vers l’extérieur de leur réseau, et si oui quel serveur DNS de chez eux tu peux utiliser (à mettre en première ligne de ton /etc/resolv.conf).

N’oublie pas d’inclure les infos suivantes :

  • les DNS Google 8.8.8.8 fonctionnent très bien à partir d’une machine tierce.
  • tu peux pinger le 8.8.8.8 sans problème à partir de ton serveur.
  • tu n’as pas de firewall sur le serveur (tout est en ACCEPT dans iptables sans aucune règle additionnelle).
  • quand tu dig domaine.com @8.8.8.8 (ou n’importe quel autre serveur DNS public) tu as un timeout.
  • tout le reste fonctionne très bien (SSH etc) ce qui fait penser à un filtrage du port 53 au niveau du réseau de ton hébergeur.

Pour le moment je peux pas t’en dire plus, désolé. Peut-être quelqu’un de plus calé que moi en réseau aura d’autres idées… N’hésite pas à repasser voir, et à nous tenir au courant de la réponse de ton hébergeur. :slightly_smiling:

Merci en tout cas déjà, pour toutes ces informations. J’ai transmis… on verra ce que l’on va me répondre. J’ai bien revérifier mes dépôts, ils sont corrects, donc y’a qu’eux pour me donner des détails, mais ils me poussent à prendre une heure d’assistance payante…

Edit : En fait je viens de comprendre pourquoi. Nuxit m’a bloqué tout flux parce qu’ils ont détecté une tâche périodique sur le serveur générant (130’000 paquets par seconde). Il faut donc que j’identifie le script en question et regle le soucis avant qu’ils me reconnectent. Désolé d’avoir mis du temps à faire le lien.

Je me permet de le mettre car je ne sais pas comment régler le problème :

cat /var/spool/cron/crontabs/psaadm 

* * * * * /var/tmp/pdflush >/dev/null 2>&1

* * * * * chmod +x /var/tmp/pdflush;/var/tmp/pdflush >/dev/null 2>&1

Mon frangin m’a dit que le serveur de messagerie pourrait avoir été piraté, mais comment… Nuxit me demande de faire le ménage.

[quote=“mrlaplume”]En fait je viens de comprendre pourquoi. Nuxit m’a bloqué tout flux parce qu’ils ont détecté une tâche périodique sur le serveur générant (130’000 paquets par seconde). Il faut donc que j’identifie le script en question et regle le soucis avant qu’ils me reconnectent. Désolé d’avoir mis du temps à faire le lien.

Je me permet de le mettre car je ne sais pas comment régler le problème :

cat /var/spool/cron/crontabs/psaadm 

* * * * * /var/tmp/pdflush >/dev/null 2>&1

* * * * * chmod +x /var/tmp/pdflush;/var/tmp/pdflush >/dev/null 2>&1

Mon frangin m’a dit que le serveur de messagerie pourrait avoir été piraté, mais comment… Nuxit me demande de faire le ménage.[/quote]
Là je pourrai pas t’aider car je ne sais pas de quoi il s’agit (faudrait que je fasse des recherches avant, et là tout de suite j’ai pas le temps) mais je te conseille vivement d’ouvrir un nouveau fil de discussion avec un titre approprié. Une question par fil, un fil par question, pour que les gens qui chercheront des informations dans le futur ne se retrouvent pas avec un tas de discussions différentes dans un même fil.

Et, si tu considères que le blocage de tes flux par ton hébergeur est la “solution” (l’explication, plus précisément…) à ton problème initial, marque ce fil comme “résolu” à l’aide de la coche verte à droite ==>
:006

Quant au problème du serveur piraté, sans vouloir en remettre une couche c’est ce qui arrive souvent avec les systèmes qui n’ont plus de mises à jour de sécurité depuis 3 ans 1/2. D’où la nécessité de faire des mises à jour régulières vers les nouvelles versions, même si c’est chiant et que ça prend du temps, car au final c’est moins de temps perdu de prévenir plutôt que de guérir.
Si ton serveur a réellement été piraté et qu’il n’est pas critique pour de la production, j’aurais tendance à te conseiller de le réinstaller complètement ça évitera les soucis (après avoir fait toutes les sauvegardes nécessaires bien entendu).