Comprendre IPv6 et sa problématique


#21

séparé ou pas, le matos n’est pas ou très peu dispo… C’est comme si sous pour passer en 4K, on devait faire tout les calculs graphiques sans les GPUs… Après je suis plus branché firewall que routeurs. De ce côté ils ont peut-être un peu d’avance (pas sûr quand un équipement reste parfois 10 ans en place…)


#22

L’adresse Mac qui arrive direct dans l’ip, c’est juste le mécanisme d’adressage le plus simple possible. Celui qui a pensé à ça avait juste pensé à supprimer un composant (le DHCP) et ça permet aussi de se passer de table arp (table de correspondance IP<->mac). D’un point de vue optimisation des ressources, c’est génial ! Par contre au niveau confidentialité, c’est moyen. Mais quand ipv6 a été écrit, cette problématique était inexistante.

Quand à faire de la sécurité sur une adresse mac/ip, c’est une hérésie. La sécurité doit se baser sur une authentification.


#23

Vraiment clair cet article @LoneWolf :slight_smile: , j’en profite pour te poser une question à laquelle je n’ai jamais rien compris, et pourtant je suis passé de non comprenant total en réseaux il y a quelques années, à petit utilisateur qui arrive à configurer de plus en plus de choses.

Comment fonctionnent et se règlent les masques de sous-réseaux ? :stuck_out_tongue: Je comprends que dalle, et je les mets plus ou moins au hasard à coup d’essai, erreur, recherche internet.

Sinon à lire cet article, c’est quand même mieux, même en IP6, d’être en mode NAT non visible de l’extérieur ? Après pour tata janine les redirections de ports sont plus pénibles à configurer en cas de besoin, mais c’est plus sûr non ? Il faudrait mieux une configuration automatique de redirection de port, que l’accessibilité directe potentielle de extérieure ?


#24

En IPv4, il y a eu plusieurs “règles” ou “normes” qui se sont succédées, et a la base, tu avais 3 grand groupes:
La classe A
La classe B
La classe C.
Il existe aussi les classe D et E mais qui sont pas vraiment utilisées.

La différence entre les 3, c’est que chaque classe A gère 16 millions de machines, la B 65534 et la C, 254
Le problème de ce système, c’est que tu n’as que 127 réseaux en classe A, seize mille et des brouettes en classe B et 2 millions en classe C

Et a l’époque, on utilisait que le système classique IP/mask qu’on écrivait 192.168.10.0/255.255.255.0, ce qui est la même chose que 192.168.10.0/24 (et c’est plus facile a écrire)
L’idée ici, c’est que tous les ordinateurs d’un même réseau peuvent parler entre eux, en direct (ie sans passer par un routeur, c’est a dire, pour reprendre mon analogie, de centre de tri postal). C’est comme si, dans la vraie vie, on allait poster directement les lettres qu’on écrit pour les gens habitant notre rue.

Comment le pc sait qu’il peut causer au voisin? Grace au masque justement. Imaginons que le pc s’appelle 192.168.10.42 (genre) et que son masque soit, classiquement dans ce cas la, 255.255.255.0 ou /24.
Quand il veut parler a 192.168.10.254, il prends l’IP et la soumet a son masque: 192.168.10.254/24=192.168.10
Il regarde sa propre IP 192.168.10.42 et fait pareil: 192.168.10.42/24=192.168.10. Le résultat est le même!!! Trop bien! Du coup, bah il va contacter directement 192.168.10.254. (je schématise un peu ici mais c’est plus simple, en vrai il regarde aussi sa table de routage)

En revanche, s’il veut parler a 192.168.11.254, il fait le même calcul et se rend compte que ca matche pas: 192.168.11.254/24=192.168.11. Busted! Dans ce cas la, il regarde sa table de routage interne (comme si chaque maison avait un centre de tri postal).
Il y a deux choix:
_Soit le pc connait un relais qui permet de contacter 192.168.11.254 et contacte ce relais en disant “eh, je veux parler a 192.168.11.254, c’est cool?” et c’est le relais (en général, un routeur) qui fera passer les messages.
_Soit le pc ne connait pas de relais permettant de contacter 192.168.11.254 et dans ce cas la, il va contacter son “relais par défaut”, qui est censé connaitre le chemin vers 192.168.11.254 OU qui connait quelqu’un qui connait quelqu’un (etc) qui connait le chemin…

C’est pas réécrit par @Cafeine, j’espère que c’est clair :slight_smile:

Pour le NAT en IPv6, le concept n’a pas de sens, mais je comprends ta question: en fait, tu réfléchis a l’envers :slight_smile:

La protection induite par le NAT est un effet de bord. C’était absolument pas voulu. Le but, et le seul but du NAT, c’est de permettre d’avoir plusieurs PC utilisant une seule IP publique, car on est en dèche d’IPv4.
De plus, le NAT introduit plein de bugs et autres galères sur certains protocoles, notamment FTP ou VOIP/TOIP.
Du coup, le fait que le NAT protège les machines n’est pas “important” pour les personnes désignant IPv6: n’oubliez pas qu’on est encore en 96-98, on sait pas ce que c’est qu’un lolcat et les script kiddies (ces pirates du dimanche relativement mauvais techniquement qui ne font que tout casser) n’existent pas encore (ou si peu).

Donc le but d’IPv6, c’est régler le problème du nombre et de faire en sorte que tous les protocoles (même les plus reloud) fonctionne sans soucis, donc en routage direct. Il faut donc réapprendre a protéger les réseaux et ça, c’est pas facile (et hors de porté de 99.99% de la population…). Mais en IPv6, ca ne se fera pas avec le NAT, qui n’a plus aucun sens.

Le retour des firewalls…


#25

Merci pour ces explications claires, je comprends beaucoup mieux le masque de sous-réseaux @LoneWolf :slight_smile: Donc dans un sous-réseaux perso simple, le masque sera le plus souvent 255.255.255.0, donc.

Et pour les NAT, de ce que j’en ai compris en essayant de de trouver des alternatives à skype sous linux, c’est qu’effectivement c’est bien reloud ce non routage direct : ou bien la solution doit avoir un serveur central sur internet, ou bien sans serveur il faut mettre à la mimine un redirection de port sur son routeur.

Mais en fait si on lit bien ton article et les évolutions d’IPv6, y compris les nouveaux mécanismes de protection, il faudra, à moins d’être en autarcie, toujours gérer l’évolution à terme et en même temps gérer les anciens systèmes : l’histoire n’est jamais finie, on arrivera jamais à avoir tout en IPv6, ou alors après de toute façon faudra pouvoir gérer l’IPv7…et donc on est condamnée, par définition dans un mode ouvert comme internet, à gérer la comptabilité ascendante et l’interopérabilité. N’est-ce pas ? :slight_smile:

En tout au moins avoir une bonne gestion des firewalls si j’en crois ta dernière phrase. La domotique avec ce que tu m’as expliqué, ça fait encore plus “peur” sans NAT :smiley: Mais au moins c’est plus susceptible d’être mis à jour car récent.


#26

J’en ai pas parlé mais le sous réseau perso a un nom, c’est les sous réseau non routable.
A ma connaissance, toutes les box utilisent le même type de sous réseau non routable de classe C, à savoir la plage 192.168.
L’idée est la suivante: tu utilises le NAT avec une IP au pif, genre 193.12.18.2. Ca marchera assez bien en fait, sauf dans un cas précis: Si tu essayes d’accéder a un service qui utilise déjà l’IP 193.12.18.2, bah ça marchera plus.
Il existe donc des sous réseaux spéciaux, appelés réseau non routable, qui n’ont pas de sens sur le réseau Internet.
Tu as ce type de réseau dans les 3 classes:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Dans ton cas, tu vas utiliser dans la majorité des cas une fraction de la zone 192.168.0.0/16 et dans ce cas, le masque utilisé est 255.255.255.0.

c’est exactement ca.

L’évolution d’Internet a été, est, et sera toujours empirique. En gros, tout le monde roule sur les autoroutes de l’information et quand on sera trop prêt du mur, il faudra trouver une échappatoire.
La majorité des bidules (appareils et logiciels) IPv4 only sont a 99% du temps obsolètes et pas indispensables.
Il va y avoir forcement du vieux matos industriel qui ne marchera que sous IPv4 mais ce genre de matériel n’a pas besoin, en général, d’internet. Donc on peut imaginer que les sociétés continueront a faire vivre un réseau IPv4 a coté ou par dessus un réseau IPv6. Et en imaginant que la société peine a sécuriser son réseau IPv6, bah IPv4 ne sera pas impacté car n’existant plus sur le réseau (on peut imaginer que les pirates trouvent des solutions pour péter IPv4 via un pc en double stack, mais bon).
En fait, les problèmes techniques existent mais sont surmontables.

Cette remarque me permet de continuer ce que je disais juste avant: Techniquement, c’est pas super compliqué, mais le problème est de faire évoluer les mentalités.
Je vais donner un exemple informatique mais simple pour illustrer.
Quand MS a sorti windows XP, il a fait un système exploitant au mieux (par rapport a win98…) les plateformes 5/686 (pentium I et supérieur), en ayant accru la sécurité utilisateur (un peu comme sous Unix) : Un utilisateur lambda sous XP peut pas faire grand chose et doit lancer pas mal de logiciel en mode administrateur pour que celui ci fonctionne. Ce genre de chose n’existait pas avec win98.
Du coup, MS a sorti des “guideline” de développement en expliquant que, si un logiciel doit effectivement être installé en mode admin, il doit pouvoir utiliser le logiciel sans être administrateur… C’était en 2002 (a peu près)
On est maintenant en 2016, avec Windows 10: est ce que vous pouvez utilisez TOUS vos logiciels sans être admin?
Pour le joueur, la réponse est non, dans le monde de l’entreprise, la réponse est “ça dépend, mais presque”. Si vous faites que de la bureautique, ça passe crème, mais des que vous utilisez des outils pro (certains compilateurs, outils 3D, etc), ca marche pas ou mal. 15 ans.
J’appelle ça le momentum technique: Les développeurs, les ingénieurs, etc, ont appris certaines techniques qu’ils maîtrisent et qui marchent, et pour des raisons de coût (formation etc) ou de flemme (eh ouais), ils ne sont pas forcement formé a l’état de l’art actuel. Et surtout dans un logiciel qui existent depuis 20 ans et qui est remis au gout du jour tous les ans (pour justifier une maintenance annuelle), on évite de faire des grosses modifs de structures - sauf quand on a plus le choix… Faire évoluer les mentalités des gens est difficile, changer les habitudes est ULTRA DIFFICILE. Genre Over 9000.

Du coup, pour IPv6, les premiers développement coûteront plus cher car il faut former les gens a une nouvelle techno, des nouvelles habitudes de programmation lié a la techno et aux conséquences de cette techno (genre la sécurité), mais aussi la résistance aux changement des personnes développant le produit: “ça marchait très bien avant, pourquoi changer?”. Et je parle même pas de trouver un bon formateur sur une techno naissante.

Il n’y a pas vraiment de solution miracle en fait, on déplace juste le problème. Et c’est peut être une bonne chose, quand tu réfléchis autrement:
Tu parlais de domotique, genre commander le chauffage de sa maison a distance. En IPv4, le constructeur du système doit prévoir un serveur pour faire le lien entre la centrale de commande, dans la maison, et le téléphone du client. En effet, a cause du NAT, le téléphone ne peut pas se connecter directement a la centrale (enfin c’est possible, mais difficile a faire pour le commun des mortels). Donc le téléphone configure virtuellement son chauffage sur le serveur et la centrale de commande, de temps en temps, va contacter le serveur pour savoir s’ils y a de nouveaux ordres.
Imaginons qu’un pirate trouve une faille sur le serveur et obtienne l’accès, du coup, a l’intégralité des centrales des clients du constructeur. Et pour le “LOLZ”, configure toutes les centrales en “full power” ou au contraire “froid sibérien”.
Pretty scary huh?

Imaginons le même scénario en IPv6: On a pas de NAT, donc le phone peut se connecter directement a la centrale. Premier point positif, il n’y a pas de latence et la commande est directe. En revanche, l’accès a la centrale est direct et n’importe qui peut se connecter. On imagine quand même que, comme pour le serveur en IPv4, il y a une sécurité avec un mot de passe. Malgre tout, si la centrale contient un trou de sécurité, le pirate pourra se connecter et mettre full power ou froid sibérien. Ouaip. Mais la différence, c’est qu’il pourra le faire que pour une seule maison a la fois. Et qu’il va en chier de ouf pour trouver toutes les centrales de chauffage en IPv6 de la terre, limitant ainsi les risques de surconsommation globaux (pour le mec qui s’est fait powned son chauffage, ca reste pas cool)

C’est toujours une bonne chose, le NAT? :wink:

IPv6, la mort du minitel 2.0 ? :slight_smile:


#27

à propos des NAT, j’avais été très surpris de voir que je pouvais me connecter sur mon Nas depuis l’extérieur sans avoir à configurer le NAT de ma freebox pour exposer le serveur du NAS sur l’IP publique.
En fait dans mon cas (et ma freebox supporte ce mode) ils utilisent un truc qui s’appelle “Hole Punching”.
En gros le Nas se connecte à un serveur de Synology, mon en tant que client externe je me connecte ausse à ce serveur. Et ensuite mon client externe utilise directement la connexion ouverte par le Nas vers le serveur Synology.
Ca evite de devoir faire transiter tout le trafic par le serveur de Synology.

Ca m’avait surpris cette méthode, niveau sécurité ça pose peut-être des soucis. Je me rappelle aussi avoir lu que basé sa sécurité sur un NAT, c’est un peu le mal.


#28

Xbox fait ca pour permettre aux gens de jouer sans serveur central depuis des annees et personne rale (ou a realise peut etre…).


#29

Une autre problématique de l’IPv6, qui a été un peu évoquée dans les commentaires, c’est que la plupart des opérateurs l’ignorent totalement dans leurs configurations. On peut voir des “box” où l’IPv6 est activé mais pas le NAT sur ce protocole. Pourquoi pas, comme expliqué dans ce (très bon) article ça pose pas de problème… sauf au niveau sécurité. Surtout quand SFR (c’est un exemple réel) avait oublié d’activer le pare-feu sur l’IPv6… Résultat on se retrouvait avec des tonnes de PC directement connectés à Internet par IPv6 (Windows par exemple assigne une addresse locale mais aussi publique par défaut, Linux il faut choisir mais si on l’active c’est pareil, MacOS je sais pas) et protégés uniquement par le pare-feu de l’OS… On a vu mieux.

Et je ne parle pas de toutes ces caméras IP(v6) et autres saloperies d’objets connectés qui avaient aussi une IPv6. On a vu nombre de failles de sécurités exploitées ainsi (par exemple des mineurs Bitcoin sur les SmartTV ou … frigo connectés). Sans parler des problématiques de vie privée. Votre caméra qui est censée vous protégée peut être utilisée pour vérifier que vous êtes chez vous ou non, merci !

Enfin pour ce qui est des performances des équipements réseau, ça fait quand même quelques années qu’IPv6 est dans les ASIC des routeurs, mais sur les équipements “couches 4-7” (pare-feu, répartiteurs de charge, IPS, …) c’est ) peine entammé. Fortinet, un des leader du secteur, ne le fait que depuis 1 an par exemple. Il faut dire que c’est super chiant à parser IPv6 (les programmes veulent le least significant byte en premier, les réseau en dernier, donc faut les intervertir sans arrêt ça tue les perfs).


#30

Le NAT n’est PAS de la sécurité. Cela permet en revanche de concentrer sa sécurité sur un goulet d’étranglement.

C’est comme de dire qu’avoir une porte c’est de la sécurité. Ce n’est pas intrinsèquement vrai - par exemple, si on laisse la porte ouverte ou qu’on ne la verrouille pas, la présence d’une porte n’améliore pas la sécurité. En revanche si on la verrouille et qu’on contrôle les accès de tout ce qui entre, là on peut parler de sécurité :slight_smile:

Tout ce qui est “sécurité automatique” (genre UPnP) je déconseille, mais pour le “hole punching” ça dépend comment c’est fait. SyncThing le fait très bien ; Synology on ne sait pas car leur protocole est propriétaire donc quand ils disent qu’ils ne voient pas le trafic il faut leur faire confiance sur parole.


#31

J’aime ce genre d’articles qui savent rester en equilibre entre la rigueur techniques et l’accessibilité. Félicitations @Lonewolf.

J’aime beaucoup mon Syno, mais avec les différents soucis de sécurité de ces dernières années, j’ai désactivé tous les services accessibles depuis l’extérieur. Je garde seulement OpenVPN et je m’en sers pour accéder au reste.


#32

J’ai pensé à cette news en voyant le titre de la news L’option « vraie IP fixe » arrive sur Freebox cette semaine, et je ne comprenais pas car à ma connaissance chaque Freebox a une IP fixe, et en fait non :

Pour faire face à la pénurie d’adresses IPv4 en cours, Free a commencé à utiliser la même adresse pour plusieurs abonnés simultanément.

@LoneWolf merci pour l’article ! J’ai une question par rapport à cette partie :

Pour pallier à ce problème, le routeur de la box de Caféine conserve une correspondance entre les accès de chaque machine et leur nom. Et elle “masque” ce nom avec l’adresse publique. De l’extérieur, on voit uniquement “France. 92600 Asnières. rue Geekzone. 42. Mr Caféine”, mais la box est capable de rediriger les accès aux ordinateurs concernés. Les paquets de données de votre partie de Starcraft II n’iront donc pas s’échouer bêtement sur votre smartphone.

Peux-tu expliquer brièvement comment se fait cette correspondante ? Est-ce que ça se base sur les ports de sortie ? Si on prend par exemple des requêtes HTTP sur le port 80 d’un serveur, comment la box envoie 2 requêtes faites par 2 PCs au serveur puis renvoie le bon résultat au bon PC ? Merci d’avance.


#33

Si. Mon pc se retrouve pas sur Shodan grace au NAT. Par construction il est plus sécurisé qu’en direct sur internet.


#34

Ton PC pourrait très bien ne pas se retrouver sur Shodan même sans NAT. Il suffit d’avoir un pare-feu qui filtre les ports sortants. NAT != Pare-feu. Tous les pare-feu font du NAT, mais le NAT ne veut pas forcément dire pare-feu.


#35

Simplement, le routeur/NAT conserve une table de correspondance avec pour chaque connexion (TCP) :

  • (A) IP source / port source du client (IP privée du PC)
  • (B) IP publique source / port sur le routeur (normalement le routeur essaie de conserver le même port source)
  • © IP publique / port destination du serveur

Quand un paquet (src A -> dst C) sort (du client vers le serveur), le NAT remplace (A) par (B) dans l’en-tête “source” du paquet. Pour le serveur, il semble donc venir de (B).
Quand le serveur répond, par un paquet (src C -> dst B), le NAT remplace (B) par (A) dans l’en-tête “destination” du paquet.

En UDP, ou il n’y a normalement pas de notion de connexion, certains NATs peuvent ne pas conserver ©, et l’ignorer completement. Seule la conversion (A)<->(B) est effectuée (sur l’en-tête ‘source’ pour les paquets sortants, et l’en-tête ‘destination’ pour les entrants). Celà permet entre-autres de faire du hole punching, et permettre a deux machines toutes deux derrière des NAT de communiquer entre elles. D’autres vont conserver ce couplage à la destination, et poser plus de soucis pour les communications directes (forcant l’utilisation de serveurs de rebond).


#36

Merci les gens pour les compléments d’info!

Je connaissais pas la technique du hole punching, je pensais pas ca possible mais apparemment, ca marche qu’en udp, ce qui me parait plus cohérent…

Comme le dit @Furism, le NAT ne sert qu’a faire de la translation d’adresse et sa protection “de facto” n’est qu’un effet de bord. Malheureusement, beaucoup de personnes comptent encore la dessus, a tel point que j’ai trouvé une première version de NAT pour IPv6 (merci a @Furism) - une hérésie.

Et je pensais que le NAT etait plus “costaud” que juste mémoriser le couple IP/port pour faire la translation, je pensais que le routeur stockait aussi l’ID (voir le checksum original) du paquet IP transmis par le pc local. Merci a @Tzim pour la précision.

On en apprend tous les jours!


#37

J’avais déjà plus ou moins fait l’état de l’art sur les méthodes de hole punching en 2005 … (projet de M1, on appelais pas ca comme ca à l’époque) et la conclusion c’était que IPv6 était la meilleure solution :slight_smile: . Le fait étant que le comportement des NATS vis a vis de l’UDP diffère (pas standardisé). Des protocoles dédiés ont du êtres créés pour

  • Détecter le comportement (ainsi que tenter de “deviner” les entrées de la table du NAT ) => STUN
  • Proposer un réflecteur UDP quand la mise en relation directe n’est pas possible => TURN
  • Détecter la meilleure solution pour l’établissement de la comm (flux audio/video) => ICE

L’idée aujourd’hui, en résidentiel/grand public (bref, sur réseaux non-managés) est que la protection doit du coup se faire au niveau de la machine finale, et non pas par un dispositif en entrée de réseau. L’inclusion d’un pare-feu dans windows allait déjà en ce sens. Ce n’est d’ailleurs pas stupide dans le sens que de plus en plus de devices sont mobiles et amenés à ce connecter a divers réseaux plus ou moins publics. Le firewalling dans la box obligerais à remettre une couche type UPnP/IGD ou équivalent pour que les applis demandent l’ouverture de la porte… bref, hérésie.
NAT pour IPv6 n’a pas d’interet pour la sécurité. Par contre, l’interet est pour le ré-adressage : j’ai changé d’adresse, mais je veux pas reconfigurer mon réseau, ou pour du multihoming. Ca pose d’autres soucis, par contre…

Non, il ne stocke en général pas le premier paquet, ni même l’ID. (la fonction pare-feu peu le faire, mais pour des optiques de filtrage spécifiques … ). Par contre, comme les entêtes sont réécrites, il doit aussi recalculer les checksums correspondants. Et ca, c’est couteux en temps.

Les gros défaut du NAT sont d’ailleurs là : Ca coute en CPU (calcul du checksum), et en RAM (table d’état : une connexion = une entrée). Et ca se sent : prenez une box un peu vieille, lancez un client bittorent avec le protocole DHT actif. Plantage, voire reboot de la box assuré (saturation de la table NAT) !

Sinon, une petite précision sur IPv6 : Une addresse v6, c’est 128bits : les 64 derniers bits sont réservés pour les machines du même segment réseau. Ce qui laisse possible 2^64 machines par segment réseau. Je vous laisse imaginer le temps nécessaire pour parcourir l’ensemble des machines d’un unique réseau. Après, le découpage des réseaux sur les 64 premiers bits est fonction de l’opérateur. La préco est de distribuer un /48. Free, pour des raisons techniques (encapsulation 6to4rd) distribue des /56.

A ce sujet : jusque là, l’opérateur n’avait besoin que de distribuer une adresse publique IPv4 a la box. Il doit maintenant être en mesure de distribuer un, voire plusieurs préfixe IPv6 => pour celà DHCP à été étendu en DHCPv6-PD (prefix delegation).


#38

Concernant la note sur le report de la protection sur la machine finale. C’est vrai que c’est une bonne chose et que c’est nécessaire, en revanche je souhaite préciser qu’il ne faut absolument pas que ce soit la seule protection d’un réseau. Il est toujours plus sûr de sécuriser un réseau sur des équipements réseau. La raison est que la surface d’attaque d’un tel équipement est beaucoup plus faible qu’un OS complet de serveur ou de poste client - ce qui est normal, ce sont des équipements spécialisés.

Il est ainsi en général plus sûr de bloquer des attaques ou des exploitations de vulnérabilité ou des virus au niveau d’un IPS ou d’un anti-virus réseau (ou d’un Web Application Firewall pour les appli réseau elles-mêmes) qu’au niveau de l’OS ou d’un logiciel qui y tourne.

Bon ça c’est quand ce sont des vrais bons équipements (typiquement ce qu’on trouve en entreprise) et pas des pare-feu grand public qui tournent sur de l’iptable mal configuré.


#39

C’est vrai en environnement controlé (administré). Ce n’est pas vrai, ni souhaitable en environnement grand public. Et encore … j’ai vu des IPS et firewalls faire plus de dégats qu’autre chose.


#40

Comme je le disais sur le chat, c’est sûr qu’il y aura toujours un admin pour faire une config pourrie - ça veut pas dire que la pratique est nécessairement mauvaise dans son ensemble :wink: