Vous n'êtes pas identifié(e).
Association libriste infothema située dans les Côtes d'Armor (Bretagne)
Blog : https://www.infothema.fr / Forum : https://www.infothema.fr/forum
Twitter : https://twitter.com/asso_infothema / Compte Mastodon : https://framapiaf.org/@infothema / PeerTube : https://infothema.net
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dernière modification par raleur (11-12-2019 21:26:55)
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
L'intérêt est de montrer que seuls sont transmis des paquets sur les adresses en ipv6 du domaine. Pour les adresses ipv4 aucune trace.
Parce que l'IPv6 est utilisé en priorité lorsqu'il est disponible, donc pas besoin d'utiliser l'IPv4.
Le début des résultats n'a pas été tronqué
Si. Une connexion TCP ne peut pas s'établir sans paquets SYN et SYN,ACK qui manquent dans ta capture. Je ne dis pas que tu as volontairement tronqué la capture, je dis que les connexions étaient déjà établies au moment où tu as lancé tcpdump, donc trop tard.
Il vaut mieux montrer que raconter.
Hors ligne
Parce que l'IPv6 est utilisé en priorité lorsqu'il est disponible, donc pas besoin d'utiliser l'IPv4.
Dans un premier temps seules les adresses ipv6 avaient été utilisées, et la seconde fois seules les ipv4. Les premiers résultats étaient semblables à ceux que j'ai posté, alors qu'en ipv4 tcpdump n'a rien renvoyé. Pour cette raison on a passé la commande avec les 4 adresses et donc le retour est le même qu'avec seulement les ipv6.
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
et pour l'ipv4 seul
Comme je l'ai écrit on va repasser ces commandes et poster les 2 retours.
Les voilà:
Dernière modification par phlinux (12-12-2019 13:18:49)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
ou
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dernière modification par raleur (13-12-2019 10:41:14)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par phlinux (12-12-2019 20:26:02)
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dernière modification par raleur (13-12-2019 10:51:11)
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dernière modification par raleur (13-12-2019 14:01:16)
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
La forme exacte est : 91-171-12-254.subs
Non, ça c'est le début du reverse DNS complet qui est 91-171-12-254.subs.proxad.net. Je t'avais dit d'utiliser l'option -n pour éviter la résolution inverse des adresses. L'adresse IP correspondante, 91.171.12.254, se termine par 254 donc elle correspond bien à la forme d'une adresse de passerelle de Freebox en mode bridge.
Dans la plage correspondant a cette adresse une ip fixe a été attribuée à la machine : 91.171.12.37
Attribuée comment ? Par DHCP ou par configuration statique ?
Comment cette adresse de passerelle, ou celle de l'ordi, peuvent-elle se connecter à l'adresse de la freebox qui, après vérification, est toujours 192.168.0.254 ?
Quelle vérification ?
Si la freebox a pour adresse 192.168.0.254, alors elle est en mode routeur et la configuration ci-dessus est incorrecte.
Il vaut mieux montrer que raconter.
Hors ligne