merci au moins j’aurais apris des truc
mais malheureusement ça ne m’a pas servir a grand chose
tcpdump -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
désespérant
edit j’ai fait plusieurs essai j’ai jamais rien eu
Il vaut mieux indiquer à tcpdump l’interface qu’il doit écouter avec l’option -i, sinon il prend la première qu’il trouve et ce n’est pas forcément la bonne.
Tu l’as fait des deux côtés, sur le client et sur le serveur ?
Truc : avant de tenter une connexion, envoyer du trafic dont on sait qu’il passe, par exemple un ping, pour valider le fonctionnement de tcpdump.
Et concernant les règles iptables sur le poste client ? tu n’as toujours par répondu avec certitude.
donc sur le pc client aucune regles d’iptables et pour le faire
un tcpdump du coté serveur je ne peut tous simplement pas puisque je n’ai plus accés a mon serveur
c’est à dire que je peut m’y connecter sans aucun problème mais seulement quand je suis pas chez moi
sinon il veut pas (meme quand j’essaye par mon adresse publique)
pour le tcpdump qui marchais peut etre pas je viens de le tester avec seulement iceweasel d’ouvert (1 onglet gmail + 2 debian-fr)
ben j’ai plein de chose en tres peu de temps
# tcpdump -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:47:41.039133 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.11 tell 192.168.0.254, length 48
23:47:41.039158 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.11 is-at 00:23:54:5c:47:bf (oui Unknown), length 28
23:47:41.040105 IP (tos 0x0, ttl 64, id 28253, offset 0, flags [DF], proto UDP (17), length 71)
192.168.0.11.32894 > dns2.proxad.net.domain: 46706+ PTR? 11.0.168.192.in-addr.arpa. (43)
23:47:41.065172 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 120)
dns2.proxad.net.domain > 192.168.0.11.32894: 46706 NXDomain 0/1/0 (92)
23:47:41.065436 IP (tos 0x0, ttl 64, id 28260, offset 0, flags [DF], proto UDP (17), length 72)
192.168.0.11.50454 > dns2.proxad.net.domain: 11382+ PTR? 254.0.168.192.in-addr.arpa. (44)
23:47:41.090361 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 121)
dns2.proxad.net.domain > 192.168.0.11.50454: 11382 NXDomain 0/1/0 (93)
23:47:41.090653 IP (tos 0x0, ttl 64, id 28266, offset 0, flags [DF], proto UDP (17), length 72)
192.168.0.11.40234 > dns2.proxad.net.domain: 61162+ PTR? 241.40.27.212.in-addr.arpa. (44)
23:47:41.116292 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 101)
dns2.proxad.net.domain > 192.168.0.11.40234: 61162 1/0/0 241.40.27.212.in-addr.arpa. (73)
23:47:41.593288 IP (tos 0x0, ttl 54, id 50675, offset 0, flags [none], proto TCP (6), length 105)
ww-in-f19.google.com.https > 192.168.0.11.52695: Flags [P.], seq 2075896666:2075896719, ack 3603216925, win 682, options [nop,nop,TS val 44591952 ecr 3626058], length 53
23:47:41.593331 IP (tos 0x0, ttl 64, id 65350, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.11.52695 > ww-in-f19.google.com.https: Flags [.], cksum 0x99f3 (correct), ack 53, win 213, options [nop,nop,TS val 3632872 ecr 44591952], length 0
23:47:41.593624 IP (tos 0x0, ttl 64, id 28392, offset 0, flags [DF], proto UDP (17), length 72)
192.168.0.11.57255 > dns2.proxad.net.domain: 46593+ PTR? 19.229.85.209.in-addr.arpa. (44)
23:47:41.621635 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 106)
dns2.proxad.net.domain > 192.168.0.11.57255: 46593 1/0/0 19.229.85.209.in-addr.arpa. (78)
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
pour le fait qu’il ce trompe de carte c’est pas bete mais regarde c’est bien marquer qu’il a prit eth0, comme il faut quoi
On n’a pas dû bien se comprendre. Le seul trafic pertinent est celui généré lorsque tu essaies de te connecter depuis le poste local au serveur local, pas lorsque tu surfes sur un quelconque site sur internet.
[quote]un tcpdump du coté serveur je ne peut tous simplement pas puisque je n’ai plus accés a mon serveur
c’est à dire que je peut m’y connecter sans aucun problème mais seulement quand je suis pas chez moi[/quote]
Tu n’as même pas d’accès direct par la console ? Il n’a ni écran ni clavier ?
il n’a ni écran ni clavier
et en refaisant un tcpdump -n au moment je faisais tout plein de ping vers le dis serveur il ne voyait rien j’ai pourtant fais attention a l’interface utilisé
et j’ai fait comme tu m’as dit ben j’ai rien pu avoir d’autre que des truc du a iceweasel
je sais plus quoi faire
parceque ya pas de regles iptable mais c’est comme si j’envoyer rien sur le réseau puisque je voit rien
et pourtant tout marche bien
demain j’essairais de me connecter a ma freebox hd a partir de mon serveur
Si je comprends bien ce que tu écris, quand tu fais un ping depuis le poste vers le serveur, le serveur répond mais tcpdump ne voit rien passer sur l’interface ethernet, ni requête ni réponse ? Tu es sûr que tu envoies à la bonne adresse IP, c’est-à-dire l’adresse privée du serveur ?
oui parfaitement sur
et oui c’est exactement ça tu as tout compris
Hélas je suis loin d’avoir tout compris, car pour moi ce que tu décris est impossible.
Récapitulons :
Sur le poste client, ping “192.168.0.11” répond, mais “tcpdump -i eth0” ne montre aucun trafic. Pas de règles iptables (iptables-save vide). Tu as tenté un ping depuis le serveur vers le poste client ?
Pourrais-tu indiquer le résultat de ceci sur le poste client quand il n’a pas d’autre activité réseau :
ifconfig
ping -nc 10 192.168.0.10
ifconfig
tiens voila mais je n’ai pas compris pourquoi tu me demande ça parcontre j’ai bien compris que normalement c’est completement impossible
[code]eth0 Link encap:Ethernet HWaddr 00:23:54:5c:47:bf
inet adr:192.168.0.11 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::223:54ff:fe5c:47bf/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1388 errors:0 dropped:0 overruns:0 frame:0
TX packets:1042 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1491755 (1.4 MiB) TX bytes:178478 (174.2 KiB)
Interruption:30
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:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:5072 (4.9 KiB) TX bytes:5072 (4.9 KiB)
wlan0 Link encap:Ethernet HWaddr 00:21:5d:9b:8a:04
inet adr:192.168.0.10 Bcast:192.168.0.255 Masque:255.255.255.0
UP 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)
wmaster0 Link encap:UNSPEC HWaddr 00-21-5D-9B-8A-04-00-00-00-00-00-00-00-00-00-00
UP RUNNING MTU:0 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)
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=64 time=0.022 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=64 time=0.021 ms
64 bytes from 192.168.0.10: icmp_seq=4 ttl=64 time=0.043 ms
64 bytes from 192.168.0.10: icmp_seq=5 ttl=64 time=0.049 ms
64 bytes from 192.168.0.10: icmp_seq=6 ttl=64 time=0.049 ms
64 bytes from 192.168.0.10: icmp_seq=7 ttl=64 time=0.042 ms
64 bytes from 192.168.0.10: icmp_seq=8 ttl=64 time=0.025 ms
64 bytes from 192.168.0.10: icmp_seq=9 ttl=64 time=0.023 ms
64 bytes from 192.168.0.10: icmp_seq=10 ttl=64 time=0.044 ms
— 192.168.0.10 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.021/0.036/0.049/0.012 ms
eth0 Link encap:Ethernet HWaddr 00:23:54:5c:47:bf
inet adr:192.168.0.11 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::223:54ff:fe5c:47bf/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1394 errors:0 dropped:0 overruns:0 frame:0
TX packets:1049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1492617 (1.4 MiB) TX bytes:180603 (176.3 KiB)
Interruption:30
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:76 errors:0 dropped:0 overruns:0 frame:0
TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:6752 (6.5 KiB) TX bytes:6752 (6.5 KiB)
wlan0 Link encap:Ethernet HWaddr 00:21:5d:9b:8a:04
inet adr:192.168.0.10 Bcast:192.168.0.255 Masque:255.255.255.0
UP 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)
wmaster0 Link encap:UNSPEC HWaddr 00-21-5D-9B-8A-04-00-00-00-00-00-00-00-00-00-00
UP RUNNING MTU:0 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)
[/code]
merci de t’interesser a mon probleme parceque sans toi je sais pas ce que je pourrais faire
ne t’inquiete pas si je ne reponds pas ce WE
je ne serais pas chez moi
Et voilà je le savais, j’en étais sûr… mais je n’osais pas te le demander directement tellement c’était con. 
Le but, c’était de voir quelle était l’interface dont les compteurs s’incrémentaient, parce que les paquets de ping, il passent forcément quelque part. La réponse est lo, l’interface interne de loopback. La raison, c’est que l’adresse du serveur 192.168.0.10 est configurée sur une autre interface locale, wlan0, et du coup la machine pense à juste titre que 192.168.0.10 c’est elle-même.
Mais bon sang de bois, pourquoi diable l’interface wifi a-t-elle la même adresse que le serveur ? Désactive-la, déconfigure ou modifie son adresse IP et tout devrait rentrer dans l’ordre.
merci tu as trouvé le problème mais je n’arrive pas a le résoudre
j’ai fait un ifdown --force -v wlan0
maintenant mon ifconfig ne m’affiche bien que le eth0 et lo
mais je ne peut toujours pas me connecter
et quand je ping c’est toujours le lo qui s’incremente bizarre
j’a desactiver le eth0 et le lo
j’ai reactiver le eth0 avec dhclient eth0
et tenter un ping, cela ne marche pas je reactive le lo et la ça marche mais juste le ping parcequ’il va en local
c’est quand meme super bizarre
Il faut supprimer ou modifier l’adresse sur wlan0. Par exemple
ifconfig wlan0 0.0.0.0merci c’est bon ça marche
c’est toi le meilleur
est ce que tu serais m’expliquer ce qu’il c’est pass ? enfin j’ai compris le probleme mais je ne comprends pas pourquoi il est arrivé
Je ne sais pas. wlan0 a été configurée avec cette adresse d’une façon ou d’une autre. Comment est-elle configurée, il y a quelque chose dans /etc/network/interfaces, network-manager ou autre ?
nan je n’ai rien nul part ce qui est le plus bizarre c’est que mes adresse ip sont fixer dans le dhcp donc réservé
peut être que cela vient d’un vieux test ou je ne sais quoi
je ne me sert que tres rarement de mon wifi
enfin bon c’est pas grave le principal c’est que cela remarche
le truc bizarre aussi c’est que j’ai plusieur fois etait obligé de remettre l’adresse ip de wlan0 a 0
quand j’ai redemarré
Par quoi l’interface wifi wlan0 est-elle gérée ? Est-elle définie dans /etc/network/interfaces ?
D’après la sortie d’ifconfig, wlan0 est activée (flag UP) mais pas connectée (pas de flag RUNNING, aucun paquet émis ou reçu). Donc quelque chose l’a activée mais elle ne peut pas avoir reçu cette adresse par DHCP puisque non connectée. Peut-être une ancienne adresse obtenue par DHCP qui serait restée dans un fichier de bail ?
je ne sais pas et le mystère restera entier puisque j’ai réinstallé ma machine client (pas le serveur) hier j’avais d’autre problème j’en avais marre je suis repassé en stable
par contre je sais que j’avais un network manager a l’origine (wicd) et que il ne marchait plus
je devais faire dhclient eth0 pour pouvoir me connecter au debut a chaque fois
donc oui c’est possible qu’il est gardé ça dans un coin mais ça fait au moins 3 ou 4 mois que je n’ai pas utlisé le wifi donc c’est bizarre quand meme
enfin bon merci quand meme parceque non seulement tu ma résolu mon problème mais en plus et surtout je sais comment tu as fait pour trouver et je sais que si le probleme revient je serais le trouver et le resoudre