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.
Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception.
OK, donc tu veux inclure un service intermédiaire, et ça n'est pas dans la philosophie d'IP : du coup oui, mets ton firewall applicatif. IP ne l'interdit pas, au contraire, mais ne peut pas remplacer effectivement une standardisation d'applicatif type request-response.
Non, la première RFC d'IPsec date de 1998 alors que SSL1.0 date de 1994,
mais bon comment tu adresse un serveur IPsec+SMTP ?
Il n'y a effectivement pas de modèle de CA global associé à IPsec, donc « tu ne peux pas » pour le cas généraliste qu'on voit avec TLS.
Oui tu utilise un reverse proxy donc.
Non, pas « proxy », juste parler TLS directement. Je précise car souvent le reverse-proxy implique d'avoir à différencier sur le hostname, avec SNI et consort, alors qu'ici on peut éviter ça.
Je n'ai pas était très précis. Mais tu peux vouloir avoir des log qui inclus l'information métier et donc doit décoder la 7ème couche. Tu peux imaginer vouloir réagir à ces informations comme ne pas router le trafic s'il y a trop d'erreurs avant.
Comme pour le premier cas, on ne va effectivement pas demander à IP de faire de l'applicatif. Ce que propose IP, par contre, c'est que le routage soit fait à la « bonne » couche.
Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».
Prendre comme hypothèse que ça a était fais une fois est un peu plus simple que de considérer que ce sera fais pour chaque nouveaux services.
Pas d'accord : pour ton reverse, il va falloir que tu fasses l'adressage (et éventuellement le nommage) de toutes façons, mais tu le feras avec des couches d'IPv4 voire du NAT, et autre. Et dès qu'il faudra « bouger » tes backend, ça va être la merde parce que ton archi d'adressage est complètement sclérosée ; tu vas aller vers des solutions à la con genre VXLAN et consort (quoique ça doit être has-been aujourd'hui). Tout mettre au niveau d'IP avec de l'adressage globale découple complètement le routage de ton applicatif, et c'est ça qui simplifie énormément la vie. On ne voit pas les désavantages d'IPv4 parce que ses restrictions ont tellement été internalisées par tous que personne ne penserait à bouger un service : tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie ! Alors que ça serait tellement évident en IPv6…
Et je ne parle même pas du setup de ton reverse-proxy : vu que c'est un SPOF, et qu'il doit être dimensionné « costaud », tu complexifies beaucoup plus que « juste un routeur ». Certes, trouver quelqu'un qui saura configurer correctement un routeur en IPv6 aujourd'hui est malheureusement pas si facile, mais j'espère que ça changera.
Mais l'argument disant que les gens l'ont pensé comme ça il y a 30 ans donc on doit continuer à le faire n'est pas très convainquant.
Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.
En fait quand je vois la facilité de mise en place
Je suis désolé mais de ce que j'ai vu (OK, subjectif), ça n'est vraiment pas si simple. Oui, les solutions sont mieux intégrées que le genre d'archi que je propose, mais ce ne sont « que » des problématique d'intégration qui pourraient être corrigées relativement facilement si on se bougeait un peu le cul. Derrière, quand il s'agit de gérer la scalabilité du bouzin, c'est une autre histoire.
et comme de très grosses infrastructures s'en servent, je me dis que pour mes besoins ça doit le faire sans trop se poser de question.
Les gros y mettent de gros moyens, et forcément ça marche. Mais le genre de truc que je propose marche même à très petite échelle, avec des moyens matériels très réduits. Ça n'est pas forcément vendeur car ça ne pousse pas à la consommation, mais c'est la manière que je préfère.
Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :
1. le loadbalancing est fait plutôt tardivement ce qui réduit théoriquement les performance
Niveau perfs, je ne doute pas que vu comment c'est tuné aujourd'hui (d'autant plus si tu parles du très bon haproxy), ça ne doit pas avoir un impact énorme.
le nombre de connexion
Là c'est clairement un des avantages d'IPv6 : tu n'as pas de limite de scalabilité. Donc ton infra marche bien tant que tu es en-dessous de la limite (et ça suffit à plein de monde, certes), mais tu sais que quand tu l'atteins t'es dans la merde.
lors de l'ajout/suppression de service, il faut pouvoir reconfigurer à chaud
Effectivement.
Mais ça ne sont pas les désavantages les plus flagrants que je voyais : je pense plutôt à la complexité de la machine (applicatif spécialisé complet versus kernel + userspace « basique »), les différentes possibilités de configuration (= très simple en IP), le SPOF que ça constitue, ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP), etc.
Je vais le faire en plus court, pour montrer que ça n'est pas si difficile que ça. Il y a sûrement un manque d'intégration dans nos systèmes actuels, et c'est très triste vu l'ancienneté du protocole, mais ça se fait bien.
Donc on ajoute une IP (la manière de le faire persister dépend du système, je te laisse voir) :
ip -6 addr add 2001:db8:0:42::497 dev eth0
Ajoute une entrée dans le DNS ; je n'ai jamais pratiqué, mais avec le standard "nsupdate" ça pourrait donner (non testé) :
Et déjà tu as le service qui tourne (après un "service openbsd-inetd reload"), mais non configuré. La conf je ne la répète pas, et pour du contrôle d'accès, dans /etc/hosts.allow :
Et c'est tout. Tu as tout ce qu'il faut depuis la conf réseau, DNS jusqu'au service, en trois lignes, avec du contrôle d'accès en deux lignes de plus. Sans aucune hypothèse autre qu'un réseau « Internet » sur un OS « Unix ».
Raison inconnue, ça veut bien dire que tu n'es pas sûr que le problème ne viens pas du système de fichiers ou d'un autre processus?
Je suis à peu près sur que ça n'était pas de la corruption de FS (pas d'interruption brutale de processus ni de reboot), mais plutôt des histoires « classiques » de téléchargement interrompu ou de mirroir en cours de modification qui ont laissé le cache dans en état bâtard. Mais ça n'est qu'une supposition.
Quand tu veux une archi qui n'est pas simplement directement client-serveur, ou alors que tu veux pouvoir ouvrir des canaux de communication annexes (genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux), ou quand tu veux un contrôle plus fin des erreurs, voire même simplement quand ton protocole est un peu plus complexe que juste du question-réponse en une fois.
syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Oui.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne?
Je dirais que les entrées-sorties standard sont faites pour l'interaction directe avec ton interlocuteur ; syslog a plutôt un but de log à destination d'autres programmes ou personnes. Donc je ne trouve pas ça illogique.
Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge
Si la personne qui peut mieux diagnostiquer le problème n'est pas l'interlocuteur du programme, je pense que ça vaut quand même le coup de passer par syslog. En fait, selon mon intuition, un log est vraiment un flux différent de l'applicatif, et doit pouvoir avoir plusieurs destinations, et va donc mieux dans un descripteur particulier. Mais c'est juste une impression, je ne suis pas un spécialiste des logs.
inetd est un outil pour économiser les ressources: il lance et éteins des daemons selon la demande.
C'est une des raisons. L'autre est qu'il gère entièrement les aspects réseau, et que le démon final n'a qu'à se servir des entrées-sorties standard. Ça a l'avantage de la simplicité, mais si on veut un truc un peu mieux intégré dans le réseau, il faudra passer par autre chose.
mais est-ce maintenant vraiment le plus long de nos jours, de charger le daemon depuis le disque dur (voire le cache de l'OS)?
Pour ton information, ce type de fonctionnement est présenté dans systemd comme une « révolution » pour ce qui est de son option de « démarrage par socket ». Donc ça doit être une considération encore d'actualité aujourd'hui.
Est-ce si coûteux de garder le processus en mémoire (en supposant qu'il soit capable de se nettoyer de lui-même lors de la fermeture d'une connexion, bien sûr) ou en swap?
Non effectivement, je ne pense pas que ça soit si énorme pour des « petits » démons (qui sont ironiquement la cible d'inetd, en général). Note que certains qui n'ont pas compris l'intérêt du swap le suppriment et peuvent donc être amenés à penser que « nettoyer » un processus ainsi est une bonne idée ; je pense qu'ils n'ont pas bien compris.
Du coup, il sert a quoi, inetd?
Pour moi c'est en priorité pour le simplicité de stdin/stdout, cf. plus haut, c'est tout.
Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
TLS offloading,
Je ne suis pas sûr de ce que tu proposes, mais la manière historique de faire c'est IPsec ; sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
logging,
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…
load balancing,…
Le load-balancing est une invention inutile dans l'archi que je présente. Ou plutôt, il est « naturel » dans mon cas.
mais tu dois faire des manipulations « système » (avoir ton DNS, ajouter une interface à ta machine, t'assurer que ton routage fonctionne bien,…). Tester et reproduire tout ça n'est pas trivial.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Bien sûr, tout n'est pas rose : la situation actuelle du « blocage » du nommage et du routage — qui amène à empêcher tout déploiement « correct » de service sur Internet — est due à un problème de répartition des responsabilités. On sait difficilement en entreprise ou à la maison déléguer une partie du DNS ou du routage à d'autres : il y a les « responsables du DNS » et les « responsables du routage » qui les gèrent de manière fermée, et qui sont parfois si obtus qu'on préfère passer par d'autres moyens pour étendre le réseau de processus que d'utiliser la manière « standard ».
mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.
Et puis de ce que j'ai compris de la description de pacserve, c'est qu'il permet de découvrir le proxy « automagiquement » sur le LAN ; c'est faisable avec squid-deb-proxy-client en ce qui concerne ta suggestion de proxy APT, et il utilise la découverte de service locale par mDNS (DNS-SD), qui utilise les enregistrements SRV.
Encore une fois, si tu raisonnes en argent, tu ne peux que arriver à des résultats débiles vu la manière dont est structurée l'économie aujourd'hui. Forcément, si tu prends comme alternative des choses qui ignorent toutes les externalités négatives comme la pollution, la débilité du système (rapport à la cohésion sociale, etc), la dette financière cachée, etc, l'équation est beaucoup moins favorable à ton objet jetable chinois.
Une solution pérenne qui inciterait à la production perenne serait la location et le contrat de maintenance.
Peut-être. Je ne sais pas si on peut se permettre d'avoir chacun une machine à laver réparable dans le monde ; peut-être qu'il faudra mutualiser, et on appellerait ça des « laveries ». Ou peut-être pas : le « coût du travail » dépend tellement de ce qu'on choisi de prioriser… Si on avait un réseau de réparateurs, comme évoqué plus haut, des objets standardisés, et qu'on se passait à la place de déplacements en avion et des grands services de divertissement débiles, le « coût » serait drôlement différent.
Il y a bien quelques licences approuvée par l'OSI qui ne sont pas libre, mais quasi-personne ne les utilisent et quasi-personne ne considère que c'est Open Source à part quelques perdu de l'OSI
Rho putain je vais l'encadrer celle-là : Zorro toujours droit dans ses bottes qui ravale son chapeau… bravo !
Faut pas mélanger toutes les discutions, c'est déjà bien suffisamment le bazar pour tout suivre :)
Je cite Zenitram :
qui a de fortes chances d'être "non compatible" avec les idées […] de l'auteur de l'appel à l'aide pour l'Humanité
Il parle de moi, là.
C'est d'attaquer sur une intro hyper générale (Soutenons la presse libre et indépendante) et que tout le reste du journal ce concentre sur le cas hyper-particulier de l'huma.
Tu as dû sauter le titre de mon journal…
Forcément, ceux qui lisent de travers ne comprennent pas et moinssent : génial.
Oui, Google est un gentil participant dans ce monde idéal qu'est le marché, qui est financé de manière honnête et réagit complètement rationnellement et c'est bien normal.
Bien sûr que le pouvoir de Google, il le détient également de ses bons services (au sens technique du terme) et de la confiance aveugle que les gens lui accordent. Ça ça n'était pas ironique. J'en suis très bien conscient.
Mais il faut savoir reconnaître les entités qui sont dangereuses pour notre démocratie. Google en fait partie, malgré tous ses à-côtés philanthropiques mignons pro-libre.
Arrête de jouer la méta-argumentation bidon, ça te fait plusser en ayant l'air d'un cador, mais tu mines le monde humain qui ne se base pas que sur les relations monétaires de marché.
Tu fais partie des idiots utiles du capitalisme libéral moderne, qui ne comprend pas les équilibres de pouvoir du monde actuel. C'est triste que la majorité soit comme toi, aveugle de ces manipulations.
En cherchant rapidement, et en excluant les journaux spécialisés :
La fermeture de Google News en Espagne a eu lieu il y a 5 ans, et est évoquée comme référence dans l'article que je cite ; je voulais parlais de la réitération de ces menaces pour tous les journaux européens suite à la « tax-link » discutée en ce moment en Europe.
Tu délires complètement, homme de paille à gogo, c'est pour ça qu'on ne peut pas débattre. Je suis tout à fait pour que des gens financent Présent ou Minutes, sans problème, même si ça n'est pas mes idées. Tu te fais une idée des « gauchos » que tu veux dégommer en les caricaturant pour mieux les tuer. Tu fais partie des promoteurs de la division qui tuent la liberté de s'exprimer, justement.
He pointed out the last time a government attempted to charge Google for links, in 2014 in Spain, the company responded by shutting down Google News in the country. […]
“We would not like to see that happen in Europe,” said Gingras.
« Ça serait dommage que vos beaux journaux disparaissent, quand même », ça ne sonne pas mafieux à mort comme truc ? En as-tu entendu parler sur un média français ? C'est ça que nous réserve un avenir où les journaux sont la propriété de milliardaires.
[^] # 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.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 2. Dernière modification le 06 février 2019 à 17:01.
OK, donc tu veux inclure un service intermédiaire, et ça n'est pas dans la philosophie d'IP : du coup oui, mets ton firewall applicatif. IP ne l'interdit pas, au contraire, mais ne peut pas remplacer effectivement une standardisation d'applicatif type request-response.
Je disais « historique » pour dire classiquement associée avec IP. Et si je chipotte, IPsec c'est 1995 https://tools.ietf.org/html/rfc1825.
Il n'y a effectivement pas de modèle de CA global associé à IPsec, donc « tu ne peux pas » pour le cas généraliste qu'on voit avec TLS.
Non, pas « proxy », juste parler TLS directement. Je précise car souvent le reverse-proxy implique d'avoir à différencier sur le hostname, avec SNI et consort, alors qu'ici on peut éviter ça.
Comme pour le premier cas, on ne va effectivement pas demander à IP de faire de l'applicatif. Ce que propose IP, par contre, c'est que le routage soit fait à la « bonne » couche.
Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».
Pas d'accord : pour ton reverse, il va falloir que tu fasses l'adressage (et éventuellement le nommage) de toutes façons, mais tu le feras avec des couches d'IPv4 voire du NAT, et autre. Et dès qu'il faudra « bouger » tes backend, ça va être la merde parce que ton archi d'adressage est complètement sclérosée ; tu vas aller vers des solutions à la con genre VXLAN et consort (quoique ça doit être has-been aujourd'hui). Tout mettre au niveau d'IP avec de l'adressage globale découple complètement le routage de ton applicatif, et c'est ça qui simplifie énormément la vie. On ne voit pas les désavantages d'IPv4 parce que ses restrictions ont tellement été internalisées par tous que personne ne penserait à bouger un service : tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie ! Alors que ça serait tellement évident en IPv6…
Et je ne parle même pas du setup de ton reverse-proxy : vu que c'est un SPOF, et qu'il doit être dimensionné « costaud », tu complexifies beaucoup plus que « juste un routeur ». Certes, trouver quelqu'un qui saura configurer correctement un routeur en IPv6 aujourd'hui est malheureusement pas si facile, mais j'espère que ça changera.
Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.
Je suis désolé mais de ce que j'ai vu (OK, subjectif), ça n'est vraiment pas si simple. Oui, les solutions sont mieux intégrées que le genre d'archi que je propose, mais ce ne sont « que » des problématique d'intégration qui pourraient être corrigées relativement facilement si on se bougeait un peu le cul. Derrière, quand il s'agit de gérer la scalabilité du bouzin, c'est une autre histoire.
Les gros y mettent de gros moyens, et forcément ça marche. Mais le genre de truc que je propose marche même à très petite échelle, avec des moyens matériels très réduits. Ça n'est pas forcément vendeur car ça ne pousse pas à la consommation, mais c'est la manière que je préfère.
Niveau perfs, je ne doute pas que vu comment c'est tuné aujourd'hui (d'autant plus si tu parles du très bon haproxy), ça ne doit pas avoir un impact énorme.
Là c'est clairement un des avantages d'IPv6 : tu n'as pas de limite de scalabilité. Donc ton infra marche bien tant que tu es en-dessous de la limite (et ça suffit à plein de monde, certes), mais tu sais que quand tu l'atteins t'es dans la merde.
Effectivement.
Mais ça ne sont pas les désavantages les plus flagrants que je voyais : je pense plutôt à la complexité de la machine (applicatif spécialisé complet versus kernel + userspace « basique »), les différentes possibilités de configuration (= très simple en IP), le SPOF que ça constitue, ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP), etc.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 10.
Je vais le faire en plus court, pour montrer que ça n'est pas si difficile que ça. Il y a sûrement un manque d'intégration dans nos systèmes actuels, et c'est très triste vu l'ancienneté du protocole, mais ça se fait bien.
Donc on ajoute une IP (la manière de le faire persister dépend du système, je te laisse voir) :
Ajoute une entrée dans le DNS ; je n'ai jamais pratiqué, mais avec le standard "nsupdate" ça pourrait donner (non testé) :
Ajoute dans /etc/inetd.conf :
Et déjà tu as le service qui tourne (après un "service openbsd-inetd reload"), mais non configuré. La conf je ne la répète pas, et pour du contrôle d'accès, dans /etc/hosts.allow :
Et c'est tout. Tu as tout ce qu'il faut depuis la conf réseau, DNS jusqu'au service, en trois lignes, avec du contrôle d'accès en deux lignes de plus. Sans aucune hypothèse autre qu'un réseau « Internet » sur un OS « Unix ».
[^] # Re: apt-cacher-ng
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Je suis à peu près sur que ça n'était pas de la corruption de FS (pas d'interruption brutale de processus ni de reboot), mais plutôt des histoires « classiques » de téléchargement interrompu ou de mirroir en cours de modification qui ont laissé le cache dans en état bâtard. Mais ça n'est qu'une supposition.
[^] # 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. Dernière modification le 06 février 2019 à 14:26.
Quand tu veux une archi qui n'est pas simplement directement client-serveur, ou alors que tu veux pouvoir ouvrir des canaux de communication annexes (genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux), ou quand tu veux un contrôle plus fin des erreurs, voire même simplement quand ton protocole est un peu plus complexe que juste du question-réponse en une fois.
Oui.
Je dirais que les entrées-sorties standard sont faites pour l'interaction directe avec ton interlocuteur ; syslog a plutôt un but de log à destination d'autres programmes ou personnes. Donc je ne trouve pas ça illogique.
Si la personne qui peut mieux diagnostiquer le problème n'est pas l'interlocuteur du programme, je pense que ça vaut quand même le coup de passer par syslog. En fait, selon mon intuition, un log est vraiment un flux différent de l'applicatif, et doit pouvoir avoir plusieurs destinations, et va donc mieux dans un descripteur particulier. Mais c'est juste une impression, je ne suis pas un spécialiste des logs.
[^] # 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é à 3.
C'est une des raisons. L'autre est qu'il gère entièrement les aspects réseau, et que le démon final n'a qu'à se servir des entrées-sorties standard. Ça a l'avantage de la simplicité, mais si on veut un truc un peu mieux intégré dans le réseau, il faudra passer par autre chose.
Pour ton information, ce type de fonctionnement est présenté dans systemd comme une « révolution » pour ce qui est de son option de « démarrage par socket ». Donc ça doit être une considération encore d'actualité aujourd'hui.
Non effectivement, je ne pense pas que ça soit si énorme pour des « petits » démons (qui sont ironiquement la cible d'inetd, en général). Note que certains qui n'ont pas compris l'intérêt du swap le suppriment et peuvent donc être amenés à penser que « nettoyer » un processus ainsi est une bonne idée ; je pense qu'ils n'ont pas bien compris.
Pour moi c'est en priorité pour le simplicité de stdin/stdout, cf. plus haut, c'est tout.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 8.
Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
Je ne suis pas sûr de ce que tu proposes, mais la manière historique de faire c'est IPsec ; sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…
Le load-balancing est une invention inutile dans l'archi que je présente. Ou plutôt, il est « naturel » dans mon cas.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Bien sûr, tout n'est pas rose : la situation actuelle du « blocage » du nommage et du routage — qui amène à empêcher tout déploiement « correct » de service sur Internet — est due à un problème de répartition des responsabilités. On sait difficilement en entreprise ou à la maison déléguer une partie du DNS ou du routage à d'autres : il y a les « responsables du DNS » et les « responsables du routage » qui les gèrent de manière fermée, et qui sont parfois si obtus qu'on préfère passer par d'autres moyens pour étendre le réseau de processus que d'utiliser la manière « standard ».
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.
[^] # Re: Autre besoin: pacserve
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Et puis de ce que j'ai compris de la description de pacserve, c'est qu'il permet de découvrir le proxy « automagiquement » sur le LAN ; c'est faisable avec squid-deb-proxy-client en ce qui concerne ta suggestion de proxy APT, et il utilise la découverte de service locale par mDNS (DNS-SD), qui utilise les enregistrements SRV.
[^] # Re: Proposition n°1: la production doit être durable
Posté par benoar . En réponse au journal Cahier de doléances. Évalué à 1.
Encore une fois, si tu raisonnes en argent, tu ne peux que arriver à des résultats débiles vu la manière dont est structurée l'économie aujourd'hui. Forcément, si tu prends comme alternative des choses qui ignorent toutes les externalités négatives comme la pollution, la débilité du système (rapport à la cohésion sociale, etc), la dette financière cachée, etc, l'équation est beaucoup moins favorable à ton objet jetable chinois.
Peut-être. Je ne sais pas si on peut se permettre d'avoir chacun une machine à laver réparable dans le monde ; peut-être qu'il faudra mutualiser, et on appellerait ça des « laveries ». Ou peut-être pas : le « coût du travail » dépend tellement de ce qu'on choisi de prioriser… Si on avait un réseau de réparateurs, comme évoqué plus haut, des objets standardisés, et qu'on se passait à la place de déplacements en avion et des grands services de divertissement débiles, le « coût » serait drôlement différent.
C'est un choix de société, c'est tout.
[^] # Re: Pourquoi je viendrais ? J'ai pas compris !
Posté par benoar . En réponse au journal En Francilie, on aime les oignons !. Évalué à 1.
Rho putain je vais l'encadrer celle-là : Zorro toujours droit dans ses bottes qui ravale son chapeau… bravo !
[^] # Re: Et Présent ?
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à 1. Dernière modification le 01 février 2019 à 12:27.
Je cite Zenitram :
Il parle de moi, là.
Tu as dû sauter le titre de mon journal…
Forcément, ceux qui lisent de travers ne comprennent pas et moinssent : génial.
[^] # Re: Ho le troll...
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à 1.
Oui, Google est un gentil participant dans ce monde idéal qu'est le marché, qui est financé de manière honnête et réagit complètement rationnellement et c'est bien normal.
Bien sûr que le pouvoir de Google, il le détient également de ses bons services (au sens technique du terme) et de la confiance aveugle que les gens lui accordent. Ça ça n'était pas ironique. J'en suis très bien conscient.
Mais il faut savoir reconnaître les entités qui sont dangereuses pour notre démocratie. Google en fait partie, malgré tous ses à-côtés philanthropiques mignons pro-libre.
Arrête de jouer la méta-argumentation bidon, ça te fait plusser en ayant l'air d'un cador, mais tu mines le monde humain qui ne se base pas que sur les relations monétaires de marché.
[^] # Re: Ho le troll...
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à -2.
Tu fais partie des idiots utiles du capitalisme libéral moderne, qui ne comprend pas les équilibres de pouvoir du monde actuel. C'est triste que la majorité soit comme toi, aveugle de ces manipulations.
[^] # Re: Ho le troll...
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à 0.
La fermeture de Google News en Espagne a eu lieu il y a 5 ans, et est évoquée comme référence dans l'article que je cite ; je voulais parlais de la réitération de ces menaces pour tous les journaux européens suite à la « tax-link » discutée en ce moment en Europe.
[^] # Re: Et Présent ?
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à 2.
Tu délires complètement, homme de paille à gogo, c'est pour ça qu'on ne peut pas débattre. Je suis tout à fait pour que des gens financent Présent ou Minutes, sans problème, même si ça n'est pas mes idées. Tu te fais une idée des « gauchos » que tu veux dégommer en les caricaturant pour mieux les tuer. Tu fais partie des promoteurs de la division qui tuent la liberté de s'exprimer, justement.
[^] # Re: Ho le troll...
Posté par benoar . En réponse au journal Aider le quotidien L'Humanité. Évalué à 3.
Pour ceux qui veulent une référence : https://www.theguardian.com/technology/2018/nov/18/google-news-may-shut-over-eu-plans-to-charge-tax-for-links
« Ça serait dommage que vos beaux journaux disparaissent, quand même », ça ne sonne pas mafieux à mort comme truc ? En as-tu entendu parler sur un média français ? C'est ça que nous réserve un avenir où les journaux sont la propriété de milliardaires.