web-dev-qa-db-fra.com

La connexion a expiré; aucun serveur n'a pu être atteint erreur

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
4
QPTR

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:

  1. 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
  1. 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.

8
khe