En essayant de faire un ping sur www.google.com, je rencontrais l'erreur:
;; la connexion a expiré; aucun serveur n'a pu être atteint
Je n'ai pu ni exécuter Sudo apt-get update ni accéder à des pages Web. J'ai donc modifié mon fichier /etc/resolv.conf de manière à ce qu'il contienne des serveurs OpenDNS.
~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# OpenDNS IPv4 nameservers
nameserver 208.67.222.222
nameserver 208.67.220.220
Cependant, je reçois toujours la même erreur:
~ $ Host -v www.google.com Essayez "www.google.com" ;; la connexion a expiré; aucun serveur n'a pu être atteint
J'ai aussi essayé avec Dig, et les résultats sont les suivants:
: ~ $ Dig @ 8.8.8.8 www.google.com
; << >> Dig 9.9.5-3ubuntu0.4-Ubuntu << >> @ 8.8.8.8 www.google.com; (1 serveur trouvé) ;; options globales: + cmd ;; la connexion a expiré; aucun serveur n'a pu être atteint
Quelqu'un pourrait-il m'aider s'il vous plaît à résoudre le problème? J'utilise Ubuntu 14.04 sur VirtualBox.
MODIFIER:
la sortie de ifconfig:
eth0 Link encap:Ethernet HWaddr 08:00:27:6a:81:38
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe6a:8138/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8368 errors:0 dropped:0 overruns:0 frame:0
TX packets:5197 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7814822 (7.8 MB) TX bytes:467136 (467.1 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:409 errors:0 dropped:0 overruns:0 frame:0
TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:42236 (42.2 KB) TX bytes:42236 (42.2 KB)
sortie de route ip:
~$ ip route default via 10.0.2.2 dev eth0 proto static
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 1
Dès que j'ai eu la même situation et le redémarrage n'a pas résolu le problème, voici mes étapes simples qui pourraient aider à trouver le problème:
vérifier la connexion internet
ping 8.8.8.8
Si la destination est inaccessible, vérifiez si votre passerelle 10.0.2.2 est accessible. Et corrige le problème.
si la connexion est bonne, vous verrez quelque chose comme:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=4.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=4.13 ms
Vérifiez si l'hôte/Dig envoie les paquets correctement:
Sudo tcpdump -n -i eth0 | grep 8.8.8.8.53
En même temps depuis une autre console de la même machine
Dig @8.8.8.8 www.google.com
Vous obtiendrez une réponse semblable à:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:34:00.980550 IP 10.0.2.15.56570 > 8.8.8.8.53: 47059+ A? google.com. (27)
13:34:05.980541 IP 10.0.2.15.56570 > 8.8.8.8.53: 47059+ A? google.com. (27)
Cela signifie que la demande avait été transmise au réseau externe mais ne revenait pas ...
Vous pouvez vérifier ce que fait votre pare-feu en analysant la sortie de vos règles de pare-feu:
iptables -n -L
Le problème peut provenir d’un pare-feu entre vous et 208.67.222.222, 208.67.220.220 ou 8.8.8.8.
dans mon cas, le pare-feu du fournisseur bloque de manière concomitante les paquets UDP entrants à partir du port 53.
et donc la correction des règles de pare-feu des fournisseurs corrige le problème.
J'espère que cette analyse sera utile à quelqu'un.