Passage IPV6

Support Debian
#1

Salouté les gens,

Je me casse les dents actuellement pour le passage à l’IPV6 d’un VPS, je cherche de la documentation orienté Debian pour la gestion de l’IPV6.

Actuellement j’ai un fichier d’interfaces comme ceci en IPV4 qui est pleinement fonctionnel :
(moins les choses que j’ai testé comme des ponts et autres alias)

allow-hotplug eth0 iface eth0 inet static address 178.170.XXX.XXX netmask 255.255.255.0 network 178.170.XXX.0 broadcast 178.170.XXX.255 gateway 178.170.XXX.1

J’ai pour l’instant un ping6 et un traceroute6 fonctionnel avec quelque chose comme ça :

allow-hotplug eth0 iface eth0 inet6 static address 2A00:C70:1:178:170:XXX:XXX:1 netmask 64 gateway 2A00:C70:1:178:170:XXX::1

Et j’aimerai bien pouvoir m’affranchir de la référence à l’IPV4 dans adressage mais je butte là dessus.

En aparté même si le VPS ping et effectue un traceroute cmplet vers l’afnic en IPV6 je n’arrive pas à m’y connecter en SSH à l’aide de la commande :

Ai-je zappé un truc ? (juste au cas où je n’avais plus accès à nmap ce matin au taff depuis cygwin :confused: je n’ai donc pas pu tester que le port soit ouvert mais le message d’erreur est clair : ‘connect: Network is unreachable’ et vu que je n’ai pas une version de ping6 sur le cygwin je n’ai pas pu tester un ping vers le serveur)

Je pourrais donner plus d’information demain (nmap et ping6 vers le VPS ) …

#2

Bonjour,

Il me semble avoir le même genre de message lorsque je veux faire de l’IPv6 avec un wifi qui ne fait que de l’IPv4.

sshd peut être paramétré pour ne répondre qu’en IPv4 (listenaddress 0.0.0.0 ?)

#3

[quote=“mazarini”]Bonjour,

Il me semble avoir le même genre de message lorsque je veux faire de l’IPv6 avec un wifi qui ne fait que de l’IPv4.

sshd peut être paramétré pour ne répondre qu’en IPv4 (listenaddress 0.0.0.0 ?)[/quote]

Yep comme à mon habitude :stuck_out_tongue: j’ai posté trop vite il me semble savoir où je me suis chié dans la conf du bouzin :083

Je ferais les réctifications demain et je vous tiendrais au jus si les essais sont concluants.

Si jamais il y a des conseils malgré tout je suis preneur :033 .

#4

Salut,

vi /etc/ssh/sshd_config :

ListenAddress :: ListenAddress 0.0.0.0

Première ligne pour l’ipv6
Deuxième ligne pour l’ipv4

#5

Salut,

vi /etc/ssh/sshd_config :

ListenAddress :: ListenAddress 0.0.0.0

Première ligne pour l’ipv6
Deuxième ligne pour l’ipv4[/quote]

Yep c’est ce que je me suis dit en me traitant de grosse baderne sans cervelle au yeux de taupe et à la lecture déficiente :005

Mais je pense aussi avoir trouvé d’où provient mon souci principale d’IPV6, faudra que je teste mais pour le SSH c’est sûr et certains j’ai sans doute zappé de dé-commenté l’adresse d’écoute :stuck_out_tongue: .

  • EDIT - je n’ai pas besoin de monter le module IPV6 car je suis sur un kenel maison, mais de toute façon il me semble que le kernel de wheezy ne le réclame pas non plus (au cas où pour ceux qui lisent).
#6

En fait, si aucune ligne est dé-commentées, ssh doit marcher. C’est si l’une ou l’autre est active que ca bloque l’autre.

Avec un noyau wheezy sur le serveur, IPv6 marche. Par contre, pas mal de trucs ne prévoient pas IPv6 (comme fail2ban ou knockd)

#7

[quote=“mazarini”]En fait, si aucune ligne est dé-commentées, ssh doit marcher. C’est si l’une ou l’autre est active que ca bloque l’autre.

Avec un noyau wheezy sur le serveur, IPv6 marche. Par contre, pas mal de trucs ne prévoient pas IPv6 (comme fail2ban ou knockd)[/quote]

Oui, ça j’en ai connaissance, le hack de fail2ban ne me tente pas non plus je me dirige vers du Portsentry, de toute façon c’est pour du container LXC et sur du domU Xen et de l’Openstack le but en premier lieu s’est de me familiariser avec l’IPV6.

De toute façon vue les ‘slash’ IP immense à scanner et ‘brute forcer’ en IPV6 le ‘port knocking’ tout comme Fail2ban ne sont pas une nécessité.
Je reste persuadé qu’il doit exister de toute manière une procédure pour reproduire le fonctionnement du ‘port knocking’ en IPV6.

#8

Que veux-tu dire exactement ?

Donc il a bien une connectivité IPv6 globale puisqu’il peut communiquer en IPv6 avec une destination globale.
Pour savoir si sshd écoute en IPv6, il suffit d’exécuter netstat -6lnp. Tu peux aussi essayer de t’y connecter depuis le VPS lui-même.

Ce message d’erreur indique normalement que la machine source, ou un routeur intermédiaire, n’a pas de route pour l’adresse de destination. La plupart du temps, c’est parce que la machine source n’a pas de connectivité IPv6 globale. Cela peut aussi venir d’un filtrage par un pare-feu (par exemple avec la cible REJECT d’ip6tables), mais ce n’est pas la réponse standard, je m’attendrais plutôt à “port unreachable” (réponse par défaut de REJECT) ou “communication prohibited” ou “connection refused”, ce qui correspond à l’envoi d’un TCP RST comme si le port n’était pas ouvert.

#9

Que veux-tu dire exactement ?[/quote]

Le fais que pour l’instant dans mon adresse déclaré dans le fichier d’interfaces il y est référence à mon IPV4.

Etant donné que je souhaite mettre ne place des container possédant pour trois d’entre eux une IP en IPV6 propre.

Donc il a bien une connectivité IPv6 globale puisqu’il peut communiquer en IPv6 avec une destination globale.
Pour savoir si sshd écoute en IPv6, il suffit d’exécuter netstat -6lnp. Tu peux aussi essayer de t’y connecter depuis le VPS lui-même.[/quote]

C’est la que le bas blesse, je travail actuellement sur un VDI que je n’ai pas encore finit de configurer, je n’ai pas encore tous mes outils réseau d’installer et certaines versions ne permettent pas de tester de l’IPV6 :frowning: (cygwin inside :confused: ).

Mais ce sera réglé ce week-end durant mes heures de nuits qui sont tout de même plus calme (enfin je l’espère :whistle: ).

Ce message d’erreur indique normalement que la machine source, ou un routeur intermédiaire, n’a pas de route pour l’adresse de destination. La plupart du temps, c’est parce que la machine source n’a pas de connectivité IPv6 globale. Cela peut aussi venir d’un filtrage par un pare-feu (par exemple avec la cible REJECT d’ip6tables), mais ce n’est pas la réponse standard, je m’attendrais plutôt à “port unreachable” (réponse par défaut de REJECT) ou “communication prohibited” ou “connection refused”, ce qui correspond à l’envoi d’un TCP RST comme si le port n’était pas ouvert.[/quote]

C’est un peu ce qui me faisais tiquer au vue du message renvoyer et du peut de test quej e pouvais pratiquer à ce moment là, j’avais un peu peur d’une connectivité limité en IPV6 ou une blague sur un des firewall software mis en place en amont.

Merci pour toute ces précisions, je vais pouvoir mettre ne pratique mes petits tests à la maison, je n’ai malheureusement pas eu une minute à moi hier et aujourd’hui au boulot :stuck_out_tongue:

  • EDIT - correction des balises :blush:
#10

Il doit manquer des balises dans ton messages, tes réponses sont contenues dans le bloc de citation qui m’est attribué.

[quote=“Clochette”]Le fais que pour l’instant dans mon adresse déclaré dans le fichier d’interfaces il y est référence à mon IPV4.
Etant donné que je souhaite mettre ne place des container possédant pour trois d’entre eux une IP en IPV6 propre.[/quote]
Désolé, je ne comprends toujours pas quel est le problème avec l’IPv4.

VDI ?
Si c’est sous Windows, il y a des commandes natives pour tester la connectivité IPv6.

  • Windows 2000/XP avec IPv6 activé (pas par défaut) : ping6, tracert6, telnet
  • Windows Vista et au-delà : ping -6, tracert -6, telnet
    Et bien sûr, pour faire du SSH, Putty fonctionne en IPv6.
#11

[quote=“PascalHambourg”]Il doit manquer des balises dans ton messages, tes réponses sont contenues dans le bloc de citation qui m’est attribué.

[quote=“Clochette”]Le fais que pour l’instant dans mon adresse déclaré dans le fichier d’interfaces il y est référence à mon IPV4.
Etant donné que je souhaite mettre ne place des container possédant pour trois d’entre eux une IP en IPV6 propre.[/quote]
Désolé, je ne comprends toujours pas quel est le problème avec l’IPv4.[/quote]

J’avoue ne pas maîtriser complètement encore l’adresssage d’IP en IPV6 mais avec un truc comme ça :

2A00:C70:1:178:170:XXX:XXX:1

Ou 178.170.XXX.XXX et mon IP fournir en IPV4 ne ressemble pas à une IPV6 mais à un mélange des deux.

Après j’ai retrouvé deux autres documentation qui me seront utile ce week-end, pour finir mes quelques tests, car je vient aussi de penser que si je vire totalement l’IPV4 de mon serveur virtuel et de mes containers seuls les gens disposant d’une connectivité en IPV6 pourront atteindre :think:

Du coup je pense déjà mettre ne place un IPV6 fonctionnel et ensuite remettre aussi le support de l’IPV4 actif via un tunnel IPV6to4.

Malheureusement je n’ai vraiment pas un débit correct pour continuer mes tests sur le serveur de chez moi je devrais donc attendre de retourner au taff ce week-end.

VDI ?
Si c’est sous Windows, il y a des commandes natives pour tester la connectivité IPv6.

  • Windows 2000/XP avec IPv6 activé (pas par défaut) : ping6, tracert6, telnet
  • Windows Vista et au-delà : ping -6, tracert -6, telnet
    Et bien sûr, pour faire du SSH, Putty fonctionne en IPv6.[/quote]

Le VDI sur lequel je taff actuellement n’est pas complet il me manque certains outils tel que nmap et consorts, je remets à jour mon Cygwin ce week-end et je finit de déployer certains outils.

#12

[quote=“Clochette”]2A00:C70:1:178:170:XXX:XXX:1
Ou 178.170.XXX.XXX et mon IP fournir en IPV4 ne ressemble pas à une IPV6 mais à un mélange des deux.[/quote]
Je ne suis toujours pas sûr de comprendre de quoi tu parles. Sauf dans quelques cas particuliers d’adresse IPv4 incluse dans une adresse IPv6 (6rd, 6to4, IPv4-mapped, IPv4-compatible), il n’y a a priori aucun lien entre les adresses IPv4 et IPv6 d’une machine. Dans tous les autres cas, c’est purement une convention du FAI ou hébergeur qui attribue les adresses, ce qui est certes assez courant pour des raisons de facilité de gestion.

Evidemment. IPv4 et IPv6 sont deux protocoles distincts, deux réseaux distincts. Certes il existe des passerelles et d’autres mécanismes de transition pour communiquer entre les deux, mais c’est une autre affaire. La double pile IPv4+IPv6 est la règle générale.

Le tunnel automatique 6to4 sert à faire passer de l’IPv6 (avec un préfixe particulier 2002:<adresse_IPv4>::/48) sur de l’IPv4, pas l’inverse. Et il n’est pas particulièrement fiable car il dépend de la bonne accessibilité de relais 6to4 à la fois par la source et la destination. Certaines destinations IPv6 natives ne sont pas accessibles par 6to4. Il vaut mieux utiliser la connectivité IPv6 native fournie par le FAI ou l’hébergeur.

Je ne sais toujours pas ce qu’est ce VDI…

#13

[quote=“PascalHambourg”][quote=“Clochette”]2A00:C70:1:178:170:XXX:XXX:1
Ou 178.170.XXX.XXX et mon IP fournir en IPV4 ne ressemble pas à une IPV6 mais à un mélange des deux.[/quote]
Je ne suis toujours pas sûr de comprendre de quoi tu parles. Sauf dans quelques cas particuliers d’adresse IPv4 incluse dans une adresse IPv6 (6rd, 6to4, IPv4-mapped, IPv4-compatible), il n’y a a priori aucun lien entre les adresses IPv4 et IPv6 d’une machine. Dans tous les autres cas, c’est purement une convention du FAI ou hébergeur qui attribue les adresses, ce qui est certes assez courant pour des raisons de facilité de gestion.[/quote]

Merci pour cet éclaircissement, j’avais eu confirmation que nous possédions une connectivité en IPV6 et en IPV4, j’avais simplement un doute sur le support de l’IPV6 seul.
Du coup je sais ce que je vais pouvoir tester sur l’hyperV qui héberge le VPS.

Evidemment. IPv4 et IPv6 sont deux protocoles distincts, deux réseaux distincts. Certes il existe des passerelles et d’autres mécanismes de transition pour communiquer entre les deux, mais c’est une autre affaire. La double pile IPv4+IPv6 est la règle générale.

Le tunnel automatique 6to4 sert à faire passer de l’IPv6 (avec un préfixe particulier 2002:<adresse_IPv4>::/48) sur de l’IPv4, pas l’inverse. Et il n’est pas particulièrement fiable car il dépend de la bonne accessibilité de relais 6to4 à la fois par la source et la destination. Certaines destinations IPv6 natives ne sont pas accessibles par 6to4. Il vaut mieux utiliser la connectivité IPv6 native fournie par le FAI ou l’hébergeur.[/quote]

Effectivement une autre chose à vérifier, même si au vue de l’explication je pense maintenant me diriger vers une double connectivité IPV4 et IPV6 sans passé par un tunnel.

Je ne sais toujours pas ce qu’est ce VDI…[/quote]

Le VDI que j’utilise c’est du ‘virtual desktop infrastructure’ en gros tu peu penser à un un serveur virtuel accueillant tous mon profil et relié à un stockage permettant de garder au chauds mes données.
Les profils sont hébergés indifféremment sur les VM démarré et libre d’utilisation.

Grosso modo une belle trouvaille des responsables chez nous pour nous verrouiller les applications que nous utilisons et imposer certains outils :stuck_out_tongue:
Mais nous avons tout de même le gros avantages de ne plus avoir besoin d’un poste de travail attribué pour pouvoir bénéficier de nos données et de nos outils de travail.
Notre VDI est couplé avec un espace cloud pour stocker nos documents personnel et autres projets divers ce qui nous permet de pouvoir accéder de n’importe quels postes à notre poste de travail personnalisé ( enfin de ce que l’on peu personnalisé) et nos outils (pour le moins restreints car encore en cours de déploiement après accords).

La ‘techno’ que nous utilisons est made in gro$oft mais il me semble aussi disponible chez Citrix et sans doute chez d’autre acteurs du marché de la virtualisation.
Chez citrix c’est le produits qui se place à un niveau supérieur du vieillissant XenAppp en proposant de virtualisé le bureau complet et non plus les applications.

#14

Il a une connectivité IPv6 globale au moins, ce VDI ?

#15

Sur le VDI théoriquement oui, le service réseau me l’a confirmé de vive voie mais je ferais la vérification tout de même depuis un poste à l’extérieur qui lui l’est.