Trop long, pas lu :
IPv6 est un excellent exemple de la différence entre la théorie et la pratique. Et le journal ne répond pas à la question du titre.
J'ai découvert ipv6 à la fin des années 90 dans mes cours à l'université où l'on m'a expliqué que ça réglerait le problème du nombre d'ip limité de ipv4 (oui, c'était une introduction au réseau, et on parlait encore de bus et d'étoile).
Mon premier vrai contact avec ipv6 a eu lieu au début des années 2000 quand j'ai créé un compte chez Hurricane Electric et monté un tunnel que j'ai utilisé pendant au moins 20 minutes avant de ne plus jamais le relancer.
Mon troisième vrai contact avec ipv6 s'est produit en mars 2020 quand j'ai commencé à avoir un comportement bizarre sur mon réseau familial.
Le-dit réseau comportait :
- la box de l'opérateur (Livebox Orange FTTH)
- un serveur freedombox hébergeant quelques services (agenda, contacts, DNS, DHCP, partages réseaux)
- des machines clientes (PC sous linux, imprimantes, tablettes et téléphones android, boitier TV)
Histoire de pouvoir accéder au serveur depuis l'extérieur, j'ai un nom de domaine perso qui résout mon ip externe et pour ne pas avoir à bricoler la configuration sur chaque appareil en fonction du lieu, je fais du split DNS pour rediriger le nom de domaine vers l'IP interne du serveur quand je suis dans le réseau local.
Courant mars 2020, des erreurs bizarres apparaissent lors de la synchronisation des contacts ou des agendas. En cherchant un peu, on découvre que :
- IPv6 est activé sur mon réseau
- orange envoie ses propres DNS via les Router Advertisement (RA)
- ceux-ci résolvent mon domaine vers l'ip publique
- le NAT hairpinning ne marche plus (cf https://lafibre.info/orange-les-news/nat-forwarding-hairpinning/ par ex)
Résultat : suivant le DNS qu'elles interrogent mes machines ont du mal à trouver le serveur.
Solution initiale la plus simple : désactiver l'ipv6 et tout rentre dans l'ordre.
Mais ipv6, c'est le futur !(tm) Et la solution simple ne me plait qu'à moitié, j'ai donc cherché comment faire pour réactiver ipv6 et l'intégrer dans mon réseau. Et je suis tombé sur la délégation de préfixe qui permet de gérer soit même son pool d'adresse IPv6, excellent, et en plus la livebox le permet depuis 2022. Fantastique.
Je me dis, je vais déléguer le préfixe à mon serveur qui va alors fournir les infos aux différentes machines via dhcpv6/RA.
Sauf qu'en fait non,ça marche pas.
L'adresse du Router Advertisement est forcément celle du routeur (oui, ça parait logique dit comme ça) et si je délègue le préfixe à mon serveur c'est lui qui va être considéré comme un routeur, ce qu'il n'est pas.
Alors oui, ça doit peut être pouvoir se modifier en utilisant DHCPv6 mais, ce dernier n'est pas pris en charge par android. Celui-ci n'utilise que l'autoconfiguration (SLAAC) via les messages RA.
Petit retour en arrière pour ceux qui n'ont pas bien suivi le paragraphe précédent. Les adresses ipv6 sont fournies de plusieurs manières possibles :
- adresse fixe manuelle
- adresse autoconfigurée via le protocole SLAAC à partir des infos reçues du routeur (RA) et de l'adresse locale de l'interface réseau (ou d'un paramétrage de la machine)
- adresse fournie par DHCPv6
ex :
enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fdda:edfb:5546:0:2ef0:5dff:fe09:4e71/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 43133sec preferred_lft 1733sec
inet6 fe80::2ef0:5dff:fe09:4e71/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
La dernière partie de chacune des adresses est la même et correspond à celle du lien local (celle en fe80)
Conclusion : il faut une machine entre la livebox et mon réseau interne. Ce que j'ai mis en place en février 2024 (propulsée par l'excellent openwrt), en apprenant plein de choses au passage.
Qu'ai-je donc appris ?
1- les adresses en ipv6 c'est compliqué :
- à retenir, l'ipv4 c'est déjà pas évident, v6 c'est quasi impossible (et donc DNS quasi-nécessaire)
- il y a plein de type d'ip différentes et il est vital de les connaitre : https://www.ripe.net/media/documents/ipv6_reference_card.pdf
- si vous n'êtes pas à l'aise avec la notation CIDR (xxx/32), c'est le moment de s'y mettre
- les raccourcis d'adresse sont pratiques mais sont à apprendre également (par exemple ::1 signifie uniquement des 0 sauf le dernier nombre)
- les machines ont au minimum deux adresses et souvent plus voire beaucoup plus
2- il y a des pièges partout, ex :
- vous ne pouvez pas pinguer simplement une adresse lien locale, il faut ajouter l'interface (et la syntaxe est différente suivant les OS _o/)
- les adresses locales (ULA), sont censées être en fc00::/7 sauf qu'en fait, il ne faut pas utiliser la partie en fc00::/8 mais uniquement celle en fd00::/8
- certains services sur le grand nain ternet sont mal configurés et j'ai du forcer l'ipv4 dans certains cas (via une résolution locale sur mon DNS)
3- Il y a des limitations frustrantes (du protocole ou de l'implémentation) :
- Les limites d'android imposent d'avoir 2 services (RA + DHCPv6) si vous voulez également fixer des adresses pour des machines peu configurable (imprimante par ex)
- le préfixe délégué est censé être fixe. Chez mon FAI, il est stable, i.e. il change de temps en temps.
- le pare feu de la livebox pour la partie v6 est quasi inutilisable via l'interface, notamment, il ne permet pas facilement de saisir des adresses, il ne propose que celle du routeur. Je vous conseille donc de passer par LiveboxMonitor, logiciel tiers bien plus efficace.
- la livebox délègue un préfixe /56 mais en réalité, ne route que le premier /64 donc dans les faits, un seul /64 est disponible.
- un /64 représente 18446744073709551616 adresses. Mais il n'est pas possible de faire des sous-réseaux dedans sans casser les systèmes de configuration.
- les adresses ULA ont une priorité moindre que les adresses locales ipv4.
- les machines derrière mon accès VPN via wireguard ne peuvent pas avoir d'adresses globales (GUA) vu que le préfixe peut changer et que de toute façon je n'ai qu'un /64 disponible, donc ULA et NAT6 pour de l'ipv6 mais qui ne sert à pas grand chose vu que les adresses ipv4 sont préférées.
Au final, l'ipv6 est maintenant fonctionnel sur mon réseau, avec des adresses GUA et ULA et un serveur accessible depuis l'extérieur.
Un grand merci à Openwrt qui m'a énormément facilité la vie ; un gros morceau, dont la gestion de la délégation de préfixe, étant automagiquement configurée par l'OS sans rien avoir à faire.
Dans la vie de tous les jours, ça ne m'apporte rien si ce n'est la satisfaction personnelle d'avoir appris et réussi. Et un peu de frustration devant les limites arbitraires amenées principalement par les implémentations.
J'ai quand même gagné une magnifique couleur verte sur https://ip.lafibre.info/ ; et ça, ça en valait la peine.
# connectivité IPv6
Posté par Cyril Chaboisseau (Mastodon) . Évalué à 7.
Merci pour ce journal intéressant
Il existe quelques autres ressources pour tester sa connectivité :
http://conn.internet.nl/ (le lien en haut à droite permet de tester la connexion IPv6 et de valider le DNSQEC)
et
https://test-ipv6.com/
qui permet de gagner encore plus de pastilles vertes
…sans oublier la tortue qui danse du projet KAME
https://www.kame.net/
# Vieux con aigri
Posté par NYC . Évalué à 10.
Tu as aussi appris à monter une usine à gaz avec pas moins de trois machines différentes et des journées de boulot juste pour avoir un agenda et un carnet d’adresse que tu aurais plus vite fait de copier à la main.
# Freebox et RA
Posté par niol (site web personnel) . Évalué à 5.
Super intéressant.
A noter que la freebox que j'ai à la maison permet de personnaliser l'adresse du ou des serveurs DNS annoncés ce qui est plus simple que la délégation de préfixe et/ou la mise en place d'une machine en plus.
Par contre, je n'ai pas trouvé de solution pour associer un nom aux adresses ipv6 des machines peu configurables.
[^] # Re: Freebox et RA
Posté par AncalagonTotof . Évalué à 3.
Faudra que je regarde ce point. Mais j'ai un autre problème, avec une Freebox + FW Debian.
Autant je me débrouille en IPv4, autant je suis loin de tout piger en v6. La base, ça va, c'est pas trop complexe.
Ma config :
[Freebox en mode Brigde] <--> [Firewall machine a tout faire] <---> [LAN]Pas de soucis pour le FW, il sait causer IPv6 avec le monde extérieur (par exemple pendant un
apt-get update, les serveur Debian sont résolu en v6).Mais côté LAN, les machines n'ont qu'une IPv6 Link Local. Même avec un dhcpd v6 (peut-être mal configuré).
Je ne vais pas lister tout ce que j'ai essayé. Déjà, il faudrait que je m'en rappelle ou que je replonge dedans …
Mais je trouve bizarre de ne jamais avoir trouvé de tuto pour ce genre de config.
Après, quand j'y pense, je me dis que c'est peut-être pas plus mal que des machines du LAN ne soient pas accessible directement de l'extérieur (oui, je sais, un FW, ça se configure par défaut en "ferme tout, ouvre au cas par cas" et pas l'inverse …).
[^] # Re: Freebox et RA
Posté par par . Évalué à 5.
Je suis loin de maitriser IPv6, mais ça ressemble à un des problèmes que j'ai eu. Résolu en ajoutant dans la config ipv6 de la freebox, l'ipv6 du fw dans "nextHop". Note que dans mon cas, le fw était aussi un routeur.
[^] # Re: Freebox et RA
Posté par dr191 . Évalué à 3.
Salut,
Moi aussi dans cette config avec un openwrt derrière.
L'approche retenue:
- 1 er sous réseau sans next hop, utilisé par la freebox le ::1, et le ::2 pour le wan du routeur en statique.
- 2 et et 3 ème sous réseaux: délégués vers le openwrt, next hop = adresse de lien local du wan openwrt. Ces 2 réseaux sont propagés ( RA) vers le lan et le wifi invités.
Par contre j'ai pas creusé si c'était possible gérer cela dans le dns. Mon dns local ipv4/v6 pour le web qui est séparé du routeur se limite à de la résolution en ipv4 pour les machines du lan. Je doute que cela possible à minima sans regrouper le dns sur la passerelle openwrt si l'ipv6 est gérée en mode slaac.
# IPv6 en réseau local
Posté par gUI (Mastodon) . Évalué à 10.
En fait j'ai du mal à comprendre l'intérêt de l'IPv6 dans un réseau local. Qu'est-ce que IPv6 peut apporter que IPv4 n'a pas ? Si quelqu'un peut m'éclairer, merci d'avance !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: IPv6 en réseau local
Posté par barmic 🦦 . Évalué à 10.
Il me semble que le NAT pose pas mal de problème. D'une part il est couteux en ressources et d'autres part il rend les protocoles point à point compliqués. Au boulot ils adorent le NAT résultat, ils ont des situations où une machine peut envoyer un paquet à une autre, mais jamais recevoir ne serais-ce que l'ack TCP… Et quand ils se retrouvent obligé à faire de l'IPv6 c'est bien sûr avec un NAT64, on va pas corriger les problème qu'on garde depuis des années.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: IPv6 en réseau local
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Le fait d'avoir, sur chaque machine, une adresse IPv6 qui fonctionne. Pas une adresse privée cachée derrière l'adresse publique du routeur ou je ne sais quoi, non, une vraie adresse publique utilisable sur Internet, sur chaque machine connectée.
Communiquer avec une machine derrière le même NAT ? Problème inexistant, il n'y a pas de NAT. Reformulons donc. Communiquer avec une machine sur le même réseau local ? Pas de problème, on utilise son adresse IPv6 publique.
[^] # Re: IPv6 en réseau local
Posté par Philippe F (site web personnel) . Évalué à 2. Dernière modification le 19 avril 2024 à 23:30.
J'entends toujours cet argument, mais je ne saisis pas en quoi c'est un plus.
Parmi tous les trucs qui sont branchés sur mon réseau domestique, j'en ai un seul qui de temps en temps pourrait être adressé de l'extérieur. Tout le reste est bien mieux derrière un mur de flamme géré (sûrement imparfaitement) par ma box.
L'IPv6, c'est un peu comme inviter les gens à se téléporter directement chez toi sans passer par la porte d'entrée finalement. Et moi, j'aime pas trop faire rentrer n'importe qui…
[^] # Re: IPv6 en réseau local
Posté par jmiven . Évalué à 8.
Bah non, parce que ton pare-feu et ses règles par défaut n'ont pas disparu.
[^] # Re: IPv6 en réseau local
Posté par totof2000 . Évalué à 10. Dernière modification le 19 avril 2024 à 23:55.
Moi j'ai jamais compris ce genre d'argument : En quoi l'IPV6 empêche d'avoir un pare-feu ? Pour rappel, un pare-feu c'est un truc qui dit "j'empêche d'entrer ce qui vient de l'exterieur" ou "je n'autorise que ce qui vient de l'exterieur à aller à tel ou tel endroit". Tu peux parfaitement avoir un pare-feu qui ne laisse rien entrer, que ce soit en IPV4 ou en IPV6.
Mais ça n'a vraiment aucun rapport.
[^] # Re: IPv6 en réseau local
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Avec IPv4, par défaut, ton réseau domestique n'est pas joignable et il faut faire quelque chose pour exposer un élément. (NAT, PAT, etc)
Avec IPv6, par défaut, ton réseau domestique et joignable et il faut faire quelque chose pour cacher un élément. (firewall)
C'est une description très naïve, j'imagine (j'espère) bien que la plupart des équipements bloque le trafic entrant à destination des réseaux domestiques, mais ça n'est quand même pas la même philosophie, et je comprends que certains ne le voient pas d'un très bon œil.
[^] # Re: IPv6 en réseau local
Posté par barmic 🦦 . Évalué à 8.
En IPv4 tu ne peux pas exposer quoique ce soit. Si tu as la chance de n'avoir qu'un seul niveau de NAT, tu peux hacker pour arriver à tes fins mais c'est tout.
En pratique c'est faux. Ta box a son firewall par défaut. Parler de fonctionnement par défaut théorique plutôt que pratique montre des problèmes théoriques plutôt que pratiques.
C'est la philosophie d'internet, hein ? Le NAT est un accident et cette façon de séparer les serveurs dans un petit nombre de d'entreprises des clients chez les particuliers rapproche beaucoup plus internet du fonctionnement du Minitel qu'on ne le crois, philosophiquement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: IPv6 en réseau local
Posté par Yth (Mastodon) . Évalué à 4.
Pas tout à fait.
Parce que la notion de réseau local est là depuis à peu près le début.
Sans parler du NAT, qui là est bien un hack pour repousser les murs.
Un réseau local, avec une passerelle et par exemple un proxy HTTP ou SOCKS5 pour accéder au web.
En fait c'est même très clairement ce qu'essaient de reproduire beaucoup d'entreprises aujourd'hui, mais avec le télétravail, donc un VPN : tu accèdes au web via le proxy, mais tu n'es pas sur internet, surtout pas, et tu accèdes aux machines du réseau local (ie le VPN, mais pas le réseau local de ta maison !) qui ne sont pas sur internet non plus.
Ipv6 avec des IP publiques pour tous, ce n'est pas du tout la philosophie.
IPv6 peut-être (mais non nécessaire en réalité ici), mais avec toujours des notions de réseau local, et de passerelle pour accéder à certains services sur internet, et des machines qui ne sont pas, n'ont jamais été, et ne devront jamais être exposées ou exposables sur internet.
Ce qui est un hack c'est l'inverse, c'est de vouloir avoir tout un sous-réseau qui soit lui-même entièrement sur internet, mais de ne faire ça qu'avec une seule IP publique.
IPv6 répond à une problématique, et c'est celle de faire un sous-réseau d'internet.
Donc qui fasse partie intégrante d'internet, mais qui reste un sous-réseau parce qu'il y a un goulet, typiquement la connexion internet.
Ce n'est absolument pas la seule façon d'imaginer la topologie d'internet, et il n'a jamais été question que toute machine soit directement sur le réseau.
PS: Pour être précis, IPv6 répond aussi à une autre problématique qu'on pourrait appeler la multiplication des sous-réseaux. Parce que même si on considère qu'une connexion = une adresse IP, on en manque, et c'est d'ailleurs sur cet unique point qu'on tente de pousser IPv6 pour remplacer IPv4.
Alors que l'argument devrait (pourrait au moins) être aussi topologique.
[^] # Re: IPv6 en réseau local
Posté par khertan . Évalué à 1.
Pas tout à fait, chez free et sfr (certain model de box, pas toutes) le firewall est désactivé sur ipc6 par défaut.
[^] # Re: IPv6 en réseau local
Posté par totof2000 . Évalué à 4.
Avec IPV4 tu n'as pas besoin de NAT pour empêcher tes ip de ton réseau local d'être joignables : il suffit de leur attribuer des adresses non routables ( extrait de https://fr.wikibooks.org/wiki/R%C3%A9seaux_TCP/IP/Adressage_IP_v4 ) :
Adresses privées (non routables sur l'Internet):
Un certain nombre de ces adresses IP sont réservées pour un usage interne aux entreprises (RFC 1918[3]) Elles ne doivent pas être utilisées sur l'internet où elles ne seront de toute façon pas routées. Il s’agit des adresses :
de 10.0.0.0 à 10.255.255.255
de 172.16.0.0 à 172.31.255.255
de 192.168.0.0 à 192.168.255.255
les adresses de 127.0.0.0 à 127.255.255.255 sont également interdites.
(fin de citation).
Une machine dans ces plages IP ne sera donc pas accessible depuis l'exterieur parce que :
Il existe également des adresses non routables en IPV6.
[^] # Re: IPv6 en réseau local
Posté par totof2000 . Évalué à 3.
Maintenant, comment faire pour donner accès à internet à une machine qui a une IP non routable ? C'est simple : on utilise un proxy qui lui aura une IP routable dans une plage réseau dédiée. C'est lui qui relaiera les paquets vers "le méchant ninternet"
Qelle est la différence avec le NAT ? Vu de loin il n'y en a ps beaucoup, du point de vue du trafic sortant. On a une machine (proxy) qui fait une sorte de translation d'adresse. Par contre c'est pour le trafic entrant que ça devient intéressant : chaque élément devant acueillir du trafic de l'extérieur peut avoir une IP qui écoute sur des ports standards : pas besoin de jongler avec une seule IP qui passerait par plusieurs ports (port 2221 pour la machine 1 en ssh, port 2222 pour la machine 2 en ssh, port 8443 pour l'accès a la caméra 1, port 8444 pour l'accès à la caméra 2, etc ….). Si tu as plusieurs service web en écoute en ssh, tu les fais tous écouter sur le port stndard (443), et la vie est plus simple.
[^] # Re: IPv6 en réseau local
Posté par Astaoth . Évalué à 1. Dernière modification le 23 avril 2024 à 01:04.
Je ferais plutôt une entrée firewall dédiée à ca, en ipv6 comme en ipv4 (avec un nat en plus si besoin est). Les proxy web sont beaucoup moins intéressants qu'ils en ont l'air :
- C'est de la configuration client, rien n'empêche un client de ne pas utiliser de proxy pour faire ses requêtes, à par les règles du firewall réseau
- Au niveau des logs firewall, l'origine des flux visible est le proxy et non le client réel. Ca masque une partie des infos et rend pénible le débug ou l'analyse de flux
- Faut un proxy qui tienne la charge pour pas devenir un goulot d'étranglement. Ce problème s'applique aussi au firewall, mais il n'est pas vraiment utile de les multiplier dans le LAN, il y en a déjà assez dans le WAN.
- Leur plus gros usage en entreprise, c'est les règles de sécurités, qui servent en gros à filtrer des catégories de domaines. Déjà les URL ne sont pas toujours catégorisées de facon cohérentes, même sur de grosses solutions, d'autres part en télétravail, soit y a pas de VPN et donc pas de proxy obligatoire (un client peut toujours désactiver la conf proxy), soit il a un VPN, qui souvent a un beau split-tunnel configuré/configurable par le client pour le trafic web, et donc faire comme si il n'y avait pas de VPN.
En fait, les proxy web sont intéressants surtout dans certains cas particuliers.
Emacs le fait depuis 30 ans.
[^] # Re: IPv6 en réseau local
Posté par totof2000 . Évalué à 2.
S'il a une IP non routable, ses paquets iront nulle part.
mais je serais également partisan du "ceinture bretelle" et mettrai en place des règles de firewall.
ça peut être effectivement un problème, mais moins gênant qu'on ne le croit.
celà dit avec une solution de centralisation de logs (ELK), on peut tout avoir à un seul endroit.
Ils sont intéressant dans un réseau domestique pour mettre en place un contrôle parental. Et le proxy, il peut aussi jouer le rôle de cache pour optimiser le débit lorsque tu as du monde qui accède au net. Le proxy peut être intéressant pour que les personnes qui ne veulent pas connecter directement leurs machines au net.
[^] # Re: IPv6 en réseau local
Posté par nud . Évalué à 6.
C'est parce que tu identifies mal ce qui doit être accédé depuis l'extérieur. Le NAT est un emmerdement pour toute communication peer-to-peer et la raison pour laquelle la plupart des systèmes de chat, voix ou conférence vidéo a besoin de STUN/ICE et souvent d'un relai sur un serveur distant, sinon ça marche vite pas si tu as plusieurs participants derrière le même NAT et autres cas du même genre. Pas besoin non plus d'UPNP, de keepalive, etc.
Avec IPv6 point d'ennui, tu peux juste faire du peer-to-peer sans te poser de questions.
Accéder directement à un "truc" ça ne concerne pas que les serveurs.
Par contre, effectivement, la contrepartie c'est que n'importe qui peut accéder à n'importe quel port de n'importe quelle machine interne pourvu qu'il ou elle en connaisse l'IP. En pratique ce n'est pas si trivial car scanner un /64 en IPv6 ce n'est pas la même chose que scanner un /24 mais un serveur malveillant pourrait théoriquement scanner les ports de ton PC à distance et essayer de se connecter en ssh par exemple. Après, c'est aussi le cas avec IPv4 sur les téléphones quand tu n'es pas derrière un CGNat. Mais oui, un firewall, du coup, c'est pas une mauvaise idée.
[^] # Re: IPv6 en réseau local
Posté par Psychofox (Mastodon) . Évalué à 6.
Tu confonds nat et pare-feux.
[^] # Re: IPv6 en réseau local
Posté par flagos . Évalué à 4.
L'adressage unique réseau local/exterieur ?
# Si seul IPv6 existait...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 18 avril 2024 à 08:07.
…il n'y aurait pas de configuration de split DNS, de NAT, d'adresse IP publique donnée uniquement à ton routeur.
Toutes les machines auraient au moins 1 adresse IP publique, voire même un préfixe de quelques centaines d'adresses.
Si un serveur a plusieurs centaines d'adresses, il n'y a même plus besoin de configurer de "virtual hosts" dans Apache et chaque conteneur/machine virtuelle peut avoir sa connexion SSH en direct sur le port 22.
La configuration du réseau serait bien plus simple, car il n'y a pas à gérer de réseaux virtuels, d'adresses privées, de NAT… Et toute la sécurité se baserait sur les firewalls qui peuvent être installés à plusieurs endroits du réseau. Leur configuration serait simplifiée, car il n'y a plus que des vrais adresses et pas de NAT.
Mais voilà, on préfère faire comme on a appris avec IPv4 et tous les outils de contournement de problèmes liés à cette technologie. Car on a appris comme ça il y a des dizaines d'années, car les FAI n'ont pas envie de délivrer de l'Internet moderne et car les logiciels n'ont pas intégré IPv6 (par exemple dans leurs systèmes de modération).
[^] # Re: Si seul IPv6 existait...
Posté par Jean Gabes (site web personnel) . Évalué à 8.
IPV6 gagnera quand il résolvera un vrai problème pour la masse des personnes, ou bien qu'il sera intégré de manière triviale et totalement transparente. On en est loin, très loin.
C'est bien toute la différence entre la théorie et la pratique pour une techno. Le seul espoir pour IPV6 c'est qu'on touche pour de vrai (avec des $$ derrière) la fin du nombre d'IPV4. Il est là depuis trop longtemps que si juste techniquement il était meilleur alors il aurait gagné.
Il a juste trop de défaut de migration, cette partie là a clairement été sacrifiée lors de sa conception. On se retrouve avec un changement bigbang sur une couche critique et peu lisible pour la majorité des personnes.
[^] # Re: Si seul IPv6 existait...
Posté par jyes . Évalué à 10. Dernière modification le 18 avril 2024 à 10:19.
IPv6 résout énormément de problèmes et est techniquement meilleur, il n’y a aucun doute là dessus. D’ailleurs, les problèmes relevés dans ce journal ne se poseraient pas en IPv6 seul correctement déployé. Toutes les machines peuvent avoir une IP globale, donc un enregistrement DNS, et la box n’a plus qu’à faire pare-feu. Et pour un non-informaticien comme moi, IPv6 est bien plus lisible que IPv4 !
Les problèmes (réels) que pose IPv6, c’est que les opérateurs de réseaux travaillent comme des sagouins et sont attachés à leur infrastructure historique en IPv4, donc qu’il faut, même avec un IPv6 fonctionnel, continuer à maintenir des NAT, des DNS locaux et autres ignominies qu’impose IPv4, ce qui limite drastiquement les simplifications que pourrait offrir IPv6. On peut ajouter à ça des pratiques héritées d‘IPv4 comme l’adresse « stable » mais pas fixe citée dans le journal, qui ne font que mettre des barrières arbitraires au bon fonctionnement d’IPv6, pour la seule raison que les opérateurs s’en foutent et se satisfont de mettre tous leurs clients derrière un NAT et une poignées d’IPv4 partagées par tout le monde. Et malheureusement, tant que les clients s’en satisfont aussi, même quand il y aura 1000 fois plus de machines que d’adresses IPv4 sur le réseau, le réseau IPv4 survivra pourvu que Facebook et Google aient une IPv4 publique.
Le côté « IPv6 n’a pas d’avantage concret avec des brouzoufs à la clé » est bien une vision occidentale où l’on ressent moins le manque d’IPv4. Ce n’est pas pour l’élégance technophile que l‘Inde développe son adoption. En France, on a de la chance que l’ARCEP pousse un peu les opérateurs qui se trouvent forcés d’être parmi les moins mauvais élèves, mais ça ne met pas la barre très haut.
Donc pour reprendre ta phrase dans les désordre « IPV6 [aurait dû] gagner[ car] il réso[ut] un vrai problème pour la masse des personnes[…]. On en est loin, très loin [car] il [est] intégré de manière [lamentable] et totalement [opaque par des acteurs du réseau qui abusent de leur poids historique] ».
[^] # Re: Si seul IPv6 existait...
Posté par Renault (site web personnel) . Évalué à 7.
La France semble être le pays de référence en terme d'adoption de l'IPv6 au niveau mondial (du moins d'après les chiffres de Google : https://www.google.com/intl/en/ipv6/statistics.html). Même devant l'Inde.
Cela a longtemps été la Belgique grâce au travail assez important de l'opérateur historique Proximus au début des années 2010, mais comme les autres opérateurs ne suivent pas cela stagne.
En tout cas l'IPv6 fonctionne bien quand l'ensemble de l'infrastructure et des logiciels sont compatibles. Je ne sais pas où en sont les réseaux mobiles mais niveau système d'exploitation il y a eu des efforts dessus et ce n'est plus le point bloquant depuis quelques temps.
[^] # Re: Si seul IPv6 existait...
Posté par jyes . Évalué à 5.
C’est variable, mais ça progresse assez vite : les baromètres de l’Arcep permettent de s’en rendre compte. Personnellement, avec mon abonnement mobile chez SFR et un téléphone Android, IPv6 n’est pas activé par défaut, mais en l’activant manuellement cela fonctionne parfaitement (je n’ai évidemment pas vérifier en me promenant pour couvrir toute la carte de France, donc il y a sûrement des malchanceux qui ont une expérience différente). J’auto-héberge quelques petits trucs en IPv6-only, et je peux les utiliser sans soucis via ma connexion mobile (je dois même faire du partage de connexion depuis mon téléphone pour y accéder au boulot).
[^] # Re: Si seul IPv6 existait...
Posté par Elfir3 . Évalué à 5.
Pourtant chez moi la fibre via EDPNet acquiert un 10/10 sur test-ipv6.com, ce qui n'est pas le cas de ma connexion mobile via Proximus se vautre lamentablement avec un 1/10.
[^] # Re: Si seul IPv6 existait...
Posté par Renault (site web personnel) . Évalué à 4.
Je suis chez EDPNet et j'ai été chez Proximus (mais non fibré pour les deux) ça semblait marcher tout aussi bien.
Faut dire que EDPnet utilise l'infrastructure de Proximus en partie donc ça n'a rien d'anormal. Et les chiffres de Google montrent bien que 60% des Belges peuvent utiliser l'IPv6 pour les services de Google ce qui reste élevé à l'échelle mondiale.
[^] # Re: Si seul IPv6 existait...
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 18 avril 2024 à 11:59.
IPv6 fonctionnait chez SFR sans souci particulier il y a 10 ans (c’était peut-être le seul truc qui fonctionnait bien chez eux…) ; ça fonctionne aussi très bien sur le réseau Orange depuis au moins 6 ans, par contre la Livebox a des limitations bien pénibles.
Par contre si tu es une entreprise ça devient la grosse merde. En 2020 (j’ai pas d’info plus récente), Orange Pro ne permettait pas d’avoir IPv6 (alors que c’était activé par défaut chez les particuliers), il fallait impérativement passer par Orange Business Services (et c’est pas les mêmes prix).
Les stores d’applications mobiles imposent une compatibilité IPv6 depuis une dizaine d’années, je dirais – même si je ne sais pas si c’est vérifié en pratique.
Le mieux avec IPv6, c’est qu’on peut faire passer des messages dans son IP.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si seul IPv6 existait...
Posté par Zenitram (site web personnel) . Évalué à 7.
Admettons. Mais à part étendre la quantité d'adresses, ça apporte quoi?
Parce que si c'était juste ça comme avantage, ils ont fait vachement compliqué (la spec est plus que "bon on passe la largeur de l'adresse de 32 à 64 bits") ce qui est limite son déploiement, donc contre-productif.
Et la, ben… Dans la vraie vie, pas encore trouvé à ma connaissance (IPv4 c'est quand même un truc qui a montré sa résilience, et même avec des milliards de gens ça va on a le partage de ports etc), d'où la non motivation de tout le monde (pas d’intérêt économique en pratique).
PS : IPv6 est tellement "utile" qu'un site de geeks comme LinuxFr n'a pas encore été assez motivé à y passer, ça en dit aussi pas mal sur la réalité de l'utilité.
[^] # Re: Si seul IPv6 existait...
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Cherche pas, on va te dire que si c'est utile, comme ça leur pc interne peut avoir une ip publique, et que ça va tout changer, que c'est facile (pour les ingé réseau) à configurer.
Moi je vois bien madame Michu être contente que son pc puisse être scanné car elle a oublié de cocher le "mur de feu" sur sa box. Ça c'est sûr elle va être contente.
Blague à part, non, cette techno tellement bien qu'après 25ans (j'insiste: 25ans) n'est toujours pas en place car il n'y a aucun intérêt économique. Il a fallu 5 fois moins de temps pour que les applications (donc soucis un peu plus divers et variés que le réseau au niveau IP et avec plus d'interlocuteurs dans la boucle à problèmes) passent de VM à des conteneurs gérés via de la seule configuration, car là oui, là il y avait un intérêt économique.
Windows a genre 75% de part de marché, mais non, on entend encore que ce sont les qualités techniques qui sont importantes et qui font un succès. Je n'aime pas plus le fait que ce soit faux. Mais non. C'est juste, et uniquement, l'intérêt économique et d'intérêt par les utilisateurs qui prime. Et ça IPV6 est très mal armé sur ces deux points.
[^] # Re: Si seul IPv6 existait...
Posté par Renault (site web personnel) . Évalué à 10. Dernière modification le 18 avril 2024 à 14:47.
Mouais, je pense que pour dire ça tu ne réalises pas à quel point changer un composant comme IP n'est pas trivial.
Le soucis d'IPv6 c'est l'effet "réseau" qui nécessite que beaucoup de services et de matériels soient compatibles avant de pouvoir faire quoique ce soit.
Les OS doivent bien le gérer, les applications sur l'OS aussi, le tout côté serveur, client mais aussi sur les équipements intermédiaires. Tous les équipements intermédiaires. Mine de rien c'était loin d'être acquis avant 2010 juste ces points là. Un élément de la chaine pas compatible, IPv4 reste nécessaire.
Ensuite il y a toute la formation, les connaissances, architectures et outils qui reposent sur de l'IPv4 qu'il faut migrer. Pas trivial non plus.
C'est bien plus complexe que de passer de VM à conteneur car globalement cela n'affecte que peu d'acteurs à la fois et tu as bien souvent un contrôle entier sur ces éléments. Si ma boîte veut passer de VMware à Docker pour des services, elle peut le faire toute seule sans attendre le reste du monde. Pour l'IPv6 tout le monde doit avancer ensemble et de nombreuses marches n'étaient pas prêtes avant 2010. Et évidemment il y a de l’inertie à tous les niveaux.
On voit le même problème dans les télécoms, l'ADSL c'est naze, les communications RTC aussi, la 2G également, pourtant ils sont encore là et bien déployés et décider de les couper prend beaucoup de temps pour des raisons similaires.
[^] # Re: Si seul IPv6 existait...
Posté par Jean Gabes (site web personnel) . Évalué à -2.
Je pense justement l'inverse: la partie réseau tu as certes à voir avec des prestataires (pas trivial je suis d'accord), mais tu n'as que l'infra qui va être impacté, alors que le changement vm->conteneur tu embarque l'infra, les dev et les responsables projets. Et là c'est autrement plus complexe je trouve.
Après ça dépends peu être des échelles, j'imagine qu'un IPV6 chez un opérateur tel c'est pas la même histoire, car là ça touche au business, et ça devient defacto complexe.
Mais de mon point de vue, dès que tu as dans la boucle des responsables de projet, tu sais que tu as intérêt à avoir de sacré argument ($$) pour faire bouger le tout :)
[^] # Re: Si seul IPv6 existait...
Posté par Renault (site web personnel) . Évalué à 10.
Mais as-tu une idée de la complexité d'un réseau télécom ? Du nombre de composants qu'il y a ? Du nombre de fournisseurs impliqués à l'échelle d'un pays ? De l'importance de la rétro compatibilité pour ne rien casser (déjà qu'il y a pas mal de fragilités) ? Ce n'est vraiment pas trivial du tout de faire évoluer tout ça.
Cela implique de tout tester et en douceur, ça se fait, mais ça prend du temps et il faut mettre des ressources dessus pendant longtemps.
Ces personnes sont probablement dans la même boîte voire quelques unes pour les grosses infras. Cela peut faire du monde mais c'est vite gérable. Et c'est bien plus facile à isoler (passer progressivement certains services d'un mode à un autre).
Pour un réseau télécom national tu as potentiellement des dizaines voire centaines d'entreprises impliquées dans toutes les étapes du coeur du réseau. Ce n'est vraiment pas la même histoire du tout. Et remplacer le matériel quand c'est nécessaire ça prend aussi du temps.
[^] # Re: Si seul IPv6 existait...
Posté par totof2000 . Évalué à 10.
Je crois que ça ne sert à rien d'expliquer : pour ma part je ne suis pas un expert réseau, mais j'ai eu l'occasion de travailler pour des opérateurs (fibre, hertzien/satellite, ou même certains des 4 principaux opérateurs français, et je n'ai eu qu'un petit aperçu de ce que c'est.
Quand je lis ça d'une part ça me fait rire (Mme Michu ne coche jamais rien sur sa box, elle prend les options par défaut, et par défaut le "mur du feu" est fermé si les fournisseurs font bien leur job en amont - pous sa machine, aujourd'hui, elle est fournie avec un "mur du feu" préinstallé et préconfiguré), mais d'autre part ça me désespère - parce que c'est ce genre de raisonnement qui fait qu'on avance pas sur l'adoption d'IPV6 ( on croirait lire des nostalgiques du minitel).
IPV6, c'est un peu comme la disparition de transpac/x25, mais à l'échelle mondiale. Normal que ça prenne beaucoup de temps? Et en plus de ça je pense qu'il y a derrière un business lié à la fourniture d'IPV4 qui doit être lucratif pour certains. Mais quand ces fameuses IP seront effectivement devenues très chères, ou que le bricolage permettant de continuer à utiliser IPV4 deviendra plus cher à maintenir que ce qu'il apporte, ça changera (et l'IOT permettra peut-être, en raison de son grand besoin d'IP, d'accélérer la transition).
Moi perso ce que je reproche à IPV6, c'est que les FAI n'accordent qu'un /64. Pour moi c'est une grosse erreur : un particulier devrait pouvoir sectionner son réseau ( tous les trucs connectés à l'exterieur devraient être séparés des PC/nas/etc .. qui eux ne devraient pas être accessibles de l'exterieur. Une DMZ quoi).
[^] # Re: Si seul IPv6 existait...
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
En fait au moins Orange et SFR accordent un /56 mais je n'ai jamais essayé d'utiliser autre chose que le /64 de base.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si seul IPv6 existait...
Posté par nud . Évalué à 3.
Chez Proximus on reçoit un /56 et je n'utilise pas le premier /64 (probablement par pur esprit de contrariété)
[^] # Re: Si seul IPv6 existait...
Posté par flagos . Évalué à 4.
Ça a déjà change. En Suisse, la plupart des opérateurs ne donnent plus d'ipv4, officiellement pour raisons de coûts. Dans mon cas, j’accède a ipv4 via DS-lite mais en natif je n'ai que de l'ipv6.
Il me semble qu'aux US c'est une config assez courante.
[^] # Re: Si seul IPv6 existait...
Posté par barmic 🦦 . Évalué à 3.
Ça aurait du sens si IPv6 était sorti cette année, mais ce n'est pas le cas. Beaucoup de ce qui existe aujourd'hui n'existait pas en 98. Le réseau dont tu parle est infiniment plus complexe aujourd'hui qu'il y a 25 ans. Il y a 25 ans il y avait beaucoup moins de monde connecté et le réseau n'était pas aussi critique, tout ne reposait pas dessus comme aujourd'hui. Tu avais des pays entier qui n'étaient presque pas relié (au hasard la Chine et l'Inde).
C'est le principe de la dette technique, elle ne s'évapore pas, elle s’accroît.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si seul IPv6 existait...
Posté par totof2000 . Évalué à 5.
Hum … quand je lis ça … ç me fait doucement rire, surtout de la part de quelqu'un qui reproche souvent la "résistance au changement".
# Adieu split dns
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 9.
J'ai abandonné le split dns il y a quelque temps. Trop pénible en maintenance.
Une solution beaucoup plus propre est de router à l'intérieur du réseau local les adresses publiques directement vers la bonne machine.
Pour l'ipv4, ma box permet par chance d'ajouter une route.
Pour l'ipv6, c'est le serveur qui envoie sa route directement sur le réseau local avec router advertisment. Il est possible d'annoncer une route sans annoncer de route par défaut ni de préfixe d'auto-configuration (qui eux sont annoncés par la box).
Avec systemd-networkd c'est la directive RouterLifetimeSec=0 qui permet ça.
Ça évite pas mal de configuration et surtout ça évite un routeur intermédiaire.
# ipv6 et auto-hébergement
Posté par err404 (site web personnel) . Évalué à 5. Dernière modification le 18 avril 2024 à 09:30.
Si on souhaite héberger des serveurs ou des services à la maison, l'ipv6 apporte le maximum de simplicité puisque chaque machine physique ou virtuelle aura la possibilité d'avoir une ip publique distincte et avec tous les ports disponibles.
Alors qu'en ipv4, on ne dispose en général que d'une seule ip publique, il faut donc faire du NAT, il faut aussi ajouter et configurer un reverse proxy SNI, et il y a souvent de nombreux ports qui sont réservés par la box de l'opérateur.
L'ipv4 reste pratique dans un vpn ou un réseau local, mais ça s'arrête là.
Les personnes qui n'aiment pas l'ipv6, c'est parce qu'elles continuent de penser que l'ipv6 est seulement une extension de l'ipv4.
ipv4 et ipv6 sont deux protocoles DIFFÉRENTS, il faut arrêter de vouloir calquer l'un sur lautre.
[^] # Re: ipv6 et auto-hébergement
Posté par Faya . Évalué à 5.
Bin disons que ça fait quelques décennies que le monde tourne sur ipv4 et ça semble encore fonctionner… Donc "ça s'arrête là" je sais pas… Là tout de suite en 4G mon téléphone a une ipv4 mais pas de v6. Donc si je dois monter un serveur qui doit être contacté par de vraies personnes depuis des appareils et des réseaux divers et variés, je vais d'abord me concentrer sur la connectivité ipv4. Sorry not sorry.
# Suggestion: virer l'IPv4
Posté par Xebrok . Évalué à 8.
C'est très intéressant, car confronté aux mêmes soucis, j'ai suivi le même chemin, à savoir routeur OpenWrt installé derrière la Livebox avec délégation de préfixe, et accès de l'extérieur par VPN Wireguard.
Pour accéder aux adresses IPv4 Internet, je passe par un couple DNS64 + NAT64.
Le DNS64 synthétise des enregistrements AAAA (IPv6) pour les requêtes DNS ne renvoyant qu'un enregistrement A (IPv4).
Le NAT64 transforme l'adresse IPv6 synthétisée en une adresse IPv4 réelle, envoyée à la Livebox.
Pour tester, j'ai viré l'IPv4 sur mon PC, et je fonctionne ainsi depuis 3 mois déjà.
Il existe sans doute quelques services bien particuliers qui ne fonctionnent pas, mais pour l'instant, c'est nickel.
Je vais sans doute activer l'option 108 dans le DHCPv4 du LAN, les clients compatibles IPv6 ne demanderont plus d'adresse IPv4.
[^] # Re: Suggestion: virer l'IPv4
Posté par Mjules (site web personnel) . Évalué à 2.
J'y ai pensé aussi mais pour le moment, j'ai encore des périphériques qui ne gère par ipv6, une imprimante/scanner en particulier donc je suis obligé de garder a minima une double pile si je ne veux pas me lancer dans des trucs complexes.
# Je ne comprends pas
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Je ne comprends pas, vraiment.
Ce que je comprends, c'est que comme tu héberges tes services, tu te retrouves, comme tout le monde, avec un problème d'accès depuis le réseau local, à ton serveur qui est derrière le même NAT. Problème très classique, auquel il existe trois solutions connues :
Si je comprends bien donc, tu avais IPv6 activé. Du coup, je ne comprends pas en quoi le cassage du NAT hairpinning change quoi que ce soit. En effet, dans ce genre de cas :
Donc, où était le problème au juste ? Je ne doute pas qu'il y avait un problème, mais ce que je trouve très bizarre, c'est qu'IPv6 est normalement une solution à ce genre de problème, pas une cause !
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 7.
Chez mi le problème se présente comme ça :
Ma conf est Ipv4 depuis longtemps, et le DHCP local fournit un DNS local, qui résout les adresses locale avec des IPs locale, y compris le nom de domaine extérieur.
C'est donc un DNS menteur, puisque sur les noms de domaines publics, il retourne de IP locales.
Et il n'y a aucun DHCP IPv6.
Mais je n'ai jamais déconfiguré explicitement l'IPv6 sur ma machine.
Et là à un moment, il s'est mis à obtenir une IPv6, qui vient apparemment de la box donc, et un DNS IPv6, qui n'est pas à moi.
Et là c'est dans le /etc/resolv.conf local de ma machine, généré par le DHCP, qu'une IPv6 est apparue en haut.
Et la résolution de nom passe par ce premier résolveur IPv6.
Et donc pas par mon DNS menteur interne.
Pif, ça marche plus.
Et là, le côté où t'as jamais activé ça sur ta box, mais tu as quand même un DHCP et un DNS IPv6 qui viennent se mettre en premier, ça casse un brin les bouts des pieds.
La solution pourrait être de configurer proprement un DHCP IPv6 avec un DNS menteur local, mais comment être bien sûr que l'autre qui vient de chaipahoù ne continue pas de mettre le bazar ?
De toute façon, la solution serait que je me renseigne - enfin - sur comment ça fonctionne vraiment, et de faire les choses proprement.
La solution facile c'est de bien dire à la machine de ne pas se fouler avec l'IPv6, c'est non.
C'est une bonne première solution, parce qu'il semble hors de question de basculer sur de l'IPv6 sans faire les choses correctement.
Et là paf.
Paf = ben ça marche, alors on touche à rien, donc pas d'IPv6, parce que c'est des efforts, et qu'à choisir entre jouer à kingdomino avec mes mômes et se coltiner de la doc IPv6, ben la technique a perdu…
[^] # Re: Je ne comprends pas
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
La façon propre de faire, c'est de publier, dans le DNS, l'adresse IPv6, forcément publique, de ton serveur. Pas besoin de DNS menteur en IPv6, ton serveur n'a qu'une adresse et elle est utilisable depuis Internet et depuis ton réseau.
Le coup du serveur dans le même réseau local que le client, comme je disais, ça a trois solutions. Deux sont compliquées, le DNS menteur et le NAT hairpinning. Et une est simple : IPv6.
Pour le résolveur ajouté par ton routeur, ça vient d'une option qu'il envoie lorsqu'il annonce son préfix IPv6. Côté client, tu as un logiciel qui tranpose ça dans
/etc/resolv.conf, et ce logiciel, tu dois pouvoir le désactiver.[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 2.
Oui, pardon, tu as raison, j'ai écrit un peu vite, en IPv6, pas besoin de DNS menteur, juste un DNS local pour les noms locaux.
[^] # Re: Je ne comprends pas
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu veux dire juste un DNS pour les noms ? Je ne vois pas ce que le mot local vient faire là-dedans, en fait.
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 4.
Le DNS du réseau local pour les noms du réseau local.
N'ayant pas vocation à servir en dehors de ce réseau local.
J'aime bien accéder à mes machines locale, localement, via des petits noms.
Ces noms n'ont pas de sens en dehors du réseau, et je ne vais certainement pas les mettre directement dans un DNS internet pour qu'un éventuel attaquant n'ait plus à scanner mon /56, mais ait directement toutes les IPv6 pertinentes.
Donc même en IPv6, il y a utilité d'un DNS local pour les noms locaux.
Ça peut se gérer avec un fichier /etc/hosts, mais il faut le déployer partout, c'est plus simple avec un DNS.
Tu mets dnsmasq, comme ça tu as ton cache DNS local, avec tes noms locaux.
Je ne vois pas ce qui te gène dans mon utilisation de local ?
Le local network, il peut être interne et NATé en IPv4, ou public en IPv6, c'est le même, c'est ce qui est derrière la connexion internet, derrière le firewall, derrière la box, chez moi.
Et je veux faire « ssh miaou » quand je suis chez moi, mais que ça n'ait aucun sens hors de chez moi.
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Soit la machine a vocation à être accessible de l'extérieur, et dans ce cas c'est utile qu'elle ait une entrée DNS publique.
Soit elle n'a pas vocation à être accessible de l'extérieur et dans ce cas le pare-feu bloque les connexions. Une entrée DNS ne baissera pas la sécurité.
Dans tous les cas :
Ne pas publier de DNS pour ne pas configurer un pare-feu est une mauvaise idée.
Sauf erreur, il n'est pas possible de récupérer la liste des entrées DNS d'un domaine. Il faut déjà connaître le nom de machine pour obtenir l'ip.
Il ne semble pas y avoir d'intérêt à avoir un DNS utilisable uniquement de l'intérieur.
Il existe mdns si tu ne veux pas configurer de DNS.
[^] # Re: Je ne comprends pas
Posté par Misc (site web personnel) . Évalué à 5.
Ça dépends, tu peux pas choper le DNS, mais tu peux regarder la liste des certificats publiques. Donc par exemple, tu peux voir si tu as mis un serveur smtps, un site web (avec une appli de ton choix), etc.
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Comment peut-on récupérer la liste des certficats ?
[^] # Re: Je ne comprends pas
Posté par jnanar (site web personnel) . Évalué à 4.
Ici par exemple: https://crt.sh/?q=linuxfr.org
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Merci pour le lien. Tu sais comment ils font pour récupérer la liste ?
On est d'accord cependant que ça n'a pas de lien avec le débat de départ, qui est de savoir si publier un enregistrement dns vers une machine injoignable permet à un attaquant de récupérer l'adresse ip ? Ou j'ai raté quelque chose ?
[^] # Re: Je ne comprends pas
Posté par Misc (site web personnel) . Évalué à 4.
C'est publié par les boites qui signent les certificats (voir https://letsencrypt.org/docs/ct-logs/ et https://certificate.transparency.dev/logs/ ) dans le but de voir si quelqu'un enregistre ton nom de domaine sans ton autorisation, etc, etc.
Et mon point est qu'il y a parfois d'autres moyens de savoir ce qui existe qu'un transfert/bruteforce DNS.
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Merci pour ta réponse j'ai appris quelque chose.
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 4.
Et moi, bah je ne vois pas l'intérêt de configurer chez mon fournisseur de nom de domaine pcdusalon.mamaison.xyz, alors qu'un bête dnsmasq avec un fichier /etc/hosts va faire l'affaire, à la fois pour le DHCPD, et le nom de domaine.
Quand pcdusalon se connecte au DHCP, fourni par dnsmasq, ce dernier regarde dans sa table l'IP à lui fournir, et est capable de répondre avec cette même IP à une requête DNS.
Ne pas le faire en local signifierait de devoir configurer ça à deux endroits différents, v'là la prise de tête, et la complexité.
J'ai un fichier /etc/ethers qui associe une adresse MAC à un nom de machine, à configurer une fois par nouvelle machine.
Un fichier /etc/hosts qui associe un nom de machine à une IP, à configurer une fois par changement de pile IP.
Un logiciel qui fournit tout ça automatiquement, et permet de laisser les autres machines en mode DHCP, dnsmasq, qui en plus sert de cache DNS, c'est toujours utile.
Et ça fonctionne même si la ligne internet est coupée : je peux encore accéder à mes machines par leurs petits noms mignons.
Et je sais quelles IPs locales, fournies par mon DHCPCD, ne sont pas reconnues, c'est la plage d'adresse publiques, et je peux configurer leur réseau, et le firewall, pour les limiter, donc un visiteur n'aura pas les mêmes accès que moi.
Ça s'appelle la gestion d'un réseau local.
Face à ça, l'intérêt d'aller configurer le DNS à l'extérieur, je vois vraiment pas.
pcdusalon, c'est privé, ça n'a aucune valeur en dehors de chez moi, même pour moi hors de chez moi, ça reste privé et basta.
Au pire j'ai une machine accessible en SSH depuis internet, et je saute sur pcdusalon depuis celle-ci.
C'est à dire que d'abord je rentre chez moi, et ensuite je vais voir pcdusalon.
Et c'est certes obligatoire en IPv4, mais ça reste pertinent en IPv6.
Parce que même si toutes mes machines ont une IP publique, je vais restreindre la surface d'attaque en laissant un unique SSH accessible à travers le pare-feu, je sauterai toujours à partir d'elle vers le reste du réseau.
Donc je n'ai jamais besoin d'avoir le DNS de pcdusalon.mamaison.xyz sur internet.
Et si pcdusalon héberge un site web public, et bien j'aurais un DNS vers monsiteweb.fr, qui pointerait vers son IP publique, ou plus probablement le reverse proxy que j'ai mis en frontal, ici pour ne pas exposer le serveur web de pcdusalon directement, mais avoir une couche de sécurité en plus, pour pré-filtrer des attaques par exemples, ou rediriger le HTTP vers le HTTPS.
On fait ça nettement mieux avec un haproxy qu'avec un thttpd.
Le DNS local, ce n'est même pas une question de sécurité juste de valeur, de portée, et d'accessibilité, de la donnée.
C'est décorrélé de la sécurité, c'est juste une question de pertinence.
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Merci pour ton commentaire détaillé et pertinent.
Tu m'as fait changé d'avis, et j'aimerais retirer la phrase « Il ne semble pas y avoir d'intérêt à avoir un DNS utilisable uniquement de l'intérieur ».
Je maintiens que ton commentaire auquel je répondais était erroné et que publier les enregistrements dns de machines injoignables ne posent pas de problème de sécurité.
Il peut par contre y avoir, comme tu le décris bien, des raisons pratiques à utiliser deux serveurs dns. Merci donc de m'avoir corrigé.
Petite question : dans la configuration que tu décris, à quoi te servent les adresses ipv4 fixes ? Tu ne pourrais pas avoir des adresses ipv4 aléatoires (fournies par le dhcp), qui ne servent que pour la communication vers l'extérieur, et à l'intérieur utiliser seulement ipv6 via un enregistrement dns ? Cela simplifierait ta configuration ?
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 2.
Oui, je pourrais.
En pratique, j'administre pas mal les machines des autres à partir de la mienne en ssh, et jusqu'à présent j'avais fait ça avec leur nom, leur IP fixe, le DNS local etc.
D'autant plus que j'ai utilisé pas mal d'années du NFS, qui est assez orienté accès par IP.
J'utilise plutôt sshfs aujourd'hui pour les montages réseaux, c'est plus ponctuel, à la demande.
Donc il y a une certaine forme d'inertie : ça fonctionne, je ne change pas.
Mais dans l'idée, mon dnsmasq pourrait récupérer le nom fourni par la machine qui fait sa requête DHCP, lui fournir une adresse aléatoire, et répondre aux requêtes DNS locales sur ce nom avec l'adresse IP fournie, et ça serait dynamique.
J'ai certaines vieilles machines qui risquent de devoir rester en fixe, mais comme j'ai plus trop tendance à les utiliser…
Faut juste que je lise de la doc, et que je prenne du temps, comme pour l'IPv6 :)
Parce que finalement, avoir de l'IPv4 pour le LAN sans accès internet, et de l'IPv6 pour l'internet ça pourrait aussi être une façon de faire les choses.
Une machine sans raison d'accéder au net n'aurait pas d'IPv6.
Parce que je trouve qu'un petit LAN ça reste cognitivement plus simple à gérer en IPv4.
Mais c'est peut-être juste un biais d'habitude.
Je pense aussi, par contre le côté « ça fonctionne à l'identique quand internet est mort », j'apprécie. Pas que ça arrive souvent (d'autant que j'ai une box ADSL+4G, faut que les deux tombent pour qu'internet soit inaccessible), mais quand même.
Et tout ça avec une seule configuration à un endroit (mon SPOF personnel quoi :) ).
[^] # Re: Je ne comprends pas
Posté par nud . Évalué à 4. Dernière modification le 21 avril 2024 à 12:36.
Ça dépend si le serveur dns autorise AXFR ou pas.
[^] # Re: Je ne comprends pas
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Oui tu as raison, je suis parti du principe qu'un serveur dns bien configuré n'autorise l'AXFR que vers les dns secondaires.
[^] # Re: Je ne comprends pas
Posté par totof2000 . Évalué à 3.
Quand tu commences a avoir plus de deux ou trois machines (physiques ou virtuelles) c'est très pratique. J'en ai eu un pendant longtemps (je ne l'ai pas encore remis en service depuis mon déménagement mais il devrait revenir).
Aucun rapport.
Ben il disait qu'il voulait configurer un DNS.
[^] # Re: Je ne comprends pas
Posté par Renault (site web personnel) . Évalué à 3.
Pour info c'est le rôle du mDNS de faire ça, et pas besoin d'un serveur DNS central pour ça ^
[^] # Re: Je ne comprends pas
Posté par Yth (Mastodon) . Évalué à 2.
C'est plus compliqué en pratique.
Parce qu'il y a des machines qui ne font pas ça par exemple.
Qu'avec un réseau très hétérogène, c'est pas si zéro-conf que ça.
Alors comparer avec un unique serveur dnsmasq qui fait tout ça avec deux fichiers de configuration plats et standards, et qui va fonctionner tout le temps, franchement, flemme tout ça, dnsmasq a gagné.
Surtout qu'étant toujours en IPv4, j'ai toujours besoin d'un DNS menteur pour les noms de domaines publics :)
Donc :
- cache DNS ;
- DHCPD (configuration, automatique de l'IP, de la passerelle, du NTP relais local, des plages d'IP visiteur, des DNS secondaires, …) ;
- DNS local ;
- TFTP pour jouer avec le boot réseau.
Un seul logiciel à configurer dans tout le réseau, et tout ça fonctionne, tout le temps, pour n'importe quel périphérique, même un vieux machin, ou un truc expérimental.
C'est toujours la flemme qui l'emporte.
[^] # Re: Je ne comprends pas
Posté par Psychofox (Mastodon) . Évalué à 4.
Moi ce que je ne comprends pas, c'est pourquoi vous n'utilisez pas mDNS/DBS-SD (avahi/bonjour/rendez-vous) pour ce qui est du réseau local/personnel de "maison".
C'est un peu fait pour ce genre de cas.
[^] # Re: Je ne comprends pas
Posté par Mjules (site web personnel) . Évalué à 5.
Yth a globalement bien résumé le problème. En 2020, mon serveur n'avait pas d'enregistrement DNS AAAA (et n'aurait de toute façon pas été configuré pour répondre sur une adresse ipv6).
Donc les DNS fournis par le message RA d'Orange résolvait sur l'ipv4 publique.
Et comme je ne connaissais pas grand chose à ipv6 à l'époque, j'ai préféré désactiver temporairement (un temporaire qui a duré 4 ans).
[^] # Re: Je ne comprends pas
Posté par Olivier Jeannet . Évalué à 4.
À quoi sert de mémoriser des adresses IP ?
Depuis 1999 que je gère des serveurs, je n'utilise que des noms, un serveur DNS c'est indispensable pour plusieurs raisons (et sans serveur DNS, au moins des fichiers "/etc/hosts"). Je retiens parfois une IP mais je ne me sers pour ainsi dire jamais des IP, sauf parfois sur de la conf réseau bas niveau.
D'ailleurs je lutte au boulot pour que certains (parmi les devs ou architectes) arrêtent de mentionner des adresses IP et ne parlent qu'en noms de serveurs. On est au 21e siècle et les serveurs DNS n'ont pas été inventés pour rien. (aucun intérêt de parler des IP, c'est pas parlant du tout et de plus ça pose certains problèmes, surtout quand on en met dans des fichiers de conf)
# Dette technique
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 18 avril 2024 à 22:02.
Tout ça c'est de la dette technique. Si tu étais aux USA, pas de problème, il y a pléthore d'adresse IPV4, si tu étais en Asie, pas de problème, il n'y a plus d'IPV4 depuis longtemps. L'Europe est entre les 2 et doit donc migrer ou bidouiller à mort… d’où des couts gigantesques.
En fait cela se retrouve dans beaucoup de cas. On a un vieux système qui marche bien que l'on ne veut pas trop toucher car ça serait compliquer de tout refaire. Mais de l'autre on voudrait bien moderniser un peu donc on met des bidouilles pour mettre un peu de moderne.
Économiquement, à long terme, ce serait bien plus intéressant de tout migrer. Mais à court terme, ça coute moins cher de bidouiller. Il arrive un moment ou l'on se dit, c'est bon j'en ai marre ça tient plus, il y a toujours un trou dans la raquette, je migre… Mais à l'échelle d'un pays, tant qu'il n'y a pas de lois, tous ne bougeront pas. Il y aura toujours des acteurs à avoir aucun intérêt à arrêter le vieux système.
IPV6 est 100 fois plus simple qu'IPV4 car il n'y aurait plus besoin des milliers de bidouilles. Mais par contre il faudrait tout re-voir…
Les exemples de ce style sont légions: Cobol, Minitel, AS400… mais avant on a l'exemple de la traction animale, de la machine à écrire, du télégraphe, du fax…
Après honnêtement, tant que tu n'a pas besoin de plus de technologie, l'ancienne technologie est aussi bien. Alors je propose de limiter le nombre d'abonner à internet (Et interdire internet sur le téléphone portable)… ou alors de ne pas auto-héberger.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Dette technique
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Exemple d'action https://linuxfr.org/users/devnewton/liens/ipv6-le-gouvernement-de-republique-tcheque-va-arreter-ipv4
[^] # Re: Dette technique
Posté par PhRæD . Évalué à 2.
Je ne vois pas ce que viens faire COBOL là-dedans : plus je connais l’écosystème hors site central, plus je me dis que pour mon métier — la monétique, hors autorisation — le COBOL et son écosystème (JCL - DFSORT - DB2) est tout à fait ce qu’il faut.
COBOL / zOS c’est tout même extrêmement efficace et simple pour gérer de très grosses volumétries à bas coût, le tout avec une qualité de service quasi sans équivalent (disponibilité à 99,99 % au moins).
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Dette technique
Posté par NYC . Évalué à 3. Dernière modification le 21 avril 2024 à 14:18.
Les gens confondent marché de "niche" et techno obsolète.
Je mets "niche" entre guillemet parce que je ne suis pas sûr qu'on puisse considérer la quasi-totalité des flux financiers, de l'informatique de gestion dans les très grosses entreprises comme une niche.
PS : et pour avoir travaillé en mixte open/Zos ce qui se joue c'est aussi les méthodes de travail…
[^] # Re: Dette technique
Posté par PhRæD . Évalué à 2.
Je plussoie !
Nous avons malheureusement des décideurs qui font des choix en fonction de la mode et non en fonction du besoin…
Il y a donc des chances que je vive le passage vers le cloud avant la fin de ma carrière, c’est le mantra du grand chef métier dont je dépend (on « n’innove » pas avec une trabant). Ce qui au passage est grotesque, le site central n’étant rien d’autre que du « cloud » avant l’heure…
M’enfin !
Et donc effectivement, le plus triste est de voir doucement disparaitre une vision de ce que peut être l’informatique de gestion, dans un moment ou le « cloud » se « sitecentralise » pourtant de plus en plus sans s’en rendre compte (forcément avec le temps, les mêmes contraintes aboutissent plus ou moins aux mêmes solutions ; c’est juste du beau gâchis de temps…). Il n’en reste pas moins qu’on risque à l’avenir de faire très compliqué pour pas grand-chose. Mais va expliquer à quelqu’un qui ne connait pas le site central que déployer n’a au grand jamais été un problème et qui va pourtant « t’expliquer la vie ».
Pour finir, je n’écris que le z/OS est parfait, mais en tout cas pour ce qu’on à faire en informatique de gestion en monétique, je doute qu’on puisse faire plus efficace (surtout en ayant vu quelques exemples de « remplacement »).
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Dette technique
Posté par NYC . Évalué à 5.
Arf, dommage que je puisse pas en parler, mais j’ai été au cœur d’un énorme enjeu de ce genre et j’aurai beaucoup à dire là-dessus…
Disons juste qu’il y a aussi et surtout une histoire de gros sous derrière.
1/ Les éditeurs mainframe (IBM évidemment, mais il y aussi tout un écosystème qui vit autour) sont en position de force envers leurs clients. Cela peut pousser certains utilisateurs à tenter d’autres technos.
2/ Sans compter que des mainframers compétents et avec de l’expérience, ça coure pas les rues, beaucoup partent à la retraite, y’a pas de politique de renouvellement autour de ça. C’est un métier difficile, stressant et qui demande un grand sens des responsabilités ; à la monétique tu dois mieux savoir que moi cet aspect là des choses. À compétence informatique similaire les mainframers sont probablement un peu mieux payés (sauf en début de carrière), mais dans le même temps j’ai toujours considéré qu’on était très largement sous-payés par rapport aux enjeux de notre travail. Le discours de l’obsolescence du mainframer que peut tenir le management, c’est aussi un moyen de faire pression vers le bas sur les salaires.
Tout ça pour dire que le management va opter pour l’open et le cloud, en assumant plus ou moins la politique de réduction de coût qu’il y a derrière…
Faut pas se laisser avoir et leur faire sentir qu’en terme de coût de maintenance, de longévité des applicatifs, de fiabilité les mainframers sont imbattables. Franchement pour faire mieux, je crois qu’il faut se tourner vers l’aéronautique, le nucléaire, ce genre de choses…
[^] # Re: Dette technique
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
D'accord mais quand tu a z/OS t'y n'a qu'un unique producteur qui maîtrise toute la chaîne. Les prix sont multipliés par 10 sur toute la chaîne. Le matériel, la maintenanceet surtout la sécurité/compatibilité avec un réseau moderne… alors certes il y a de la fiabilité mais 0 flexibilité. Et si l'oncle Sam ou je ne sais quoi décide quoi que ce soit on est foutu.
Aujourd'hui un bon serveur bien fait sous Linux sait faire aussi bien pour bien moins cher. Et n'allez pas croire que z/OS est plus simple.
Et le cloud, ce n'est pas un serveur central, c'est des dizaines répartis dans le monde entier. Point de vue résilience il n'y a pas mieux. C'est bien plus que 99.99% de disponibilité. C'est 100% avec des coupure de 0.0001% locales mais pas générales.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Dette technique
Posté par PhRæD . Évalué à 4.
Pour information, IBM, n’est pas, et de loin le seul éditeur sur z/OS.
Pour ce qui est de la flexibilité, il faudrait juste savoir de quoi l’on parle : s’il s’agit de pourvoir faire ce qu’on veut avec les briques que l’on a, je maintiens qu’il est possible de faire tout ce qui nous passe par la tête (et même pire !) en site central : on peut faire du 3270 (et je pense qu’en back-office, rien ne vaut mieux que ce type d'interface), de l’API REST, du traitement (très très) massif avec le batch (compatible avec une activité transactionnelle en mode BMP), du MQ, du synchrone, de l’asynchrone, faire manger du JSON à un programme COBOL qui pourrait répondre en xml si ça lui chante, bref, vraiment tout ce qu’on veut.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Dette technique
Posté par totof2000 . Évalué à 5.
Je pense que tu as une vue un peu déformée de ce que eut faire un mainframe IBM et Zos.
Zos (qui s'appelait sait faire du TCP IP depuis des dizaines d'années. ZOs s'est très bien adapté aux évolutions techniques modernes. Les mainframes avaient la virtualisation matérielle bien avant qu''on ne puisse l'imaginer sur X86 et Unix. ZOs sait faire l'équivalent de k8s ( voir https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/juergen-holtz1/2022/05/10/containers-on-zos-kubernetes-meets-system-automati ) Un mainframe peut faire tourner des VMs Linux, et on peut même déployer un cluster Openshift sous Zos.
Alors oui, c'est cher. Mais quand tu as besoin de fiabilité, tu en as pour ton argent. Mais c'est comme tout : tout dépend de tes besoins.
# se passer de la box sosh
Posté par totof2000 . Évalué à 3.
Est-ce qu'il est possible de se passer de la box sosh et de bénéficier de l'IPV4/IPV6 ?
[^] # Re: se passer de la box sosh
Posté par Mjules (site web personnel) . Évalué à 4.
Oui, et ça permet d'utiliser intégralement le /56 délégué. Mais c'est compliqué et il faut accepter de se passer du téléphone fixe.
Tu as beaucoup d'informations sur lafibre.info : https://lafibre.info/remplacer-livebox/
[^] # Re: se passer de la box sosh
Posté par totof2000 . Évalué à 4.
Je complète ma question : serait-il possible de configurer un PC en routeur en lui installant une carte PCI Fibre adaptée ?
[^] # Re: se passer de la box sosh
Posté par Mjules (site web personnel) . Évalué à 5.
Pour le module fibre, il faut que le numéro de série soit reconnu par Orange pour qu'ils l'acceptent sur leur réseau, donc soit arriver à les faire modifier ton dossier pour le numéro de série de ton carte/module fibre, soit modifier/flasher ton module pour qu'il adopte le numéro de série de celui de la livebox (ou du boitier ONT orange).
cf là et d'autres sujets : https://lafibre.info/remplacer-livebox/remplacement-de-livebox5-nimporte-quel-sfp-fait-laffaire/
[^] # Re: se passer de la box sosh
Posté par totof2000 . Évalué à 4.
Merci pour la réponse. Ca n'a pas l'air d'être très simple. Ya-t-il d'autres fournisseurs qui permettent de se passer de leur box plus facilement ?
[^] # Re: se passer de la box sosh
Posté par Mjules (site web personnel) . Évalué à 2.
Chez les 4 grands FAI, a priori, neuf et bouygues serait un peu plus simple.
Après tu as les FAI plus confidentiels comme milkywan où là tu amènes toi même ton routeur.
[^] # Re: se passer de la box sosh
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
J'ai l'impression que se passer du modem de l'opérateur n'est pas possible, car c'est un outil qui fait partie de leur infrastructure et doit donc avoir des mots de passe/clés secrètes spécifiques à l'opérateur pour éviter les abus de leur infrastructure.
(Les box en France sont juste des outils qui intègrent un modem, un routeur et un serveur multimédia)
Ce que j'ai fais chez moi, c'est que j'ai monté un routeur avec OpenWrt et c'est la seule machine connectée au modem de mon opérateur (qui ne fournit que de l'IPv4 dans mon cas).
Ensuite, j'ai commandé le produit IPv4 as a Service d'ungleich et j'ai demandé également de recevoir un préfixe IPv6
/48inclus dans le prix.1Ces deux services demandent seulement d'avoir une connexion internet (via le modem de l'opérateur) et d'avoir une machine qui peut exécuter un client VPN Wireguard (n'importe quelle machine fait l'affaire, car Wireguard fonctionne sans avoir besoin de décodage matériel particulier).2
Ensuite, j'ai configuré tout mon réseau via le routeur avec OpenWrt3 et je suis complètement indépendant de mon opérateur réseau. C'est un peu cher, mais c'est vraiment chouette de maîtriser son réseau.
L'avantage de cette solution, c'est que pour faire entrer le trafique Internet dans mon réseau, je n'ai besoin de configurer uniquement le NAT et le firewall de mon routeur: aucune configuration spéciale n'est nécessaire sur le modem de mon opérateur, j'en suis indépendant.
J'ai pu vérifier cette théorie d'indépendance cette hiver quand j'ai du déménagé temporairement chez une connaissance: j'ai branché mon routeur sur le modem de son opérateur et mon serveur était tout de suite accessible :)
On peut aussi ne commander que le réseau IPv6 uniquement ce qui est un peu moins cher, mais moi j'avais besoin d'avoir une adresse IPv4 publique pour mon serveur et de pouvoir définir les entrées reverse DNS pour mon serveur mail. ↩
Après un routeur dédié est plus efficace en terme d'énergie et propose pour une centaine d'euro plusieurs ports ethernet et souvent la gestion du wifi. Passez voir le wiki d'OpenWrt avant de faire vos courses, ils ont un tableau des matériels compatibles. ↩
Dans OpenWrt, les deux tunnels VPNs (un pour l'IPv4 et un pour l'IPv6) sont vu comme des interfaces réseaux de type WAN supplémentaire. ↩
[^] # Re: se passer de la box sosh
Posté par nud . Évalué à 6.
Alors je sais pas en France mais en Belgique c'était exactement la situation telle que présentée par Proximus (l'opérateur historique) mais l'IBPT (le régulateur des télécoms en Belgique) les a obligés à autoriser d'autres routeurs (notamment Fritzbox mais pas que) et à permettre aux utilisateurs d'obtenir leurs identifiants et mots de passe VDSL, tout cela pour une question de concurrence et de règles UE.
Comme j'ai une connexion VDSL j'utilise toujours la box opérateur avec une connexion PPPoE pour l'IPv4 et DHCP6 pour l'IPv6 depuis un routeur maison opnsense, mais il semblerait que les rares élus ayant une connexion fibre peuvent se passer de la box complètement.
Tout marche au poil, le seul emmerdement c'est que le préfixe IPv6 n'est actuellement pas réputé fixe et pourrait donc changer à tout moment, ce qui aurait un effet sur toutes les IPs internes.
# Faut pas jeter le bébé IPv6...
Posté par lym . Évalué à 3. Dernière modification le 07 mai 2024 à 11:39.
… avec l'eau du marigot IPv4 quand même!
Un cas ou un double adressage sur un routeur (pas sous mon contrôle) m'a rendu service, c'est dans une loc de vacances: Visiblement, le serveur DHCPv4 était mal configuré et en quasi permanence en rupture de baux (sans doute alloués trop longuement)… donc rien de fonctionnel en IPv4, même en tentant une allocation fixe dans la plage qui semblait valide via l'infaillible "méthode du ping muet"… probable que le routeur bloquait tout ce qu'il n'avait pas alloué lui même et qu'il eu fallu usurper un couple MAC+IPv4 "légitime" au risque d'emmerder qqun d'autre.
Par contre une IPv6 automatique (préfixe+fin de la MAC de l'interface) était utilisable… et permettait d'accéder au moins au côté IPv6 du web actuel (l'occasion de se rendre compte qu'il en manque)!
En fait, ce qui m'a posé pb, c'est que ma domotique auto-hébergée (derrière une LB4 pourtant avec IPv6 activé et IPv4 resté en doublon) n'était pas accessible car no-ip qui fournit mon nom de domaine gratuit ne renseigne pas par défaut l'IPv6 dans les scripts qu'ils proposent… Même si en pratique elle ne change jamais et qu'on peut alors l'ajouter sur leur site via son compte.
Depuis, ceinture et bretelles avec une solution simple qui check périodiquement si IPv4 ou IPv6 changent et m'envoient un mail le cas échéant avec la solution de backup bulletproff si même le côté DNS joue un sale tour: Un simple lien cliquable de connexion au raspberry PI qui héberge ma domotique ainsi (concaténations de chaîne en Lua):
<a href="https://'..outIP4..'/">IPv4 link...</a>\\n<a href="https://['..outIP6..']/">IPv6 link...</a>
L'occasion d'apprendre seulement qu'un lien en adressage direct en IPv6 impose de mettre l'adresse entre crochets, pour ma part: C'est peu mais pour des besoins simples cela me parait offrir une solution de secours acceptable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.