Apt-get update ne marche plus

Support Debian
#6

Alors c’est un informaticien qui à effectué les changements du coup je ne sais pas vraiment tout surtout pour le DNS.

Par contre je viens de voir sur /etc/resolv.conf que j’ai une adresse ip mais pas le nom de domaine…mais j’ai un 62.1… alors que d’après moi l’adresse ip du routeur c’est toujours 95… ou le nom de domaine c’est à dire webm…com

Le site internet est accessible depuis l’extérieur en https mais les connexions en SSH pour utiliser putty ne sont pas acceptées

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a4:ba:db:14:a7:39 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether a4:ba:db:14:a7:3b brd ff:ff:ff:ff:ff:ff

ip -4 addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 192.168.34.2/24 brd 192.168.34.255 scope global eth0 valid_lft forever preferred_lft forever

default via 192.168.34.1 dev eth0 192.168.34.0/24 dev eth0 proto kernel scope link src 192.168.34.2

ip -4 rule show

0: from all lookup local 32766: from all lookup main 32767: from all lookup default

Ping en interne client vers serveur = OK
Ping vers du serveur vers mon ordinateur (en interne) = OK
Ping du serveur vers wwww.google.fr = ne marche pas
Ping du serveur vers google.fr mais avec l’adresse ip de google =216.58.211.100 = OK
Site web accessible depuis internet en https avec le nom de domaine = ok
Site web accessible depuis internet en https avec l’ip = ne marche pas

a+

#7

A priori la connectivité IP est bonne. Reste la résolution DNS, donc l’adresse IP du ou les serveurs DNS. Le domaine n’est pas important pour la résolution des noms extérieurs.

Quel routeur ? La route par défaut a comme adresse de routeur 192.168.34.1.
De toute façon, il n’y a pas forcément de rapport entre le routeur et le DNS. Ce n’est que dans les box et petits routeurs que c’est la même machine.

#8

Autre chose quand je tape l’adresse internet du site 95…/login alors là il ne marche pas il me stipule que j’ai pas la permission.

A+

#9

Aucune importance. Cela ne concerne que la configuration des sites du serveur web.

#10

Voici ce qu’il y a dans nano /etc/resolv.conf
nameserver 62.193…

#11

Si tu ne donnes pas l’adresse complète, ça ne nous sert à rien. Et c’est plutôt avec “l’informaticien” qu’il faut vérifier si c’est bien un serveur DNS récursif joignable par la machine à son nouvel emplacement.
Si c’est l’adresse d’un serveur DNS situé à l’extérieur du réseau, il faut que le pare-feu de la DMZ laisse passer les requêtes DNS vers celle-ci.

#12

Ok super !

Je viens de comprendre :slightly_smiling:

#13

Tant mieux mais les lecteurs aimeraient aussi connaître le dénouement de l’histoire.

#14

Ben finalement cela ne marche pas !

Je suis allé sur mon ordinateur sous window sur le réseau interne et j’ai tapé ipconfig/all
il indique que mon DNS est 10.33.1.12 et j’ai la confirmation pour l’informaticien

J’ai effectué un ping sur mon serveur sur 10.33.1.12 et cela marche bien.

Je vais sur le serveur avec putty et là j’indique bien dans nano /etc/resolv.conf "nameserver 10.33.1.12"
Je suis allé aussi sur Webmin et il indique bien 10.33.1.12

Du coup je lance apt-get update … mais hélas c’est toujours l’échec …:frowning:

[code] apt-get update
Err http://ftp.fr.debian.org jessie InRelease

Err http://ftp.fr.debian.org jessie-proposed-updates InRelease

Err http://ftp.fr.debian.org jessie Release.gpg
Impossible d’initialiser la connexion à ftp.fr.debian.org: 80 (2a01:e0c:1:1598 ::2). - connect (101: Le réseau n’est pas accessible) [IP : 2a01:e0c:1:1598::2 8 0]
Err http://ftp.fr.debian.org jessie-proposed-updates Release.gpg
Impossible d’initialiser la connexion à ftp.fr.debian.org: 80 (2a01:e0c:1:1598 ::2). - connect (101: Le réseau n’est pas accessible) [IP : 2a01:e0c:1:1598::2 8 0]
Err http://www.deb-multimedia.org jessie InRelease

Err http://www.deb-multimedia.org jessie Release.gpg
Impossible de se connecter à www.deb-multimedia.org:http :
Err http://security.debian.org jessie/updates InRelease

Err http://security.debian.org jessie/updates Release.gpg
Impossible d’initialiser la connexion à security.debian.org: 80 (2001:a78:5:0:216:35ff:fe7f:be4f). - connect (101: Le réseau n’est pas accessible) [IP : 2001:a78:5:0:216:35ff:fe7f:be4f 80]
Lecture des listes de paquets… Fait
W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/jessie/InRelease

W: Impossible de récupérer http://security.debian.org/dists/jessie/updates/InRelease

W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/jessie-proposed-updates/InRelease

W: Impossible de récupérer http://www.deb-multimedia.org/dists/jessie/InRelease

W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/jessie/Release.gpg Impossible d’initialiser la connexion à ftp.fr.debian.org: 80 (2a01:e0c:1:1598::2). - connect (101: Le réseau n’est pas accessible) [IP : 2a01:e0c:1:1598::2 80]

W: Impossible de récupérer http://ftp.fr.debian.org/debian/dists/jessie-proposed-updates/Release.gpg Impossible d’initialiser la connexion à ftp.fr.debian.org: 80 (2a01:e0c:1:1598::2). - connect (101: Le réseau n’est pas accessible) [IP : 2a01:e0c:1:1598::2 80]

W: Impossible de récupérer http://www.deb-multimedia.org/dists/jessie/Release.gpg Impossible de se connecter à www.deb-multimedia.org:http :

W: Impossible de récupérer http://security.debian.org/dists/jessie/updates/Release.gpg Impossible d’initialiser la connexion à security.debian.org: 80 (2001:a78:5:0:216:35ff:fe7f:be4f). - connect (101: Le réseau n’est pas accessible) [IP : 2001:a78:5:0:216:35ff:fe7f:be4f 80]

W: Le téléchargement de quelques fichiers d’index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.
[/code]

#15

Je suis perplexe. La résolution se fait mais on ne voit que des adresses IPv6, ce qui n’a de sens que si la machine a une connectivité IPv6. Si elle a aussi une connectivité IPv4, elle devrait essayer de se connecter aux adresses IPv4 des miroirs Debian. Il doit y avoir un défaut de configuration quelque part que je n’arrive pas à cerner. Pourrais-tu fournir le résultat des commandes suivantes qui pourraient m’aider à y voir plus clair :

[code]ip addr # adresses IPv4 et IPv6 de la machine
ip -4 route # table de routage IPv4
ip -6 route # table de routage IPv6

pour vérifier quelles adresses IP le serveur DNS renvoie pour ftp.fr.debian.org

host ftp.fr.debian.org

pour vérifier quelles adresses IP le resolver de la libc renvoie

getent ahosts ftp.fr.debian.org | cut -d ’ ’ -f 1 | uniq

routage de l’adresse IPv4 de ftp.fr.debian.org

ip route get 212.27.32.66

routage de l’adresse IPv6 de ftp.fr.debian.org

ip route get 2a01:e0c:1:1598::2[/code]

#16

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a4:ba:db:14:a7:39 brd ff:ff:ff:ff:ff:ff inet 192.168.34.2/24 brd 192.168.34.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::a6ba:dbff:fe14:a739/64 scope link valid_lft forever preferred_lft forever 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether a4:ba:db:14:a7:3b brd ff:ff:ff:ff:ff:ff

ip -4 route

default via 192.168.34.1 dev eth0 192.168.34.0/24 dev eth0 proto kernel scope link src 192.168.34.2

ip -6 route

host ftp.fr.debian.org

ftp.fr.debian.org is an alias for debian.proxad.net. debian.proxad.net has address 212.27.32.66 debian.proxad.net has IPv6 address 2a01:e0c:1:1598::2

getent ahosts ftp.fr.debian.org | cut -d ’ ’ -f 1 | uniq

212.27.32.66 2a01:e0c:1:1598::2

ip route get 212.27.32.66

212.27.32.66 via 192.168.34.1 dev eth0 src 192.168.34.2 cache

ip route get 2a01:e0c:1:1598::2

unreachable 2a01:e0c:1:1598::2 from :: dev lo table unspec proto kernel src fe80::a6ba:dbff:fe14:a739 metric 4294967295 error -101

#17

C’est une configuration IPv4 classique sans configuration IPv6 globale. Je ne comprends pas les messages d’erreur d’apt-get concernant les adresses IPv6 qu’il ne devrait même pas essayer de contacter. Que donne la commande suivante pour vérifier la connectivité IPv4 effective ?

#18

tcptraceroute 212.27.32.66

traceroute to 212.27.32.66 (212.27.32.66), 30 hops max, 60 byte packets 1 192.168.34.1 (192.168.34.1) 0.197 ms 0.202 ms 0.194 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * *^Z

ci-dessous ma source liste

#deb cdrom:[Debian GNU/Linux 8.1.0 Jessie - Official amd64 NETINST Binary-1 20150606-14:16]/ jessie mai
deb ftp.fr.debian.org/debian/ jessie main
deb-src ftp.fr.debian.org/debian/ jessie main
deb security.debian.org/ jessie/updates main
deb-src security.debian.org/ jessie/updates main

#19

J’ai écrit [mono]tcptraceroute[/mono] pour utiliser le port TCP 80 comme une connexion HTTP, pas [mono]traceroute[/mono] qui utilise des paquets UDP par défaut.

Si le résultat est le même, cela peut expliquer les erreurs : le serveur est injoignable, peut-être parce que l’adresse de passerelle 192.168.34.1 n’est pas la bonne et ne mène pas vers l’extérieur, ou bien parce que la connexion HTTP sortante est filtrée par un pare-feu.

#20

Traceroute marche bien ! :frowning:
La passerelle est la bonne

#21

Lequel marche bien ? traceroute ou tcptraceroute ?

#22

Traceroute marche bien

traceroute 212.27.32.66 traceroute to 212.27.32.66 (212.27.32.66), 30 hops max, 60 byte packets 1 192.168.34.1 (192.168.34.1) 0.204 ms 0.180 ms 0.190 ms 2 192.168.33.1 (192.168.33.1) 0.786 ms 0.787 ms 1.132 ms 3 62-193-36-144.as16211.net (62.193.36.144) 4.132 ms 4.409 ms 3.960 ms 4 62-193-37-65.as16211.net (62.193.37.65) 5.119 ms 5.411 ms 5.651 ms 5 stella-telecom.th2-1.rt.hopus.net (37.77.34.54) 4.592 ms 4.818 ms 4.606 ms 6 193.253.13.205 (193.253.13.205) 5.666 ms 3.916 ms 3.726 ms 7 ae40-0.noidf002.aubervilliers.francetelecom.net (193.252.98.110) 4.325 ms 4.125 ms 4.378 ms 8 * * * 9 ae41-0.nosta102.paris.francetelecom.net (193.251.126.61) 4.760 ms 4.527 ms * 10 * * * 11 * * * 12 * p11-crs16-1-be1001.intf.routers.proxad.net (78.254.249.5) 8.006 ms * 13 * * * 14 * * * 15 debian.proxad.net (212.27.32.66) 4.929 ms 4.933 ms 5.173 ms

Par contre je viens de voir que 192.168.33.1 et 192.168.33.196 sont dans denyhost …
Cependant je viens d’enlever les deux adresses mais cela ne marche toujours pas

#23

Je ne vois pas en quoi ces adresses dans denyhosts nous concernent.

Par contre si le tcptraceroute (TCP/80) ne passe pas alors que le traceroute normal (UDP) passe, les connexions HTTP vers l’extérieur, ou du moins vers le miroir Debian, sont impossibles probablement à cause d’un filtrage par un pare-feu situé sur ou derrière la passerelle, peut-être sur le routeur à l’adresse 192.168.33.1.

Edit : Ne faudrait-il pas passer par un proxy pour les connexions HTTP ?

#24

Bonjour,

Je viens de résoudre le problème par l’ouverture du pare-feu (DMZ) en ouvrant le port ftp.

A+

#25

Etonnant dans la mesure où les dépots dans ton sources.list sont définis en HTTP.