C'est pas vraiment une « structure » mais au Hackerspace (à l'Élabo) il y a un certain nombre de personnes qui réparent des machines. Et un stock de poubelles^Wmachines à recycler impressionnant (enfin, je pense qu'une bonne partie est allée à la benne lors du dernier nettoyage).
Pareil ici pour ma banque, même pour l'espace client de gestion de son compte. Bon, ça a changé il y a 6 mois avec la refonte, mais c'était le cas pendant plusieurs années. J'ai même reçu un joli courrier papier après ma remarque sur laquelle ils m'indiquent qu'ils ne voyaient pas de problème…
C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port
J'aurais bien aimé avoir ton explication sur ce choix… Alors j'enfonce un peu le clou : s'imaginer qu'on maîtrise une application parce qu'on peut « choisir » quels ports elle utilise, c'est un peu comme ceux qui croient maîtriser la consommation CPU ou mémoire d'une appli avec les cgroup. Tu te dis « Je vais interdire à l'application de faire ci ou ça », alors qu'en fait tu la casses parce que si un flux existe, c'est qu'il a une bonne raison d'exister, comme pour la conso CPU ou mémoire. J'ai l'impression que les gens font des analogies à deux francs sur « restreindre » une application comme un être vivant : ça va la « calmer » un peu de limiter son accès réseau / son CPU / sa mémoire… c'est débile !
Oui, ce que tu pointes (qui est un utilitaire) est plutôt défini par les configurations de socket : https://manpages.debian.org/unstable/systemd/systemd.socket.5.en.html
Je précise dans le journal qu'une configuration pour approx est fournie par défaut dans ce format. Cependant, le manuel ne semble pas indiquer la possibilité de spécifier un nom d'hôte dans "ListenStream" (équivalent du premier champ pour inetd), ce qui est pour moi une régression inacceptable (les identifiants sous forme de noms changent en général moins que les IP, et dans mon exemple le nom d'hôte sera spécifié potentiellement pour d'autres services, et la modification serait laborieuse et prompte à erreur si elle se faisait par adresse ; sans parler de la lourdeur avec les IPv6). Encore une réinvention de la roue en moins bien.
Si quelqu'un qui utilise systemd pouvait me contredire, je n'en serais que plus heureux ; mais il faudrait au moins mettre à jour le man.
Je vais faire le commentaire habituel : avec du suspend-to-ram, j'ai mon système up plus rapidement que mes écrans s'allument… (2-3 s, en gros) Et j'ai tout de chargé et connecté, pas besoin de relancer mes n logiciels et leur contexte.
OK, j'ai oublié la troisième voie : ne rien en avoir à foutre et rester comme on est par la force, l'isolement, etc, afin de défendre nos besoins en énergie. Ça « peut » marcher, mais j'ai quelques doutes quand même.
Va falloir discuter un coup avec les gilets jaunes, alors, parce que ça me semble assez incompatibles avec l'injonction permanente à gagner du pouvoir d'achat.
Je ne pense pas que c'est ce qu'ils veulent : ils ne veulent juste pas en perdre. On a détruit les services publics pour les remplacer par plus de consommation et de divertissement, mais ça ne suffit pas à combler ce manque.
Après, bien sûr que dans ma perspective il y a une grosse dimension décroissance qui est assez difficile à faire accepter. Mais il n'y a pas d'autre solution, le seul choix étant de savoir si on veut la choisir (maintenant) ou la subir (plus tard). Généralement, quand on subit, c'est moins beau à voir.
C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port parce que peut être que quelqu'un va les utiliser un jour
Alors là tu retombes complètement dans les contorsions inutiles d'IPv4 : en quoi « choisir » les ports de tes applications va t'aider à la maîtriser ? Faire du mapping de port, c'est comme faire du NAT, c'est des modalités locales « hors » de l'appli qui sclérosent le routage et le réseau ; c'est de « l'intelligence dans le réseau ». Les ports ne sont pas faits pour servir de variable d'ajustement du placement de service, à la base, même si c'est la « doctrine Docker » aujourd'hui (les mecs qui ont inventé Docker n'y connaissent rien en réseau).
Je ne comprends pas du tout ce que ça t'apporte de pouvoir bidouiller ça.
OK donc tu veux mettre de l'intelligence au milieu, et ça ne colle pas bien dans le modèle « classique » d'IP.
Par contre, la gestion de surcharge peut très bien s'effectuer côté client, avec des SRV et/ou l'utilisation correcte de getaddrinfo(3), qui permet de base d'itérer sur un nombre d'hôtes renvoyé par le DNS, et trouver un serveur fonctionnel dans le tas (avec des règles précises d'essai et de repli pour les SRV). Tu peux même mettre des règles en « fontal » également si tu le souhaites, sur critère X ou Y, pour renvoyer un ICMP unreachable quand tu veux.
Encore une fois, tu peux toujours utiliser des solutions « intelligentes » dans le réseau pour faire de l'analyse et du re-routage en cas de surcharge ou autre, comme l'exemple que tu as donné, mais tu peux également utiliser les méthodes plus « bout-en-bout ».
Je me demande quel est l'overhead (octets utiles sur octets pour transporter) pour dire "salut" suivi de "salut" suivi de "je t'ai pas vu en ligne hier" (chose qu'on ne fait pas avec des mails) par rapport aux autres protocoles.
Sûrement 100 fois moins que la somme des JS utilisés sur chaque page Web pour visionner le-dit message ;-)
C'est assez intéressant. J'ai déjà eu des idées similaires pour un autre type de projet, et j'avais également déjà voulu faire du chat par e-mail, sans y penser sérieusement… bravo à vous.
En ce qui concerne les groupes, j'avais tenté de voir comment était supporté la gestion de groupe « historique » de l'e-mail (https://tools.ietf.org/html/rfc5322#page-17) et ça marchait dans Outlook, ce qui m'avait motivé pour creuser un peu, celui-ci étant pour moi le plus petit dénominateur commun. Manque de bol, j'ai l'impression que c'est le MUA qui gère le mieux cette feature… Effectivement, tracker les modification d'état du groupe de manière non-stricte est à faire, et le système présenté ici est pas mal.
La ou Internet IPv4 est un réseau de réseaux, avec des passerelles, avec IPv6 il n'y a plus qu'un seul réseau?
« Réseau de réseaux » ne veut pas forcément dire « imbrication » avec NAT ! Internet v6 est autant un réseau de réseau qu'IPv4, c'est juste que l'interconnexion se fait de manière « plate » jusqu'aux extrémités.
Si tu es distribué c'est complexe quelque soit ta version d'IP, c'est le fait d'avoir 2 logiciels qui tournent et qui doivent être synchronisés qui pose problème pas le routage, pas le reverse proxy.
Oui, sauf que si ton application ne nécessite pas d'état partagé, comme approx, tu n'as pas à t'embêter avec ; le frontal en reverse-proxy t'oblige à le faire, même si ton application ne le nécessite pas. Après, si tu gères majoritairement des applications distribuées qui nécessitent du partage d'état, avoir à le faire sur le proxy n'ajoute qu'une contrainte de plus, en effet.
Docker va cacher ça dans un réseau spécifique. Ce qui entre et sors de ce réseau est tout à fais maîtrisable.
Gni ? Maîtrisable dans quel sens ? Si tu dis « bien décris », bah pareil pour mon application : je peux te décrire quel type de paquet/connexion elle va lancer dans quel sens. Je ne comprends pas la différence que tu fais.
Il existe des serveurs qui n'ouvrent pas de sockets et ne font que lire stdin?
Heu… c'est le principe d'approx que je viens de décrire dans le journal ! Sauf que je vois qu'en fait il l'utilise comme un socket en faisant un getsockname() pour commencer, et du coup je me rends compte que je connais mal inetd car à priori on peut faire bien plus que de simple entrées-sorties : c'est bien le socket tel qu'ouvert par inetd qui est passé sur stdin/stdout.
Du coup, autre point qui m'intéresse: ton IPv6, tu la distribue comment? Codée en dur dans la machine ou distribuée par un DHCP?
Comme tu veux. C'est la « complexité » d'IPv6 : vu que ta topologie n'est pas « gérée dynamiquement » par le NAT¹, il faut que tu aies un plan d'adressage « bien fait » au départ. Il existe plein de conseils là-dessus, et c'est une problématique routeur ; une fois que ton réseau est en place, c'est plus simple pour l'adressage des serveurs et services.
qui aura 2 IPs, une en local, une en global.
Non. Oublie « local » ou « global » ; enfin, dans un réseau simple². Tu ne dois pas penser « interface », mais « adressage » : comment adresses-tu ta machine ? Ton routeur, si tu veux une seule IP sur le loopback (façon Cisco), ça se fait très bien. Et le loopback ça n'est aucune des deux interfaces que tu viens de décrire ! Moi en général j'adresse globalement l'interface upstream (« nord » pour certains). Au sud, je laisse uniquement link-local, s'il n'y a pas de raison particulière de l'adresser en global. Tu vas me dire « ah ! mais t'as une locale d'une côté et globale de l'autre ! » mais ça n'est pas ça : j'ai de toutes façons des link-local sur mes deux interfaces, et je rajoute des globales où je veux. Question routage, je ferai passer les paquets tels-quels d'une interface à l'autre, après décision de routage sur la destination : c'est la base d'IP. Et dans IPv6 quand on ne fait pas de traduction, ça a l'avantage qu'un paquet sera identique quel que soit le point du réseau où il est observé : c'est une propriété absolument déterminante point de vue débugabilité du réseau, à un point que tu ne peux pas imaginer (je debug parfois des problèmes avec NAT des deux côté où les gens n'ont aucune idée de qui l'a envoyée ni qui la recevra).
1 : c'est dur à expliquer clairement, je peux préciser si tu veux.
2 : je sous-entend quand tu n'ajoutes pas un réseau « parallèle » en ULA
Bah tu dis ça, mais une fois que tu as monté ton ensemble de Docker dans tous les sens avec tes quarante applis containerisées qui font plein de trucs dynamique, cet ensemble va bien « lancer des connexions dans tous les sens ». Une application complexe aura ce comportement au bout d'un moment. Vouloir modéliser ça et le mettre dans le marbre d'une firewall (applicatif ou non) c'est scléroser ton modèle applicatif, qui va par la suite devoir truander tes flux pour se faufiler là où ça passe. C'est ça qui est vendu d'avance.
Et puis cette hypocrisie du « monitoring » quand aujourd'hui la moindre page web envoie des infos à droite à gauche dans tous les sens de manière dynamique… (OK, je change de contexte) personne ne le monitore, ça serait trop complexe ! Et pourtant je ne vois pas les sysadmin s'en plaindre : ils sont à la limite de leurs compétences et du coup ne font rien, alors que pour faire chier les applications standards ça ils y arrivent bien ! Bref, on ne voit et contrôle que ce qu'on veut voir et contrôler.
OK, c'est un cas extrême. Mais même en restant au « même endroit » (physiquement), souvent les réseaux en RFC 1918 sont gérés de manière anarchique, et le schéma de routage devient ossifié et on doit inventer des technos en-dessous pour refaire le routage à un niveau inférieur (à coup de technologies de VPN diverse et variées).
Je suis d'accord que le problème est plus complexe que dire juste « IPv6 », mais ça va avec : utiliser les API standard (socket), ne pas intégrer un schéma IP en dur dans le code, etc.
Ce que je ne comprends pas c'est que je ne reçois pas de critique claire de ce modèle : on me dit que c'est « has-been » alors que ça scale beaucoup mieux que les trucs actuels. Je sais bien que l'obstacle majeur n'est pas dans la technique mais dans la formation, le modèle de responsabilité, la mise en place de la transition, etc. Mais pourquoi dire que le modèle technique est dépassé ?!
On peut très bien déclarer plusieurs reverse proxy dans ton enregistrement dns.
Oui, mais comme je disais après il faut réussir à les synchroniser pour tout ce qui est état partagé (pour l'authentification sûrement, voire plus).
Par contre si je ne me trompe pas c'est bien plus compliqué avec IPv6. Là où les ip sont présenté en round robin avec IPv4, avec IPv6 l'ordre est défini et fixé. Donc les clients doivent consciemment implémenter le balancing.
Hmm, je ne vois pas d'où tu sors ça : le principe d'IP (v4 ou v6) « à l'ancienne » c'est de faire de la répartition sur un ensemble d'IP retournées en résolvant un nom. Sauf que comme il n'existe pas de standard sur comment faire ce round-robin, il a été standardisé les enregistrements SRV, sur le modèle des MX, qui précise l'algo à implémenter. D'autres ont préféré gérer ça côté serveur, et comme d'hab c'est moche : on pète le mécanisme de cache avec des TTL courts et du round-robin fait par le DNS. Aucune de ces solutions n'est spécifique à v4 ou v6, c'est juste que je suppose qu'en IPv6 on fera quelque-chose de mieux avec des SRV. Si tu veux implémenter du load-balancing côté serveur par contre, pas de problème, je pense que haproxy et consort savent faire de l'IPv6. C'est juste que ça n'est pas dans sa philosophie.
Hum ? Je ne vois pas de quoi tu parle ?
Si tu as de l'authentification fait par ton frontal, il faut que l'état soit répliqué sur tous tes fronts de la bonne manière. C'est complexe. Si il y a un peu de gestion de session sur les fronts, pareil.
Aujourd'hui, je pense que tu pourrais tout à fait lancer ton service via un bon vieux init.d (ou fichiers services, si tu manges de ce pain là :p) .
Tout à fait, je présentais juste ce service qui avait ce type de fonctionnement, mais n'importe quel démon est le bienvenu !
Or j'ai cru comprendre que tu déployais tout ça sur un réseau local, n'est ce pas ?
Bzzz ! Tu fais l'erreur de penser « local vs. global » : tu as inscrits dans la définition de ton service le périmètre qu'il aura. C'est gravé dans le marbre, et dès que ton périmètre devra changer, tu seras dans la merde. En IPv6, tu mets ton service « sur le réseau » (d'où le titre de ce journal), et tu définis après (et de préférence aux extrémités, pas dans le réseau) sa portée.
rien ne t'empêche d'ajouter une adresse (v4 ou v6) à eth0 et de faire tourner ton cache de paquet sur cette nouvelle adresse.
Et tu devras te taper des problématiques de routage à la con au moindre changement topologique. C'est vu et revu.
C'est surtout que ceux qui ont lu le code d'ip_conntrack_* qui font encore cauchemars…
Effectivement, et la conclusion c'est qu'il ne faut pas faire de conntrack. C'est pour moi le principal obstacle à la prolifération d'IPv6 : arrêter avec les politiques de soit-disant sécurité débiles, et ne pas faire de stateful! C'est ce qui a tué l'Internet v4 hors Web, et ce qui tuera IPv6 dans l'œuf si on fait la même connerie.
[^] # Re: sur Rennes ?
Posté par benoar . En réponse au journal Refaire fonctionner des portables dans un fablab. Évalué à 3.
C'est pas vraiment une « structure » mais au Hackerspace (à l'Élabo) il y a un certain nombre de personnes qui réparent des machines. Et un stock de poubelles^Wmachines à recycler impressionnant (enfin, je pense qu'une bonne partie est allée à la benne lors du dernier nettoyage).
[^] # Re: Même le milieu médical s'en fout
Posté par benoar . En réponse au journal Sécurité, vie privée... et Google Analytics!. Évalué à 3.
Pareil ici pour ma banque, même pour l'espace client de gestion de son compte. Bon, ça a changé il y a 6 mois avec la refonte, mais c'était le cas pendant plusieurs années. J'ai même reçu un joli courrier papier après ma remarque sur laquelle ils m'indiquent qu'ils ne voyaient pas de problème…
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 0.
J'aurais bien aimé avoir ton explication sur ce choix… Alors j'enfonce un peu le clou : s'imaginer qu'on maîtrise une application parce qu'on peut « choisir » quels ports elle utilise, c'est un peu comme ceux qui croient maîtriser la consommation CPU ou mémoire d'une appli avec les cgroup. Tu te dis « Je vais interdire à l'application de faire ci ou ça », alors qu'en fait tu la casses parce que si un flux existe, c'est qu'il a une bonne raison d'exister, comme pour la conso CPU ou mémoire. J'ai l'impression que les gens font des analogies à deux francs sur « restreindre » une application comme un être vivant : ça va la « calmer » un peu de limiter son accès réseau / son CPU / sa mémoire… c'est débile !
[^] # Re: Pour remplacer inetd
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 3.
Oui, ce que tu pointes (qui est un utilitaire) est plutôt défini par les configurations de socket : https://manpages.debian.org/unstable/systemd/systemd.socket.5.en.html
Je précise dans le journal qu'une configuration pour approx est fournie par défaut dans ce format. Cependant, le manuel ne semble pas indiquer la possibilité de spécifier un nom d'hôte dans "ListenStream" (équivalent du premier champ pour inetd), ce qui est pour moi une régression inacceptable (les identifiants sous forme de noms changent en général moins que les IP, et dans mon exemple le nom d'hôte sera spécifié potentiellement pour d'autres services, et la modification serait laborieuse et prompte à erreur si elle se faisait par adresse ; sans parler de la lourdeur avec les IPv6). Encore une réinvention de la roue en moins bien.
Si quelqu'un qui utilise systemd pouvait me contredire, je n'en serais que plus heureux ; mais il faudrait au moins mettre à jour le man.
[^] # Re: userland
Posté par benoar . En réponse au journal Mon retour sous KDE. Évalué à 1.
Je vais faire le commentaire habituel : avec du suspend-to-ram, j'ai mon système up plus rapidement que mes écrans s'allument… (2-3 s, en gros) Et j'ai tout de chargé et connecté, pas besoin de relancer mes n logiciels et leur contexte.
Ah, et ça fait 10 ans que ça fonctionne…
[^] # Re: Proposition n°1: la production doit être durable
Posté par benoar . En réponse au journal Cahier de doléances. Évalué à 1.
OK, j'ai oublié la troisième voie : ne rien en avoir à foutre et rester comme on est par la force, l'isolement, etc, afin de défendre nos besoins en énergie. Ça « peut » marcher, mais j'ai quelques doutes quand même.
[^] # Re: Proposition n°1: la production doit être durable
Posté par benoar . En réponse au journal Cahier de doléances. Évalué à 0.
Je ne pense pas que c'est ce qu'ils veulent : ils ne veulent juste pas en perdre. On a détruit les services publics pour les remplacer par plus de consommation et de divertissement, mais ça ne suffit pas à combler ce manque.
Après, bien sûr que dans ma perspective il y a une grosse dimension décroissance qui est assez difficile à faire accepter. Mais il n'y a pas d'autre solution, le seul choix étant de savoir si on veut la choisir (maintenant) ou la subir (plus tard). Généralement, quand on subit, c'est moins beau à voir.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 4.
Alors là tu retombes complètement dans les contorsions inutiles d'IPv4 : en quoi « choisir » les ports de tes applications va t'aider à la maîtriser ? Faire du mapping de port, c'est comme faire du NAT, c'est des modalités locales « hors » de l'appli qui sclérosent le routage et le réseau ; c'est de « l'intelligence dans le réseau ». Les ports ne sont pas faits pour servir de variable d'ajustement du placement de service, à la base, même si c'est la « doctrine Docker » aujourd'hui (les mecs qui ont inventé Docker n'y connaissent rien en réseau).
Je ne comprends pas du tout ce que ça t'apporte de pouvoir bidouiller ça.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
OK donc tu veux mettre de l'intelligence au milieu, et ça ne colle pas bien dans le modèle « classique » d'IP.
Par contre, la gestion de surcharge peut très bien s'effectuer côté client, avec des SRV et/ou l'utilisation correcte de getaddrinfo(3), qui permet de base d'itérer sur un nombre d'hôtes renvoyé par le DNS, et trouver un serveur fonctionnel dans le tas (avec des règles précises d'essai et de repli pour les SRV). Tu peux même mettre des règles en « fontal » également si tu le souhaites, sur critère X ou Y, pour renvoyer un ICMP unreachable quand tu veux.
Encore une fois, tu peux toujours utiliser des solutions « intelligentes » dans le réseau pour faire de l'analyse et du re-routage en cas de surcharge ou autre, comme l'exemple que tu as donné, mais tu peux également utiliser les méthodes plus « bout-en-bout ».
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Si tu fais de l'authentification en frontal, il va bien falloir synchroniser tes tokens de session. C'est un exemple, il y en a peut-être d'autres.
[^] # Re: Consommation de ressources
Posté par benoar . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 10.
Sûrement 100 fois moins que la somme des JS utilisés sur chaque page Web pour visionner le-dit message ;-)
# Sympa
Posté par benoar . En réponse au journal Delta Chat est prêt pour le bureau. Évalué à 6.
J'ai regardé la spec pour comprendre un peu mieux :
https://github.com/deltachat/spec/blob/master/spec.md
C'est assez intéressant. J'ai déjà eu des idées similaires pour un autre type de projet, et j'avais également déjà voulu faire du chat par e-mail, sans y penser sérieusement… bravo à vous.
En ce qui concerne les groupes, j'avais tenté de voir comment était supporté la gestion de groupe « historique » de l'e-mail (https://tools.ietf.org/html/rfc5322#page-17) et ça marchait dans Outlook, ce qui m'avait motivé pour creuser un peu, celui-ci étant pour moi le plus petit dénominateur commun. Manque de bol, j'ai l'impression que c'est le MUA qui gère le mieux cette feature… Effectivement, tracker les modification d'état du groupe de manière non-stricte est à faire, et le système présenté ici est pas mal.
Bon courage pour la suite !
[^] # Re: My 2 cents
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 4.
« Réseau de réseaux » ne veut pas forcément dire « imbrication » avec NAT ! Internet v6 est autant un réseau de réseau qu'IPv4, c'est juste que l'interconnexion se fait de manière « plate » jusqu'aux extrémités.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
L'article de LWN à propos de cette présentation vient d'être dispo au public aujourd'hui :
https://lwn.net/Articles/777595/
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Oui, sauf que si ton application ne nécessite pas d'état partagé, comme approx, tu n'as pas à t'embêter avec ; le frontal en reverse-proxy t'oblige à le faire, même si ton application ne le nécessite pas. Après, si tu gères majoritairement des applications distribuées qui nécessitent du partage d'état, avoir à le faire sur le proxy n'ajoute qu'une contrainte de plus, en effet.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Gni ? Maîtrisable dans quel sens ? Si tu dis « bien décris », bah pareil pour mon application : je peux te décrire quel type de paquet/connexion elle va lancer dans quel sens. Je ne comprends pas la différence que tu fais.
[^] # Re: My 2 cents
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 2.
Heu… c'est le principe d'approx que je viens de décrire dans le journal ! Sauf que je vois qu'en fait il l'utilise comme un socket en faisant un getsockname() pour commencer, et du coup je me rends compte que je connais mal inetd car à priori on peut faire bien plus que de simple entrées-sorties : c'est bien le socket tel qu'ouvert par inetd qui est passé sur stdin/stdout.
[^] # Re: My 2 cents
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 4.
Comme tu veux. C'est la « complexité » d'IPv6 : vu que ta topologie n'est pas « gérée dynamiquement » par le NAT¹, il faut que tu aies un plan d'adressage « bien fait » au départ. Il existe plein de conseils là-dessus, et c'est une problématique routeur ; une fois que ton réseau est en place, c'est plus simple pour l'adressage des serveurs et services.
Non. Oublie « local » ou « global » ; enfin, dans un réseau simple². Tu ne dois pas penser « interface », mais « adressage » : comment adresses-tu ta machine ? Ton routeur, si tu veux une seule IP sur le loopback (façon Cisco), ça se fait très bien. Et le loopback ça n'est aucune des deux interfaces que tu viens de décrire ! Moi en général j'adresse globalement l'interface upstream (« nord » pour certains). Au sud, je laisse uniquement link-local, s'il n'y a pas de raison particulière de l'adresser en global. Tu vas me dire « ah ! mais t'as une locale d'une côté et globale de l'autre ! » mais ça n'est pas ça : j'ai de toutes façons des link-local sur mes deux interfaces, et je rajoute des globales où je veux. Question routage, je ferai passer les paquets tels-quels d'une interface à l'autre, après décision de routage sur la destination : c'est la base d'IP. Et dans IPv6 quand on ne fait pas de traduction, ça a l'avantage qu'un paquet sera identique quel que soit le point du réseau où il est observé : c'est une propriété absolument déterminante point de vue débugabilité du réseau, à un point que tu ne peux pas imaginer (je debug parfois des problèmes avec NAT des deux côté où les gens n'ont aucune idée de qui l'a envoyée ni qui la recevra).
1 : c'est dur à expliquer clairement, je peux préciser si tu veux.
2 : je sous-entend quand tu n'ajoutes pas un réseau « parallèle » en ULA
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 2.
Bah tu dis ça, mais une fois que tu as monté ton ensemble de Docker dans tous les sens avec tes quarante applis containerisées qui font plein de trucs dynamique, cet ensemble va bien « lancer des connexions dans tous les sens ». Une application complexe aura ce comportement au bout d'un moment. Vouloir modéliser ça et le mettre dans le marbre d'une firewall (applicatif ou non) c'est scléroser ton modèle applicatif, qui va par la suite devoir truander tes flux pour se faufiler là où ça passe. C'est ça qui est vendu d'avance.
Et puis cette hypocrisie du « monitoring » quand aujourd'hui la moindre page web envoie des infos à droite à gauche dans tous les sens de manière dynamique… (OK, je change de contexte) personne ne le monitore, ça serait trop complexe ! Et pourtant je ne vois pas les sysadmin s'en plaindre : ils sont à la limite de leurs compétences et du coup ne font rien, alors que pour faire chier les applications standards ça ils y arrivent bien ! Bref, on ne voit et contrôle que ce qu'on veut voir et contrôler.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Donc pour de la protection de surcharge, ou de l'anti-DDoS, ou un truc du genre ? Ça se gère très bien niveau IP, selon moi.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
OK, c'est un cas extrême. Mais même en restant au « même endroit » (physiquement), souvent les réseaux en RFC 1918 sont gérés de manière anarchique, et le schéma de routage devient ossifié et on doit inventer des technos en-dessous pour refaire le routage à un niveau inférieur (à coup de technologies de VPN diverse et variées).
Je suis d'accord que le problème est plus complexe que dire juste « IPv6 », mais ça va avec : utiliser les API standard (socket), ne pas intégrer un schéma IP en dur dans le code, etc.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 3.
Ce que je ne comprends pas c'est que je ne reçois pas de critique claire de ce modèle : on me dit que c'est « has-been » alors que ça scale beaucoup mieux que les trucs actuels. Je sais bien que l'obstacle majeur n'est pas dans la technique mais dans la formation, le modèle de responsabilité, la mise en place de la transition, etc. Mais pourquoi dire que le modèle technique est dépassé ?!
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Oui, mais comme je disais après il faut réussir à les synchroniser pour tout ce qui est état partagé (pour l'authentification sûrement, voire plus).
Hmm, je ne vois pas d'où tu sors ça : le principe d'IP (v4 ou v6) « à l'ancienne » c'est de faire de la répartition sur un ensemble d'IP retournées en résolvant un nom. Sauf que comme il n'existe pas de standard sur comment faire ce round-robin, il a été standardisé les enregistrements SRV, sur le modèle des MX, qui précise l'algo à implémenter. D'autres ont préféré gérer ça côté serveur, et comme d'hab c'est moche : on pète le mécanisme de cache avec des TTL courts et du round-robin fait par le DNS. Aucune de ces solutions n'est spécifique à v4 ou v6, c'est juste que je suppose qu'en IPv6 on fera quelque-chose de mieux avec des SRV. Si tu veux implémenter du load-balancing côté serveur par contre, pas de problème, je pense que haproxy et consort savent faire de l'IPv6. C'est juste que ça n'est pas dans sa philosophie.
Si tu as de l'authentification fait par ton frontal, il faut que l'état soit répliqué sur tous tes fronts de la bonne manière. C'est complexe. Si il y a un peu de gestion de session sur les fronts, pareil.
[^] # Re: My 2 cents
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 6.
Tout à fait, je présentais juste ce service qui avait ce type de fonctionnement, mais n'importe quel démon est le bienvenu !
Bzzz ! Tu fais l'erreur de penser « local vs. global » : tu as inscrits dans la définition de ton service le périmètre qu'il aura. C'est gravé dans le marbre, et dès que ton périmètre devra changer, tu seras dans la merde. En IPv6, tu mets ton service « sur le réseau » (d'où le titre de ce journal), et tu définis après (et de préférence aux extrémités, pas dans le réseau) sa portée.
Et tu devras te taper des problématiques de routage à la con au moindre changement topologique. C'est vu et revu.
[^] # Re: L’avenir et le passé
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 6.
Effectivement, et la conclusion c'est qu'il ne faut pas faire de conntrack. C'est pour moi le principal obstacle à la prolifération d'IPv6 : arrêter avec les politiques de soit-disant sécurité débiles, et ne pas faire de stateful! C'est ce qui a tué l'Internet v4 hors Web, et ce qui tuera IPv6 dans l'œuf si on fait la même connerie.