Il y a 20 ans, quand on a commencé à parler d'ipv6, certains
n'hésitaient pas à affirmer que le système actuel était à bout de
souffle et qu'il était urgent tout passer en v6. 10 ans après, je me
suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais
ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent
d'attendre, la généralisation des routeurs NAT avait reculé le problème.
J'ai refermé l'oeil et attendu encore 10 ans de plus...
Et je tombe sur un article de 2010 partant en guerre contre les gens qui
ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui
revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains
fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas
"sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4
allait être attribuée en 2011, et que le basculement était donc pour
l'année 2011, il n'y avait pas d’échappatoire...
Bref, je considère qu'il est tout de même temps qu'au moins à titre
personnel je m'y intéresse, même si je ne suis pas sûr de voir cette
transition majeure de mon vivant.
Je commence donc prudemment par faire quelques tests sur mon réseau
local (même si pour le fun j'ai activé l'ipv6 de ma box, histoire de
voir si les serveurs de test-v6 considéraient que j'étais bon pour le
service).
J'ai un poste de travail en linux, avec une adresse:
fe80::aee0:10ff:fed0:7e6/64
Un serveur WEB de test sur le même réseau privé: fe80::a00:27ff:fe98:c7a1/64
(bizarre, j'ai lu quelque part que les adresses commençant par fe
n'étaient pas routables, mais comme pour l'instant je ne passe pas par
un routeur, cela ne devrait pas être un problème)
Et là mes ennuis commencent car je ne parviens pas à faire une requête
http depuis ma station vers mon serveur.
Les outils v4 et v6 sont différents et il est possible que je ne
respecte pas correctement les nouvelles syntaxes. Je tente successivement:
en fait il faut indiquer la carte réseau, pourquoi pas:
ping6 -I wlan0 fe80::a00:27ff:fe98:c7a1
64 bytes from fe80::a00:27ff:fe98:c7a1: icmp_seq=1 ttl=64 time=0.234 ms
=> donc la connectivité semble OK
Alors je me lance:
telnet -6 fe80::a00:27ff:fe98:c7a1 80
lnet: Unable to connect to remote host: Invalid argument
Pourtant ce n'est pas un problème "d'argument" puisque sur le serveur
lui-même, avec son adresse de loopback ça fonctionne:
telnet -6 ip6-localhost 80
Trying ::1...
Connected to ::1.
Escape character is '^]'.
D'ailleurs en utilisant wget, depuis ma station vers le serveur puis sur
le serveur lui-même c'est le même genre de problème:
Depuis la station:
wget fe80::a00:27ff:fe98:c7a1
--2016-10-24 17:47:54-- ftp://fe80/:a00:27ff:fe98:c7a1
=> «:a00:27ff:fe98:c7a1»
Résolution de fe80 (fe80)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «fe80»
sur le serveur lui-même ça fonctionne:
wget ip6-localhost
--2016-10-24 17:49:55-- http://ip6-localhost/
Résolution de ip6-localhost (ip6-localhost)… ::1
Connexion à ip6-localhost (ip6-localhost)|::1|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 177 [text/html]
Sauvegarde en : « index.html »
2016-10-24 17:49:55 (38,5 MB/s) — « index.html » sauvegardé [177/177]
Ce n'est donc pas un problème apache, puisqu'il peut se répondre à
lui-même. Il semble que ce soit la "pile" ipv6 qui pose problème (il n'y
a que le ping qui fonctionne). Je précise que tout firewall est
désactivé des deux côtés (règles iptables par défaut).
Le Mon, 24 Oct 2016 17:59:42 +0200, denis.paris écrivait :
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains n'hésitaient pas à affirmer que le système actuel était à bout de souffle et qu'il était urgent tout passer en v6. 10 ans après, je me suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent d'attendre, la généralisation des routeurs NAT avait reculé le problème. J'ai refermé l'oeil et attendu encore 10 ans de plus... Et je tombe sur un article de 2010 partant en guerre contre les gens qui ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas "sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4 allait être attribuée en 2011, et que le basculement était donc pour l'année 2011, il n'y avait pas d’échappatoire... Bref, je considère qu'il est tout de même temps qu'au moins à titre personnel je m'y intéresse, même si je ne suis pas sûr de voir cette transition majeure de mon vivant. Je commence donc prudemment par faire quelques tests sur mon réseau local (même si pour le fun j'ai activé l'ipv6 de ma box, histoire de voir si les serveurs de test-v6 considéraient que j'étais bon pour le service). J'ai un poste de travail en linux, avec une adresse: fe80::aee0:10ff:fed0:7e6/64 Un serveur WEB de test sur le même réseau privé: fe80::a00:27ff:fe98:c7a1/64 (bizarre, j'ai lu quelque part que les adresses commençant par fe n'étaient pas routables, mais comme pour l'instant je ne passe pas par un routeur, cela ne devrait pas être un problème) Et là mes ennuis commencent car je ne parviens pas à faire une requête http depuis ma station vers mon serveur. Les outils v4 et v6 sont différents et il est possible que je ne respecte pas correctement les nouvelles syntaxes. Je tente successivement: ping6 fe80::a00:27ff:fe98:c7a1 Invalid argument (ça commence bien)
Essaie avec une adresse IPv6 publique. Normalement, ça fonctionne : Root rayleigh:[~] > ping6 2001:7a8:a8ed:10::128 PING 2001:7a8:a8ed:10::128(2001:7a8:a8ed:10::128) 56 data bytes 64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=1 ttld timeC.3 ms 64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=2 ttld timeB.7 ms Je viens de tester, même avec une adresse link-local, ça fonctionne encore : Root rayleigh:[~] > ping6 fe80::208:2ff:feaf:da71 PING fe80::208:2ff:feaf:da71(fe80::208:2ff:feaf:da71) 56 data bytes 64 bytes from fe80::208:2ff:feaf:da71%eth2: icmp_seq=1 ttld time=0.073 ms
en fait il faut indiquer la carte réseau, pourquoi pas: ping6 -I wlan0 fe80::a00:27ff:fe98:c7a1 64 bytes from fe80::a00:27ff:fe98:c7a1: icmp_seq=1 ttld time=0.234 ms => donc la connectivité semble OK Alors je me lance: telnet -6 fe80::a00:27ff:fe98:c7a1 80 lnet: Unable to connect to remote host: Invalid argument Pourtant ce n'est pas un problème "d'argument" puisque sur le serveur lui-même, avec son adresse de loopback ça fonctionne: telnet -6 ip6-localhost 80 Trying ::1... Connected to ::1. Escape character is '^]'. D'ailleurs en utilisant wget, depuis ma station vers le serveur puis sur le serveur lui-même c'est le même genre de problème: Depuis la station: wget fe80::a00:27ff:fe98:c7a1 --2016-10-24 17:47:54-- ftp://fe80/:a00:27ff:fe98:c7a1 => «:a00:27ff:fe98:c7a1» Résolution de fe80 (fe80)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «fe80»
Ça, c'est plutôt normal. En IPv4, le ':' sépare l'adresse IP ou le nom du port utilisé. Tu devrais essayer avec wget -6 (pas testé) pour voir s'il interprète les adresses IPv6 correctement. Là, il doit être par défaut en IPv4 et le fait d'avoir autre chose que des chiffres le perturbe. Certains utilitaires utilisent une notation d'IPv6 entre crochets.
sur le serveur lui-même ça fonctionne: wget ip6-localhost --2016-10-24 17:49:55-- http://ip6-localhost/ Résolution de ip6-localhost (ip6-localhost)… ::1 Connexion à ip6-localhost (ip6-localhost)|::1|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Sauvegarde en : « index.html » 2016-10-24 17:49:55 (38,5 MB/s) — « index.html » sauvegardé [177/177] Ce n'est donc pas un problème apache, puisqu'il peut se répondre à lui-même. Il semble que ce soit la "pile" ipv6 qui pose problème (il n'y a que le ping qui fonctionne). Je précise que tout firewall est désactivé des deux côtés (règles iptables par défaut). Qu'est-ce que j'ai loupé?
D'un côté, tu as une adresse résolue en IPv6. De l'autre tu indiques brutalement d'adresse IPv6. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Mon, 24 Oct 2016 17:59:42 +0200,
denis.paris <denis.paris@free.fr> écrivait :
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains
n'hésitaient pas à affirmer que le système actuel était à bout de
souffle et qu'il était urgent tout passer en v6. 10 ans après, je me
suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais
ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent
d'attendre, la généralisation des routeurs NAT avait reculé le problème.
J'ai refermé l'oeil et attendu encore 10 ans de plus...
Et je tombe sur un article de 2010 partant en guerre contre les gens qui
ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui
revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains
fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas
"sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4
allait être attribuée en 2011, et que le basculement était donc pour
l'année 2011, il n'y avait pas d’échappatoire...
Bref, je considère qu'il est tout de même temps qu'au moins à titre
personnel je m'y intéresse, même si je ne suis pas sûr de voir cette
transition majeure de mon vivant.
Je commence donc prudemment par faire quelques tests sur mon réseau
local (même si pour le fun j'ai activé l'ipv6 de ma box, histoire de
voir si les serveurs de test-v6 considéraient que j'étais bon pour le
service).
J'ai un poste de travail en linux, avec une adresse:
fe80::aee0:10ff:fed0:7e6/64
Un serveur WEB de test sur le même réseau privé: fe80::a00:27ff:fe98:c7a1/64
(bizarre, j'ai lu quelque part que les adresses commençant par fe
n'étaient pas routables, mais comme pour l'instant je ne passe pas par
un routeur, cela ne devrait pas être un problème)
Et là mes ennuis commencent car je ne parviens pas à faire une requête
http depuis ma station vers mon serveur.
Les outils v4 et v6 sont différents et il est possible que je ne
respecte pas correctement les nouvelles syntaxes. Je tente successivement:
Essaie avec une adresse IPv6 publique. Normalement, ça fonctionne :
Root rayleigh:[~] > ping6 2001:7a8:a8ed:10::128
PING 2001:7a8:a8ed:10::128(2001:7a8:a8ed:10::128) 56 data bytes
64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=1 ttld timeC.3 ms
64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=2 ttld timeB.7 ms
Je viens de tester, même avec une adresse link-local, ça fonctionne
encore :
Root rayleigh:[~] > ping6 fe80::208:2ff:feaf:da71
PING fe80::208:2ff:feaf:da71(fe80::208:2ff:feaf:da71) 56 data bytes
64 bytes from fe80::208:2ff:feaf:da71%eth2: icmp_seq=1 ttld time=0.073 ms
en fait il faut indiquer la carte réseau, pourquoi pas:
ping6 -I wlan0 fe80::a00:27ff:fe98:c7a1
64 bytes from fe80::a00:27ff:fe98:c7a1: icmp_seq=1 ttld time=0.234 ms
=> donc la connectivité semble OK
Alors je me lance:
telnet -6 fe80::a00:27ff:fe98:c7a1 80
lnet: Unable to connect to remote host: Invalid argument
Pourtant ce n'est pas un problème "d'argument" puisque sur le serveur
lui-même, avec son adresse de loopback ça fonctionne:
telnet -6 ip6-localhost 80
Trying ::1...
Connected to ::1.
Escape character is '^]'.
D'ailleurs en utilisant wget, depuis ma station vers le serveur puis sur
le serveur lui-même c'est le même genre de problème:
Depuis la station:
wget fe80::a00:27ff:fe98:c7a1
--2016-10-24 17:47:54-- ftp://fe80/:a00:27ff:fe98:c7a1
=> «:a00:27ff:fe98:c7a1»
Résolution de fe80 (fe80)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «fe80»
Ça, c'est plutôt normal. En IPv4, le ':' sépare l'adresse IP ou le
nom du port utilisé.
Tu devrais essayer avec wget -6 (pas testé) pour voir s'il
interprète les adresses IPv6 correctement. Là, il doit être par
défaut en IPv4 et le fait d'avoir autre chose que des chiffres le
perturbe. Certains utilitaires utilisent une notation d'IPv6 entre
crochets.
sur le serveur lui-même ça fonctionne:
wget ip6-localhost
--2016-10-24 17:49:55-- http://ip6-localhost/
Résolution de ip6-localhost (ip6-localhost)… ::1
Connexion à ip6-localhost (ip6-localhost)|::1|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 177 [text/html]
Sauvegarde en : « index.html »
2016-10-24 17:49:55 (38,5 MB/s) — « index.html » sauvegardé [177/177]
Ce n'est donc pas un problème apache, puisqu'il peut se répondre à
lui-même. Il semble que ce soit la "pile" ipv6 qui pose problème (il n'y
a que le ping qui fonctionne). Je précise que tout firewall est
désactivé des deux côtés (règles iptables par défaut).
Qu'est-ce que j'ai loupé?
D'un côté, tu as une adresse résolue en IPv6. De l'autre tu indiques
brutalement d'adresse IPv6.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Mon, 24 Oct 2016 17:59:42 +0200, denis.paris écrivait :
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains n'hésitaient pas à affirmer que le système actuel était à bout de souffle et qu'il était urgent tout passer en v6. 10 ans après, je me suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent d'attendre, la généralisation des routeurs NAT avait reculé le problème. J'ai refermé l'oeil et attendu encore 10 ans de plus... Et je tombe sur un article de 2010 partant en guerre contre les gens qui ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas "sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4 allait être attribuée en 2011, et que le basculement était donc pour l'année 2011, il n'y avait pas d’échappatoire... Bref, je considère qu'il est tout de même temps qu'au moins à titre personnel je m'y intéresse, même si je ne suis pas sûr de voir cette transition majeure de mon vivant. Je commence donc prudemment par faire quelques tests sur mon réseau local (même si pour le fun j'ai activé l'ipv6 de ma box, histoire de voir si les serveurs de test-v6 considéraient que j'étais bon pour le service). J'ai un poste de travail en linux, avec une adresse: fe80::aee0:10ff:fed0:7e6/64 Un serveur WEB de test sur le même réseau privé: fe80::a00:27ff:fe98:c7a1/64 (bizarre, j'ai lu quelque part que les adresses commençant par fe n'étaient pas routables, mais comme pour l'instant je ne passe pas par un routeur, cela ne devrait pas être un problème) Et là mes ennuis commencent car je ne parviens pas à faire une requête http depuis ma station vers mon serveur. Les outils v4 et v6 sont différents et il est possible que je ne respecte pas correctement les nouvelles syntaxes. Je tente successivement: ping6 fe80::a00:27ff:fe98:c7a1 Invalid argument (ça commence bien)
Essaie avec une adresse IPv6 publique. Normalement, ça fonctionne : Root rayleigh:[~] > ping6 2001:7a8:a8ed:10::128 PING 2001:7a8:a8ed:10::128(2001:7a8:a8ed:10::128) 56 data bytes 64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=1 ttld timeC.3 ms 64 bytes from 2001:7a8:a8ed:10::128: icmp_seq=2 ttld timeB.7 ms Je viens de tester, même avec une adresse link-local, ça fonctionne encore : Root rayleigh:[~] > ping6 fe80::208:2ff:feaf:da71 PING fe80::208:2ff:feaf:da71(fe80::208:2ff:feaf:da71) 56 data bytes 64 bytes from fe80::208:2ff:feaf:da71%eth2: icmp_seq=1 ttld time=0.073 ms
en fait il faut indiquer la carte réseau, pourquoi pas: ping6 -I wlan0 fe80::a00:27ff:fe98:c7a1 64 bytes from fe80::a00:27ff:fe98:c7a1: icmp_seq=1 ttld time=0.234 ms => donc la connectivité semble OK Alors je me lance: telnet -6 fe80::a00:27ff:fe98:c7a1 80 lnet: Unable to connect to remote host: Invalid argument Pourtant ce n'est pas un problème "d'argument" puisque sur le serveur lui-même, avec son adresse de loopback ça fonctionne: telnet -6 ip6-localhost 80 Trying ::1... Connected to ::1. Escape character is '^]'. D'ailleurs en utilisant wget, depuis ma station vers le serveur puis sur le serveur lui-même c'est le même genre de problème: Depuis la station: wget fe80::a00:27ff:fe98:c7a1 --2016-10-24 17:47:54-- ftp://fe80/:a00:27ff:fe98:c7a1 => «:a00:27ff:fe98:c7a1» Résolution de fe80 (fe80)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «fe80»
Ça, c'est plutôt normal. En IPv4, le ':' sépare l'adresse IP ou le nom du port utilisé. Tu devrais essayer avec wget -6 (pas testé) pour voir s'il interprète les adresses IPv6 correctement. Là, il doit être par défaut en IPv4 et le fait d'avoir autre chose que des chiffres le perturbe. Certains utilitaires utilisent une notation d'IPv6 entre crochets.
sur le serveur lui-même ça fonctionne: wget ip6-localhost --2016-10-24 17:49:55-- http://ip6-localhost/ Résolution de ip6-localhost (ip6-localhost)… ::1 Connexion à ip6-localhost (ip6-localhost)|::1|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Sauvegarde en : « index.html » 2016-10-24 17:49:55 (38,5 MB/s) — « index.html » sauvegardé [177/177] Ce n'est donc pas un problème apache, puisqu'il peut se répondre à lui-même. Il semble que ce soit la "pile" ipv6 qui pose problème (il n'y a que le ping qui fonctionne). Je précise que tout firewall est désactivé des deux côtés (règles iptables par défaut). Qu'est-ce que j'ai loupé?
D'un côté, tu as une adresse résolue en IPv6. De l'autre tu indiques brutalement d'adresse IPv6. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Sergio
Le 24/10/2016 à 17:59, denis.paris a écrit :
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains n'hésitaient pas à affirmer que le système actuel était à bout de souffle et qu'il était urgent tout passer en v6. 10 ans après, je me suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent d'attendre, la généralisation des routeurs NAT avait reculé le problème. J'ai refermé l'oeil et attendu encore 10 ans de plus... Et je tombe sur un article de 2010 partant en guerre contre les gens qui ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas "sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4 allait être attribuée en 2011, et que le basculement était donc pour l'année 2011, il n'y avait pas d’échappatoire...
Peut pas tester ton truc, parce que mon opérateur fait parti des "neuneus" hélas (SFR via numéricâble). -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 24/10/2016 à 17:59, denis.paris a écrit :
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains n'hésitaient pas à affirmer que le système actuel était à bout de
souffle et qu'il était urgent tout passer en v6. 10 ans après, je me suis dis qu'il était peut-être temps de jeter un oeil sur le
truc, mais ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent d'attendre, la généralisation des routeurs NAT avait
reculé le problème. J'ai refermé l'oeil et attendu encore 10 ans de plus...
Et je tombe sur un article de 2010 partant en guerre contre les gens qui ne passaient immédiatement leur box en ipv6, ou pire les
neuneus qui revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains fournisseurs n'étaient qu'en v4 (autrement dit
leur ipv6 n'étaient pas "sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4 allait être attribuée en 2011, et
que le basculement était donc pour l'année 2011, il n'y avait pas d’échappatoire...
Peut pas tester ton truc, parce que mon opérateur fait parti des "neuneus" hélas (SFR via numéricâble).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Il y a 20 ans, quand on a commencé à parler d'ipv6, certains n'hésitaient pas à affirmer que le système actuel était à bout de souffle et qu'il était urgent tout passer en v6. 10 ans après, je me suis dis qu'il était peut-être temps de jeter un oeil sur le truc, mais ça n'avait semble-t-il pas avancé beaucoup. Il était toujours urgent d'attendre, la généralisation des routeurs NAT avait reculé le problème. J'ai refermé l'oeil et attendu encore 10 ans de plus... Et je tombe sur un article de 2010 partant en guerre contre les gens qui ne passaient immédiatement leur box en ipv6, ou pire les neuneus qui revenaient en arrière parce qu'ils voulaient utiliser un VPN et certains fournisseurs n'étaient qu'en v4 (autrement dit leur ipv6 n'étaient pas "sécurisé". Il affirmait d'une manière péremptoire que la dernière ipv4 allait être attribuée en 2011, et que le basculement était donc pour l'année 2011, il n'y avait pas d’échappatoire...
Peut pas tester ton truc, parce que mon opérateur fait parti des "neuneus" hélas (SFR via numéricâble). -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
telnet -6 fe80::a00:27ff:fe98:c7a1 80 lnet: Unable to connect to remote host: Invalid argument
Essaie telnet -6 fe80::a00:27ff:fe98:c7a1%eth0 80 (si l'interface en question est eth0)
denis.paris
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches. J'avais oublié de préciser une chose: la machine apache est une machine virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une machine virtuelle est une machine comme les autres!) mais c'est la façon dont elle est raccordée à ma station (réelle) qui posait problème. Etant hors de chez moi, j'avais lancé cette machine dans une instance "virtualbox", donc elle partageait la même carte réseau physique (celle de mon PC). Je suis maintenant de retour, et je fais tourner à présent une machine identique sur un système ESX Vmware, donc un "host" distinct. Du coup, ça fonctionne! (du coup mon web a récupéré une adresse v6 publique) Par exemple: telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80 Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71... Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71. Escape character is '^]'. En revanche wget ne fonctionne toujours pas: wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01» Mais j'ai contourné le problème en "mapant" cette adresse publique avec un nom de machine dans mon fichier "hosts" avec le nom "web6": ping6 web6 PING web6(web6) 56 data bytes 64 bytes from web6: icmp_seq=1 ttld time=0.218 ms 64 bytes from web6: icmp_seq=2 ttld time=0.276 ms 64 bytes from web6: icmp_seq=3 ttld time=0.292 ms et: wget web6 --2016-10-24 23:21:25-- http://web6/ Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71 Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» (wget fonctionne aussi avec le paramètre -6 qui semble optionnel) Mais d'autres outils ont besoin du paramètre -6, comme nmap: nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6): Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71) Host is up (0.00022s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind Donc le format exotique à base de ":" pose parfois des problèmes, mais pas toujours. Pour le navigateur Internet il faut mettre les "[]", etc... Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille. Merci à tous et bonne soirée.
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches.
J'avais oublié de préciser une chose: la machine apache est une machine
virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une
machine virtuelle est une machine comme les autres!) mais c'est la façon
dont elle est raccordée à ma station (réelle) qui posait problème.
Etant hors de chez moi, j'avais lancé cette machine dans une instance
"virtualbox", donc elle partageait la même carte réseau physique (celle
de mon PC). Je suis maintenant de retour, et je fais tourner à présent
une machine identique sur un système ESX Vmware, donc un "host"
distinct. Du coup, ça fonctionne!
(du coup mon web a récupéré une adresse v6 publique)
Par exemple:
telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80
Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71...
Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71.
Escape character is '^]'.
En revanche wget ne fonctionne toujours pas:
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71
--2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71
=> «e34:ec07:d660:250:56ff:fe83:5b71»
Résolution de 2a01 (2a01)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «2a01»
Mais j'ai contourné le problème en "mapant" cette adresse publique avec
un nom de machine dans mon fichier "hosts" avec le nom "web6":
ping6 web6
PING web6(web6) 56 data bytes
64 bytes from web6: icmp_seq=1 ttld time=0.218 ms
64 bytes from web6: icmp_seq=2 ttld time=0.276 ms
64 bytes from web6: icmp_seq=3 ttld time=0.292 ms
et:
wget web6
--2016-10-24 23:21:25-- http://web6/
Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71
Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 177 [text/html]
Enregistre : «index.html»
(wget fonctionne aussi avec le paramètre -6 qui semble optionnel)
Mais d'autres outils ont besoin du paramètre -6, comme nmap:
nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6):
Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST
Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71)
Host is up (0.00022s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Donc le format exotique à base de ":" pose parfois des problèmes, mais
pas toujours. Pour le navigateur Internet il faut mettre les "[]", etc...
Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille.
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches. J'avais oublié de préciser une chose: la machine apache est une machine virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une machine virtuelle est une machine comme les autres!) mais c'est la façon dont elle est raccordée à ma station (réelle) qui posait problème. Etant hors de chez moi, j'avais lancé cette machine dans une instance "virtualbox", donc elle partageait la même carte réseau physique (celle de mon PC). Je suis maintenant de retour, et je fais tourner à présent une machine identique sur un système ESX Vmware, donc un "host" distinct. Du coup, ça fonctionne! (du coup mon web a récupéré une adresse v6 publique) Par exemple: telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80 Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71... Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71. Escape character is '^]'. En revanche wget ne fonctionne toujours pas: wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01» Mais j'ai contourné le problème en "mapant" cette adresse publique avec un nom de machine dans mon fichier "hosts" avec le nom "web6": ping6 web6 PING web6(web6) 56 data bytes 64 bytes from web6: icmp_seq=1 ttld time=0.218 ms 64 bytes from web6: icmp_seq=2 ttld time=0.276 ms 64 bytes from web6: icmp_seq=3 ttld time=0.292 ms et: wget web6 --2016-10-24 23:21:25-- http://web6/ Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71 Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» (wget fonctionne aussi avec le paramètre -6 qui semble optionnel) Mais d'autres outils ont besoin du paramètre -6, comme nmap: nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6): Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71) Host is up (0.00022s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind Donc le format exotique à base de ":" pose parfois des problèmes, mais pas toujours. Pour le navigateur Internet il faut mettre les "[]", etc... Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille. Merci à tous et bonne soirée.
Ascadix
denis.paris a émis l'idée suivante :
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches. J'avais oublié de préciser une chose: la machine apache est une machine virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une machine virtuelle est une machine comme les autres!) mais c'est la façon dont elle est raccordée à ma station (réelle) qui posait problème. Etant hors de chez moi, j'avais lancé cette machine dans une instance "virtualbox", donc elle partageait la même carte réseau physique (celle de mon PC).
Oui .. mais ... Mode "Bridge" ou "NAT" ou "réseau isolé" ? là est le gros de la différence. Si t'en mode "Bridge" ... t'es p'tet sur un bug Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Je suis maintenant de retour, et je fais tourner à présent une machine identique sur un système ESX Vmware, donc un "host" distinct. Du coup, ça fonctionne! (du coup mon web a récupéré une adresse v6 publique) Par exemple: telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80 Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71... Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71. Escape character is '^]'. En revanche wget ne fonctionne toujours pas: wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01» Mais j'ai contourné le problème en "mapant" cette adresse publique avec un nom de machine dans mon fichier "hosts" avec le nom "web6": ping6 web6 PING web6(web6) 56 data bytes 64 bytes from web6: icmp_seq=1 ttld time=0.218 ms 64 bytes from web6: icmp_seq=2 ttld time=0.276 ms 64 bytes from web6: icmp_seq=3 ttld time=0.292 ms et: wget web6 --2016-10-24 23:21:25-- http://web6/ Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71 Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» (wget fonctionne aussi avec le paramètre -6 qui semble optionnel) Mais d'autres outils ont besoin du paramètre -6, comme nmap: nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6): Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71) Host is up (0.00022s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind Donc le format exotique à base de ":" pose parfois des problèmes, mais pas toujours. Pour le navigateur Internet il faut mettre les "[]", etc... Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille. Merci à tous et bonne soirée.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
denis.paris a émis l'idée suivante :
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches.
J'avais oublié de préciser une chose: la machine apache est une machine
virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une machine
virtuelle est une machine comme les autres!) mais c'est la façon dont elle
est raccordée à ma station (réelle) qui posait problème.
Etant hors de chez moi, j'avais lancé cette machine dans une instance
"virtualbox", donc elle partageait la même carte réseau physique (celle de
mon PC).
Oui .. mais ...
Mode "Bridge" ou "NAT" ou "réseau isolé" ?
là est le gros de la différence.
Si t'en mode "Bridge" ... t'es p'tet sur un bug
Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Je suis maintenant de retour, et je fais tourner à présent une
machine identique sur un système ESX Vmware, donc un "host" distinct. Du
coup, ça fonctionne!
(du coup mon web a récupéré une adresse v6 publique)
Par exemple:
telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80
Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71...
Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71.
Escape character is '^]'.
En revanche wget ne fonctionne toujours pas:
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71
--2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71
=> «e34:ec07:d660:250:56ff:fe83:5b71»
Résolution de 2a01 (2a01)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «2a01»
Mais j'ai contourné le problème en "mapant" cette adresse publique avec un
nom de machine dans mon fichier "hosts" avec le nom "web6":
ping6 web6
PING web6(web6) 56 data bytes
64 bytes from web6: icmp_seq=1 ttld time=0.218 ms
64 bytes from web6: icmp_seq=2 ttld time=0.276 ms
64 bytes from web6: icmp_seq=3 ttld time=0.292 ms
et:
wget web6
--2016-10-24 23:21:25-- http://web6/
Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71
Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 177 [text/html]
Enregistre : «index.html»
(wget fonctionne aussi avec le paramètre -6 qui semble optionnel)
Mais d'autres outils ont besoin du paramètre -6, comme nmap:
nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6):
Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST
Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71)
Host is up (0.00022s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Donc le format exotique à base de ":" pose parfois des problèmes, mais pas
toujours. Pour le navigateur Internet il faut mettre les "[]", etc...
Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille.
Merci à tous et bonne soirée.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Merci pour vos réponses, qui m'ont inspiré des pistes de recherches. J'avais oublié de préciser une chose: la machine apache est une machine virtuelle, ce qui ne m'a pas semblé au début devoir être signalé (une machine virtuelle est une machine comme les autres!) mais c'est la façon dont elle est raccordée à ma station (réelle) qui posait problème. Etant hors de chez moi, j'avais lancé cette machine dans une instance "virtualbox", donc elle partageait la même carte réseau physique (celle de mon PC).
Oui .. mais ... Mode "Bridge" ou "NAT" ou "réseau isolé" ? là est le gros de la différence. Si t'en mode "Bridge" ... t'es p'tet sur un bug Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Je suis maintenant de retour, et je fais tourner à présent une machine identique sur un système ESX Vmware, donc un "host" distinct. Du coup, ça fonctionne! (du coup mon web a récupéré une adresse v6 publique) Par exemple: telnet -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 80 Trying 2a01:e34:ec07:d660:250:56ff:fe83:5b71... Connected to 2a01:e34:ec07:d660:250:56ff:fe83:5b71. Escape character is '^]'. En revanche wget ne fonctionne toujours pas: wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01» Mais j'ai contourné le problème en "mapant" cette adresse publique avec un nom de machine dans mon fichier "hosts" avec le nom "web6": ping6 web6 PING web6(web6) 56 data bytes 64 bytes from web6: icmp_seq=1 ttld time=0.218 ms 64 bytes from web6: icmp_seq=2 ttld time=0.276 ms 64 bytes from web6: icmp_seq=3 ttld time=0.292 ms et: wget web6 --2016-10-24 23:21:25-- http://web6/ Résolution de web6 (web6)… 2a01:e34:ec07:d660:250:56ff:fe83:5b71 Connexion à web6 (web6)|2a01:e34:ec07:d660:250:56ff:fe83:5b71|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» (wget fonctionne aussi avec le paramètre -6 qui semble optionnel) Mais d'autres outils ont besoin du paramètre -6, comme nmap: nmap -6 2a01:e34:ec07:d660:250:56ff:fe83:5b71 (ou bien nmap -6 web6): Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-24 23:24 CEST Nmap scan report for web6 (2a01:e34:ec07:d660:250:56ff:fe83:5b71) Host is up (0.00022s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind Donc le format exotique à base de ":" pose parfois des problèmes, mais pas toujours. Pour le navigateur Internet il faut mettre les "[]", etc... Bref, la manipulation de ipv6 est loin d'être un long fleuve tranquille. Merci à tous et bonne soirée.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
denis.paris
Le 25/10/2016 à 01:00, Ascadix a écrit :
Oui .. mais ... Mode "Bridge" ou "NAT" ou "réseau isolé" ? là est le gros de la différence. Si t'en mode "Bridge" ... t'es p'tet sur un bug Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Mode Bridge, bien sûr. Le serveur de test se retrouve sur le même réseau que les autres machines derrière la box (192.168.0.0/24) Pas forcément un bug, sans doute un "feature" car l'ipV6 est censé être plus sécurisé, du coup il refuse de partager la même carte réseau, contrairement à un vrai équipement réseau qui en a au moins deux.
Le 25/10/2016 à 01:00, Ascadix a écrit :
Oui .. mais ...
Mode "Bridge" ou "NAT" ou "réseau isolé" ?
là est le gros de la différence.
Si t'en mode "Bridge" ... t'es p'tet sur un bug
Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Mode Bridge, bien sûr. Le serveur de test se retrouve sur le même réseau
que les autres machines derrière la box (192.168.0.0/24)
Pas forcément un bug, sans doute un "feature" car l'ipV6 est censé être
plus sécurisé, du coup il refuse de partager la même carte réseau,
contrairement à un vrai équipement réseau qui en a au moins deux.
Oui .. mais ... Mode "Bridge" ou "NAT" ou "réseau isolé" ? là est le gros de la différence. Si t'en mode "Bridge" ... t'es p'tet sur un bug Si t'es en mode NAT ou isolé, c'est normal que ça ne marche pas.
Mode Bridge, bien sûr. Le serveur de test se retrouve sur le même réseau que les autres machines derrière la box (192.168.0.0/24) Pas forcément un bug, sans doute un "feature" car l'ipV6 est censé être plus sécurisé, du coup il refuse de partager la même carte réseau, contrairement à un vrai équipement réseau qui en a au moins deux.
Nicolas George
"denis.paris" , dans le message <580e7e41$0$24787$, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une URL mal formée, il essaie de deviner et pense que c'est du FTP. Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer de crochets, puisque le caractère : sert souvent à délimiter le numéro de port. Apparemment, les adresses lien-locales ne sont pas autorisées.
"denis.paris" , dans le message
<580e7e41$0$24787$426a74cc@news.free.fr>, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71
--2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71
=> «e34:ec07:d660:250:56ff:fe83:5b71»
Résolution de 2a01 (2a01)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une
URL mal formée, il essaie de deviner et pense que c'est du FTP.
Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer
de crochets, puisque le caractère : sert souvent à délimiter le numéro de
port. Apparemment, les adresses lien-locales ne sont pas autorisées.
"denis.paris" , dans le message <580e7e41$0$24787$, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une URL mal formée, il essaie de deviner et pense que c'est du FTP. Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer de crochets, puisque le caractère : sert souvent à délimiter le numéro de port. Apparemment, les adresses lien-locales ne sont pas autorisées.
denis.paris
Le 25/10/2016 à 11:37, Nicolas George a écrit :
"denis.paris" , dans le message <580e7e41$0$24787$, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une URL mal formée, il essaie de deviner et pense que c'est du FTP. Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer de crochets, puisque le caractère : sert souvent à délimiter le numéro de port. Apparemment, les adresses lien-locales ne sont pas autorisées.
En effet avec wget il faut à la fois des crochets et préciser le protocole: wget [2a01:e34:ec07:d660:250:56ff:fe83:5b71] ftp://[2a01/e34:ec07:d660:250:56ff:fe83:5b71]: Adresse numérique IPv6 incorrecte. Mais la commande suivante fonctionne: wget http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71] --2016-10-25 13:39:22-- http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71]/ Connexion à [2a01:e34:ec07:d660:250:56ff:fe83:5b71]:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» Et si je mets l'adresse dans le hosts et que j'utilise le nom, cela fonctionne pour cette adresse publique même si je ne précise pas "http://". En revanche pour l'adresse locale il n'y a que le ping6 qui fonctionne, et encore faut-il préciser explicitement l'interface de sortie (ce qui ne me choque pas en effet, mais wget ne permet pas de la préciser).
Le 25/10/2016 à 11:37, Nicolas George a écrit :
"denis.paris" , dans le message
<580e7e41$0$24787$426a74cc@news.free.fr>, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71
--2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71
=> «e34:ec07:d660:250:56ff:fe83:5b71»
Résolution de 2a01 (2a01)… échec : Nom ou service inconnu.
wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une
URL mal formée, il essaie de deviner et pense que c'est du FTP.
Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer
de crochets, puisque le caractère : sert souvent à délimiter le numéro de
port. Apparemment, les adresses lien-locales ne sont pas autorisées.
En effet avec wget il faut à la fois des crochets et préciser le protocole:
wget http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71]
--2016-10-25 13:39:22-- http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71]/
Connexion à [2a01:e34:ec07:d660:250:56ff:fe83:5b71]:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 177 [text/html]
Enregistre : «index.html»
Et si je mets l'adresse dans le hosts et que j'utilise le nom, cela
fonctionne pour cette adresse publique même si je ne précise pas "http://".
En revanche pour l'adresse locale il n'y a que le ping6 qui fonctionne,
et encore faut-il préciser explicitement l'interface de sortie (ce qui
ne me choque pas en effet, mais wget ne permet pas de la préciser).
"denis.paris" , dans le message <580e7e41$0$24787$, a écrit :
En revanche wget ne fonctionne toujours pas:
Lis les messages d'erreur :
wget 2a01:e34:ec07:d660:250:56ff:fe83:5b71 --2016-10-24 23:18:07-- ftp://2a01/e34:ec07:d660:250:56ff:fe83:5b71 => «e34:ec07:d660:250:56ff:fe83:5b71» Résolution de 2a01 (2a01)… échec : Nom ou service inconnu. wget : impossible de résoudre l'adresse de l'hôte «2a01»
wget ne veut pas une adresse IP, il veut une URL. Comme tu lui donnes une URL mal formée, il essaie de deviner et pense que c'est du FTP. Pour mettre une adresse IPv6 numérique dans une URL, on est censé l'encadrer de crochets, puisque le caractère : sert souvent à délimiter le numéro de port. Apparemment, les adresses lien-locales ne sont pas autorisées.
En effet avec wget il faut à la fois des crochets et préciser le protocole: wget [2a01:e34:ec07:d660:250:56ff:fe83:5b71] ftp://[2a01/e34:ec07:d660:250:56ff:fe83:5b71]: Adresse numérique IPv6 incorrecte. Mais la commande suivante fonctionne: wget http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71] --2016-10-25 13:39:22-- http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71]/ Connexion à [2a01:e34:ec07:d660:250:56ff:fe83:5b71]:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 177 [text/html] Enregistre : «index.html» Et si je mets l'adresse dans le hosts et que j'utilise le nom, cela fonctionne pour cette adresse publique même si je ne précise pas "http://". En revanche pour l'adresse locale il n'y a que le ping6 qui fonctionne, et encore faut-il préciser explicitement l'interface de sortie (ce qui ne me choque pas en effet, mais wget ne permet pas de la préciser).
Nicolas George
"denis.paris" , dans le message <580f45b4$0$5277$, a écrit :
Mais la commande suivante fonctionne: wget http://[2a01:e34:ec07:d660:250:56ff:fe83:5b71]
Par hasard, puisqu'il y a des caractères spéciaux du shell qui ne sont pas protégés par des guillemets.
"denis.paris" , dans le message <580f45b4$0$5277$426a74cc@news.free.fr>,
a écrit :
