Poste Windows accès Internet : OK pas linux

Poste Windows accès Internet : OK pas linux - Réseaux - Systèmes & Réseaux Pro

Marsh Posté le 05-07-2012 à 19:04:38    

Bonjour,
 
   Les postes windows de mon réseau (Windows XP, Windows 7, Windows 2008) ont accès à Internet. Les postes Linux (Ubuntu, CentOS et RedHat n'ont plus accès a internet). Il y a une semaine tous les postes windows et linux avaient accès à internet sans problème. La configuration des postes linux n'a pas été modifié entre temps. Le FAI est orange.
 
Test effectué sur les poste Linux :
 
[root@SV-R1NET-APP003 ~]# ping www.google.fr
ping: unknown host www.google.fr
[root@SV-R1NET-APP003 ~]# ping 173.194.66.94   (adresse IP d'un serveur de google)
PING 173.194.66.94 (173.194.66.94) 56(84) bytes of data.
^C
--- 173.194.66.94 ping statistics ---
126 packets transmitted, 0 received, 100% packet loss, time 125483ms
 
[root@SV-R1NET-APP003 ~]# traceroute www.google.fr
www.google.fr: Nom ou service inconnu
Cannot handle "host" cmdline arg `www.google.fr' on position 1 (argc 1)
[root@SV-R1NET-APP003 ~]# di
diff       diff-jars  dir        dirname    disown
diff3      dig        dircolors  dirs
[root@SV-R1NET-APP003 ~]# dig www.google.fr
 
; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6 <<>> www.google.fr
;; global options: +cmd
;; connection timed out; no servers could be reached

 
Pourtant tous ces postes arrivent bien à joindre le routeur cisco qui permet d'accéder à internet :
 
[root@SV-R1NET-APP003 ~]# ping 10.197.19.2
PING 10.197.19.2 (10.197.19.2) 56(84) bytes of data.
64 bytes from 10.197.19.2: icmp_seq=1 ttl=255 time=0.458 ms
64 bytes from 10.197.19.2: icmp_seq=2 ttl=255 time=0.435 ms
 
 
Les même tests sur Windows  
 
 
C:\Users\>ping www.google.fr
 
Envoi d'une requête 'ping' sur www-cctld.l.google.com [173.194.78.94] avec 32 oc
tets de données :
Réponse de 173.194.78.94 : octets=32 temps=57 ms TTL=44
Réponse de 173.194.78.94 : octets=32 temps=56 ms TTL=44
Réponse de 173.194.78.94 : octets=32 temps=56 ms TTL=44
Réponse de 173.194.78.94 : octets=32 temps=57 ms TTL=44
 
Statistiques Ping pour 173.194.78.94:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 56ms, Maximum = 57ms, Moyenne = 56ms
 
 
 
Je ne comprends pas la raisons du problèmes. Quelqu'un a-t-il une idée pour m'aider ?
 
Merci d'avanace.
 
 

Reply

Marsh Posté le 05-07-2012 à 19:04:38   

Reply

Marsh Posté le 05-07-2012 à 20:08:09    

compare les ipconfig/ifconfig

Reply

Marsh Posté le 05-07-2012 à 20:13:23    

1) as-tu bien vérifié la configuration DNS de tes postes linux ?

 

2) que donne:  le résultat de la commande  "route" sur un poste problématique ?

Message cité 1 fois
Message édité par vrobaina le 05-07-2012 à 20:13:30

---------------
Les cons, ça ose tout, et c'est même à ça qu'on les reconnait....
Reply

Marsh Posté le 06-07-2012 à 07:48:02    

vrobaina a écrit :

1) as-tu bien vérifié la configuration DNS de tes postes linux ?  
 
2) que donne:  le résultat de la commande  "route" sur un poste problématique ?


 
+1 pour les dns , s'il n'arrive pas à traduire le nom www.google.fr en adresse ip c'est un problème de résolution de nom
si sur ton linux tu fais un ping 173.194.67.94 ? cela donne quoi, si le ping passe c'est que le routage fonctionne bien

Reply

Marsh Posté le 06-07-2012 à 09:05:35    

il l'a fait, c'est le 2ème test

Reply

Marsh Posté le 06-07-2012 à 09:54:55    

Supers les tests mais effectivement y'a pas les passerelles.

Reply

Marsh Posté le 06-07-2012 à 09:59:01    

Ouai j'ai fais le test du ping de l'adresse IP de google depuis un linux et cela ne fonctionne pas alors que sur windows oui.
 
Les ipconfig et ifconfig sont identique (sauf adresse IP bien sur) je l'ai ai configurer même à la main en dur pour être sur et cela ne fonctionne pas.  
 
D'autre idée ?

Reply

Marsh Posté le 06-07-2012 à 10:07:39    

affiche les routes, et les règles de ton iptables.
Les machines sont sur le même sous réseau ?

Reply

Marsh Posté le 06-07-2012 à 10:13:53    

Pas de changement sur les switchs ? VLAN ?


---------------
In my bed, but still_at_work.
Reply

Marsh Posté le 06-07-2012 à 10:28:50    

Pour Still at home : Non je n'ai qu'un Vlan et j'arrive a pinguer le routeur aussi bien depuis les postes linux et depuis les postes windows
 
Pour Je@nb :  
 
table de routage d'un linux :  
[root@SV-R1NET-APP003 ~]# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
10.197.19.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         10.197.19.2     0.0.0.0         UG    0      0        0 eth0
 
 
table de routage windows  
IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0      10.197.19.2    10.197.19.107     10
      10.197.19.0    255.255.255.0         On-link     10.197.19.107    266
      10.197.19.0  255.255.255.255         On-link     10.197.19.107     11
      10.197.19.0  255.255.255.255      10.199.2.96    10.197.19.107     11
    10.197.19.107  255.255.255.255         On-link     10.197.19.107    266
    10.197.19.255  255.255.255.255         On-link     10.197.19.107    266
.

Le reste des routes sont des routes vers d'autres d'autres réseaux sans importance

Reply

Marsh Posté le 06-07-2012 à 10:28:50   

Reply

Marsh Posté le 06-07-2012 à 10:30:42    

Toutes les machines sont sur le même réseau. Tout fonctionnait bien la semaine dernière je n'ai rien changer et depuis le début de la semaine cela ne fonctionne plus et je n'ai rien modifié


Message édité par molbento le 06-07-2012 à 10:31:00
Reply

Marsh Posté le 06-07-2012 à 10:33:18    

Je ne pense pas que le problème vienne du serveur DNS car depuis linux je n'arrive pas a pinguer l'adresser IP du serveur de google alors que sous windows

Reply

Marsh Posté le 06-07-2012 à 11:21:58    

Ta métrique n'est pas la même sur les deux postes pour 0.0.0.0
 
Faut-il y voir un rapport ?


---------------
In my bed, but still_at_work.
Reply

Marsh Posté le 06-07-2012 à 11:38:10    

Non la matérique ne change rien, cela fonctionnait comme cela avant. Je peux quand même essayé.
 
J'ai modifier la métrique linux mais cela n'a rien changé.

Reply

Marsh Posté le 06-07-2012 à 13:09:39    

C'est bizarre ta 2ème entrée dans ta route linux. Ca ressemble à l'APIPA.
 
Tu veux pas faire un ifconfig -a et un iptables -L -v ?

Reply

Marsh Posté le 06-07-2012 à 13:34:45    

[root@SV-R1NET-APP003 ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr **:**:**:**:**:**
          inet adr:10.197.19.44  Bcast:10.197.19.255  Masque:255.255.255.0
          adr inet6: fe80::218:feff:fe77:b35c/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:56315 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:7092321 (6.7 MiB)  TX bytes:143182 (139.8 KiB)
          Interruption:16 Mémoire:f8000000-f8012800
 
eth1      Link encap:Ethernet  HWaddr **:**:**:**:**:**
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:17 Mémoire:fa000000-fa012800
 
eth2      Link encap:Ethernet  HWaddr 00:1B:78:56:5A:F6
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:17 Mémoire:fdfe0000-fe000000
 
eth3      Link encap:Ethernet  HWaddr 00:1B:78:56:5A:F7
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:18 Mémoire:fdfa0000-fdfc0000
 
lo        Link encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:356 (356.0 b)  TX bytes:356 (356.0 b)
 
 
root@SV-R1NET-APP003 ~]# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  879 73096 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
    1    60 ACCEPT     icmp --  any    any     anywhere             anywhere
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    4   208 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
26711 4615K REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
 
Chain OUTPUT (policy ACCEPT 1007 packets, 124K bytes)
 pkts bytes target     prot opt in     out     source               destination
 

Reply

Marsh Posté le 09-07-2012 à 08:55:01    

salut au niveau de la passerelle tu utilises quoi ?
j'ai eu le cas chez un  client qui n'arrivait plus à surfer via du Checkpoint.
 
Checkpoint tu l'achete en fonction du nombre d'ip local connecté, donc si quelqu'un via avec son laptop et que tu es juste aux niveau des licences, tu as ce genre de problème.
 
Ta conf à l'air correct.

Reply

Marsh Posté le 09-07-2012 à 13:35:05    

Non j'utilise pas de logiciel comme checkpoint pas de problème de licence

Reply

Marsh Posté le 11-07-2012 à 09:54:38    

personne n'a d'autre idée le problème existe toujours ??

Reply

Marsh Posté le 11-07-2012 à 10:23:12    


je ne connais ip table mais il me semble qu'il n'y a que des paquets rejetés (dernière ligne de tes stats). As-tu essayé en désactivant ip tables? (ou en ouvrant tout?)

Reply

Marsh Posté le 11-07-2012 à 11:11:27    

En effet IPTABLE était activé. Je l'ai désactiver mais cela ne fonctionne pas d'avantage.  
 
# /etc/init.d/iptables status
Le pare-feu est arrêté
# ping google.fr
ping: unknown host google.fr

Reply

Marsh Posté le 11-07-2012 à 11:53:48    

Essai avec une IP : 8.8.8.8


---------------
In my bed, but still_at_work.
Reply

Marsh Posté le 11-07-2012 à 14:21:21    

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
539 packets transmitted, 0 received, 100% packet loss, time 538406ms

Reply

Marsh Posté le 11-07-2012 à 14:46:45    


Et un traceroute vers 8.8.8.8 ?

Reply

Marsh Posté le 11-07-2012 à 14:48:28    

Fais un tracert vers 8.8.8.8 sur ta machine Windows et sur ta machine Linux.


---------------
In my bed, but still_at_work.
Reply

Marsh Posté le 11-07-2012 à 15:23:03    

Résultat Windows :  
 
C:\Users\>tracert 8.8.8.8
 
Détermination de l'itinéraire vers google-public-dns-a.google.com [8.8.8.8]
avec un maximum de 30 sauts :
 
  1    <1 ms    <1 ms    <1 ms  10.197.19.2
  2    46 ms    37 ms    41 ms  80.10.245.214
  3    36 ms    36 ms    36 ms  10.123.122.78
  4    85 ms    37 ms    38 ms  xe-2-3-0-0.ncdij202.dijon.francetelecom.net [193.253.91.230]
  5    67 ms    44 ms    43 ms  ae42-0.nistr102.strasbourg.francetelecom.net [193.252.160.118]
  6    53 ms    56 ms    54 ms  193.252.103.122
  7    53 ms    69 ms    55 ms  google-9.gw.opentransit.net [193.251.254.18]
  8    54 ms    56 ms    52 ms  72.14.238.234
  9    57 ms    54 ms    97 ms  72.14.235.171
 10    60 ms    57 ms    59 ms  209.85.253.20
 11    60 ms    58 ms    99 ms  209.85.252.83
 12     *        *        *     Délai d'attente de la demande dépassé.
 13    57 ms    57 ms    57 ms  google-public-dns-a.google.com [8.8.8.8]
 
Itinéraire déterminé.
 
 
 
 
 
 
 
résultat linux  :  
 
# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
 
Pourtant j'arrive bien à joindre ma passerelle 10.197.19.2 depuis un poste linux :  
 
# ping 10.197.19.102
PING 10.197.19.102 (10.197.19.102) 56(84) bytes of data.
64 bytes from 10.197.19.102: icmp_seq=1 ttl=128 time=0.964 ms
64 bytes from 10.197.19.102: icmp_seq=2 ttl=128 time=0.207 ms
64 bytes from 10.197.19.102: icmp_seq=3 ttl=128 time=0.218 ms
 
 

Reply

Marsh Posté le 11-07-2012 à 16:47:27    

Tu devrais au moins avoir le routeur dans le traceroute...


---------------
In my bed, but still_at_work.
Reply

Marsh Posté le 11-07-2012 à 17:12:54    

je suis d'accord !!
 
quand je ping le routeur il me répond et quand je fais un traceroute vers lui tout j'ai ceci comme réponse :  
 
 
# ping 10.197.19.2
PING 10.197.19.2 (10.197.19.2) 56(84) bytes of data.
64 bytes from 10.197.19.2: icmp_seq=1 ttl=255 time=0.508 ms
64 bytes from 10.197.19.2: icmp_seq=2 ttl=255 time=0.478 ms
64 bytes from 10.197.19.2: icmp_seq=3 ttl=255 time=0.467 ms
 
--- 10.197.19.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.467/0.484/0.508/0.024 ms
# traceroute 10.197.19.2
traceroute to 10.197.19.2 (10.197.19.2), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Reply

Marsh Posté le 11-07-2012 à 18:09:48    

Salut,
 
On ne s’intéresse qu'aux postes mais au niveau de la passerelle, c'est quoi comme type ?
Tu n'as pas une autre passerelle possible vers Internet pour tester ?

Reply

Marsh Posté le 11-07-2012 à 20:11:54    

fait un arp -a ?

Reply

Marsh Posté le 11-07-2012 à 20:51:12    


et rien n'a changé au niveau du routeur? (ACLs, etc ..)?

Reply

Marsh Posté le 12-07-2012 à 09:38:12    

Je@nb :  
 
La commanda arp -a donne :  
 
#arp -a
bewan (10.197.19.2) at 00:50:7f:8a:e7:18 [ether] on eth0
 
Or la passerelle 10.197.19.2 n'est pas un bewan et l'adresse mac n'est pas la bonne. Comme réinitialiser ce paramatère ?

Reply

Marsh Posté le 12-07-2012 à 10:07:36    

Ouais donc tu as un pb là je pense. Soit l'entrée a été mis statiquement et c'est une erreur soit ya un équipement sur ton réseau qui répond et pour une raison inconnue sur les linux c'est lui qui est prioritaire :D.
 
Fait la même commande sur windows pour comparer.
 
Pour flusher, j'ai pas en tête mais essaie un arp -d 10.197.19.2 ou un ip neighbor delete 10.197.19.2
 
Relance après la commande arp -a pour voir ce qui reremonte (après un ping par exemple)

Reply

Marsh Posté le 12-07-2012 à 10:22:14    

Ok ca résoud mon problème. Maintenant quel équipement envoie ces informations arp a mes équipements linux le serveur DHCP ?

Reply

Marsh Posté le 12-07-2012 à 10:39:32    

Non, l'équipement lui même surement.

Reply

Marsh Posté le 12-07-2012 à 10:44:31    

et pourquoi il récupère cette adresse MAC qui est celle d'un ancien équipement. Pourtant il y a deux semaine tout fonctionnait correctement et j'ai pas redémarrer tout mes serveurs en mm temps. Je trouve cela bizarre mais bon vu que tu m'as trouvé la solution c'est cool merci

Reply

Marsh Posté le 12-07-2012 à 11:56:19    

Ton ancien équipement est online encore ?
 
Peut être tu as une entrée arp statique sur tes postes linux (j'en sais rien)

Reply

Marsh Posté le 12-07-2012 à 12:52:26    

non l'ancien équipement n'est pas actif. Et toutes les table arp sont en dynamique. C'est pas grave merci pour la solution encore.

Reply

Marsh Posté le 13-07-2012 à 23:17:54    

Salut  
J'ai eu ce problème sur une debian propre
Résolu en désactivant l'ipv6...

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed