Re: [FRnOG] [MISC] Tiens, STARLINK is out.
On 06/04/2022 07:56, Yoann QUERET wrote: On 06/04/2022 07:37, Mickael Monsieur wrote: On sait si starlink a déjà cessé d’émettre ? J'ai un accès Starlink en Haute-Savoie qui fonctionne toujours Et j'en ai un en Haute-Loire qui fonctionne encore pour le moment. et je me posais la question des conséquences de ce retrait des autorisations et des échéances.. Ca me semble difficile de couper le service en France uniquement. Peut-être en fonction du lieu d'installation ? Ça me semble pas si difficile, les sanctions vont tomber sur StarLink si elle continue d'émettre alors qu'elle n'a plus l'autorisation. Quid de notre situation légale en tant qu'usagers ? Est-ce qu'on va payer aussi si on continue d'utiliser notre parabole propriétaire aux paramètres mystiques ? Est-ce qu'on peut prétendre qu'on ne sait pas ce qu'on fait ? -- Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Tiens, STARLINK is out.
On 06/04/2022 08:31, Rémy Grünblatt wrote: Sur le sujet, autant mettre le lien vers la décision elle même: http://www.conseil-etat.fr/fr/arianeweb/CE/decision/2022-04-05/455321 Pour résumer... Ce qui a été retenu par les chambres du Conseil d'État, c'est que l'ARCEP n'a pas respecté le V de l'article L31-1 [1]. Sauf qu'ils ne disent pas en quoi l'ARCEP de l'a pas respecté. Comme l'a dit Stéphane Rivière, est-ce qu'on considère que ça a une incidence importante parce que le service de Starlink marche beaucoup mieux que les offres ADSL à la campagne ? Si c'est juste ça, il suffit à l'ARCEP de réaliser une consultation publique, et dans deux mois Starlink ré-obtient ses autorisations. J'ai bien suivi ? Pendant ce temps, si Starlink maintient son service, est-ce que l'État va gaspiller des resources pour aller chercher quelques k€ d'amende dans un pays étranger ? Je ne dis pas qu'il ne faut pas le faire pour la forme. Mais grossièrement ça ressemble à une grosse mascarade. Est-ce qu'on a sollicité le publique quand l'électricité s'est démocratisée ? Est-ce qu'on a sollicité le publique quand les micro-ondes sont devenus des équipements indispensables des cuisines modernes ? Est-ce qu'on a sollicité le publique quand on a construit des trottoirs dans des villages paumés et peu fŕequentés de Haute-Loire ? (Bon, ça en vrai c'est possible, j'imagine que personne a dit non tellement l'idée était absurde de base) [1]: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43545201 -- Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nombreuses coupures de fibres optiques en France
On 29/04/2022 09:16, Toussaint OTTAVI wrote: Le 29/04/2022 à 08:27, David Ponzone a écrit : (et niveau empreinte CO2 non plus probablement). Là, par contre, je ne vois pas comment un paquet qui fait Ajaccio-Ajaccio pourrait consommer plus de CO2 que le même paquet qui monte à Paris, fait un petit tour sur le périph' optique, puis redescend. J'ai même eu des cas où çà passait... par la Nouvelle-Zélande ! On est vendredi, mais je prend ça au premier degrés quand même, car c'est un sujet très intéressant. Est-ce qu'il y a eu des études sur l'impact écologique des télécommunications terrestres (cuivre ou fibre) ? D'un point de vue purement écologique : Je vois la centralisation comme un point positif, pour la mutualisation des ressources et la possibilité de ne pas trop surdimensionner les capacités (quand tout passe par un point, c'est plus facile de dimensionner pour 100% de capacité plutôt que quand tu n'es pas sûr de par quel chemin vont passer tes paquets). Par contre je ne vois pas en quoi un paquet consommerait plus ou moins en fonction de la distance. Traverser 200km ou 1km, ça devrait revenir au même, théoriquement. Physiquement et techniquement on a forcément des noeuds sur notre chemin, et chaque noeud consomme un peu, que ce soit un simple répéteur de signal ou un routeur. Dites moi si je me trompe. Si je ne me trompe pas, alors on peut réduire le problème à : "une route avec plus de noeuds consommera plus qu'une route avec moins de noeuds, quelle que soit sa distance physique". Et dans ce cas, je me pose une question à laquelle je n'ai pas de réponse : à quoi ressemblerait un maillage plus fin ? Je n'ai certes pas de réponse à cette question, mais je me dis quand même que pour passer à un maillage plus fin, il suffit d'interconnecter d'avantage les noeuds, sans avoir nécessairement besoin d'en ajouter. Est-ce naïf ? Et, pour "l'efficience", est-ce qu'on ne pourrait pas conserver des longues lignes de cuivre/fibre qui permettent de "court-circuiter" une série de plus petites routes ? (à la façon dont fonctionne le réseau routier ? Pour faire un Paris -> Lyon, si on veut être efficace, on ne passe pas par des départementales) Enfin, mais ça c'est tellement une évidence que je ne devrais même pas le dire. Avoir plus de matériel est moins "écologique" qu'avoir moins de matériel (impact écologique de la fabrication, toussa toussa). Et poser un câble, qu'il soit en cuivre ou en fibre, est coûteux en énergie, et demande de traverser des écosystèmes, c'est à prendre en compte dans le calcul de l'impact écologique. -- - Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [ALERT] Incident elec Netcenter Vénissieux
On 09/06/2023 17:36, Renaud wrote: On 09/06/2023 17:05, Stéphane Rivière wrote: [../..] Quand on voit que même Google se vautre suite à un seul incident dans un seul DC, il y a de quoi être circonspect... +1 Personne n'est à l'abri. Enfin, on peut imaginer que, désormais, les onduleurs et les batteries au "fond du jardin", comme les GE, ça va devenir la règle... [../..] Vivement le datacenterless, il y a un business model d'avenir là-dessus! J'aurais juré que ça existait déjà et que ça s'appellait "Le Cloud". --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] [FRnOG] [ALERT] Incident elec Netcenter Vénissieux
On 09/06/2023 17:49, David Ponzone wrote: Y a du Cloud qui est pas dans un DC ? Ou alors il faut pratiquer le multi-cloud, en s’assurant de pas dépendre des mêmes DC. Le 9 juin 2023 à 17:45, Léo El Amri via frnog a écrit : On 09/06/2023 17:36, Renaud wrote: On 09/06/2023 17:05, Stéphane Rivière wrote: [../..] Quand on voit que même Google se vautre suite à un seul incident dans un seul DC, il y a de quoi être circonspect... +1 Personne n'est à l'abri. Enfin, on peut imaginer que, désormais, les onduleurs et les batteries au "fond du jardin", comme les GE, ça va devenir la règle... [../..] Vivement le datacenterless, il y a un business model d'avenir là-dessus! J'aurais juré que ça existait déjà et que ça s'appellait "Le Cloud". En tant que """développeur""", vu comment on me le vend, je croyais que c'était magique et qu'il n'y avait pas d'ordinateur derrière "Le Cloud". Pardon je pensais qu'on était trolldi. Plus sérieusement : Je constate que le multi-cloud ou multi-DC est déjà une pratique assez courante, en m'appuyant sur ma propre expérience chez des clients. Ils avaient pourtant soit voué un culte à l'Amazone du Service de la Toile, soit vendu leur âme au grand Azure, mais la disponibilité était une caractéristique recherchée lorsqu'elle n'était pas déjà vendue clef en main. Et depuis que je bosse (2015), il a toujours été question de réplication sur des lieux différents en ce qui concerne le stockage (et ça pour le coup c'est assez bien supporté par tous les cloud grand-publique que je connais (GCP, AWS, Azure et Hetzner). Pour finir, le DC-less est déjà un peu ce que propose IPFS[1] et autres. Avec ces trucs là, la planète entière devient un DC plus ou moins résilient. Je me souviens qu'il existait aussi un truc similaire à IPFS mais pour du calcul plutôt que pour du stockage, utilisé par un projet de recherche scientifique sur le pliage des protéines et qui avait le mot "Mesh" dans le nom il me semble, est-ce que quelqu'un voit ce que c'est ? [1] : https://ipfs.tech/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] [FRnOG] [ALERT] Incident elec Netcenter Vénissieux
On 09/06/2023 18:42, julien soula wrote: On Fri, Jun 09, 2023 at 06:05:58PM +0200, Léo El Amri via frnog wrote: [.../...] Je me souviens qu'il existait aussi un truc similaire à IPFS mais pour du calcul plutôt que pour du stockage, utilisé par un projet de recherche scientifique sur le pliage des protéines et qui avait le mot "Mesh" dans le nom il me semble, est-ce que quelqu'un voit ce que c'est ? folding@home ? (mais y a pas "Mesh" pour le coup) a+, Merci ! Ça ne me dit rien, mais grace à ça je crois que j'ai retrouvé ce dont je parlais. Je crois que c'est World Community Grid [1]. Par contre il n'y a ni projet de pliage de protéine (ou alors il y a eu un "sponsoring" pendant quelques temps), ni "Mesh" dans le nom. Mais comme ça date d'il a plus de 15 ans maintenant, ma mémoire doit me faire défaut. Enfin, là où je voulais en venir, c'est que avec IPFS combiné à un système comme WCG (en plus générique), on a du DC-less qui répond à presque tous les besoins non-réseau. Reste que les télécoms pourront difficilement se passer des DC, en tous cas en France, tant qu'on aura pas pris des mesures drastiques de décentralisation de l'architecture du réseau, comme nous en discutions sur la liste il y a quelques mois. [1] : https://www.worldcommunitygrid.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Gandi, c'est fini...
On 14/06/2023 14:34, Arnaud Launay wrote: Le Wed, Jun 14, 2023 at 01:48:30PM +0200, David Touitou a écrit: Ceux qui ne sont pas chez Gandi, où êtes-vous ? Bookmyname. Une bonne interface années 90, parfaitement fonctionnelle, il existe une API, les tarifs sont raisonnables. Pour les fonctionnalités avancées, pas sûr: c'est un registrar, pas un FSI. PI, BookMyName est le nom commercial de vente de NDD de Online (maintenant "Scaleway"). Je n'ai jamais été client NDD chez eux depuis la création de Scaleway, mais je pense qu'il y a plus de fonctionnalités sur l'interface de Scaleway (https://www.scaleway.com/fr/domains-and-dns/) que sur l'interface de BookMyName. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Gandi, c'est fini...
On 14/06/2023 16:52, Bertrand FRUCHET via frnog wrote: - les mails chez Powermail ( un "petit" très efficace car spécialisé dans cette activité) Est-ce qu'il est possible d'avoir un pointeur vers ce "Powermail" ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Gandi, c'est fini...
C'est vendredi chez DuckDuckGo apparemment... https://duckduckgo.com/?q=powermail&t=h_&ia=web PS : En fait j'ai testé la recherche en français, et ça apparait en premier résultat dans ce cas. Donc c'est un PEBKAC. On 14/06/2023 17:46, David Ponzone wrote: Euhh, https://www.powermail.fr <https://www.powermail.fr/> non ? C’est vendredi ? :) Le 14 juin 2023 à 17:42, Léo El Amri via frnog a écrit : On 14/06/2023 16:52, Bertrand FRUCHET via frnog wrote: - les mails chez Powermail ( un "petit" très efficace car spécialisé dans cette activité) Est-ce qu'il est possible d'avoir un pointeur vers ce "Powermail" ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Gandi, c'est fini...
On 16/06/2023 18:02, Noryungi wrote: Laisse tomber tout de suite cette histoire de chatbot. Mais le reste ça te va ?! Le 16/06/2023 à 15:01, Victor UETTWILLER a écrit : En soit, la meilleur idée serait d'ouvrir ce service avec une société qui faisait de la presta de NDD avec Gandi et qui part. Faire une sorte de réunion de société mécontent de l'augmentation fulgurante des prix de Gandi. Niveau code, l'abonnement Chat-GPT 4 coûte dans les $24/mois non ? Ça va pas revenir bien cher. Niveau doc, il y a tout ce qu'il faut déjà en ligne, là encore j'ai pété, et on se fait une base standard. Niveau support, pour le chatbot j'aimerais bien tenter d'entrainer un guanaco 65B pour ça, mais il y en a pour 25k€ de matos minimum et 2kW donc c'est peut-être une fausse bonne idée. On n'a qu'à faire un offshore en Tunisie (ils sont en dèche) si vous savez pas gérer vous-même. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Gandi, c'est fini...
On 18/06/2023 22:38, David Ponzone wrote: Coop alors que n’importe qui ici peut se monter un mailcow en 15 min ? Je me demande si c’est pas un peu overkill. Pour le moment ce qui a été proposé c'est de lancer un service NDD + mailbox qui marche et qui soit vraiment NoBullshit (Désolé Gandi mais vous avez perdu le droit d'utiliser ce slogan). Sauf que c'est accompagné de beaucoup de problèmes déjà évoqués, dont le plus gros, à mon avis, qui est qu'on s'adresse à des clients non-techniques qui vont solliciter le support pour rien (et qui coûtera probablement le plus cher, de loin). Sinon on peut lancer un service uniquement NDD, avec serveur de noms primaire fournit quand même, mais dans ce cas il y a peu de chances de trouver des clients puisque les seuls intéressés seraient des individus tech, ou des sociétés qui ont besoin de sous-traiter cette activité (genre les boites d'hébergement mutualisé, ou simplement les sous-traitants d'autres boites qui ne font pas de web). Sauf que derrière tu dois payer 4000 USD par an à l'ICANN et négocier avec tous les registry du monde (et ça je sais pas combien ça coûte) (ou alors se concentrer sur juste quelques TLDs, mais ça ne résout pas le problème de la masse critique requise pour amortir les coups de matraque de l'ICANN et des TLDs). Donc soit on fait un truc qui existe déjà et qui n'apporte rien (d'autre que l'éthique) au marché, soit on fait un truc de niche qui risque fort de ne pas marcher. En attendant, il y a l'OpenNIC Project (https://www.opennic.org/)... PS : Même si l'idée 2 marche pas, ça m'intéresse d'essayer --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Pire que Sogetrel.....
On 20/06/2023 23:07, Spyou wrote: Le 19/06/2023 à 10:35, David Ponzone a écrit : On a trouvé, ça s’appelle SOLUTIONS30. On a jamais vu des guignolos pareils, et devinez-quoi, c’est le sous-traitant Number1 de l’agrume (sur le FTTH) dans certains coins. Bon, après, ça sert à rien de le dénoncer puisque on a pas le choix mais peut-être qu’à force de voir leur nom dans des commentaires négatifs, ils vont finir par réagir. Peut-être même qu’ils sont sur la liste… Le problème: essentiellement des annulations de RDV FTTH (clients pro) à la dernière minute (plus de 50% des cas) La question: est-ce qu’il y a autant d’annulations sur des clients pro Orange directs…. Je préfère encore 80% d'annulation que les sous-traitants de chez nous qui montent à pieds joints sur les tiroirs optiques pour brancher leurs jarretières. J'ai perdu une vidéo d'une intervention de Sogetrel à un NRA/NRO Orange près duquel ils tiraient de la fibre aérienne en jetant des boucles de câble par dessus les poteaux pour essayer de faire s'accorcher ledit câble aux supports cuivre existants. Ça mieux s'ils avaient annulé eux aussi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 17:23, Laurent Barme wrote: l'IPv6 est [...] un danger potentiel pour la sécurité et une menace pour la vie privée. Comment ? Pourquoi ? (On est pas vendredi, je demande vraiment) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 17:23, Laurent Barme wrote: Stephane (Borrtzmeyer) est prescripteur et pas acteur Si Bortzmeyer n'est pas acteur, que faut-il faire pour l'être ? Est-ce que moi je le suis ? En tant que simple consommateur d'Internet (je n'ai pas d'AS ni de réseau publique) est-ce que activer l'IPv6 sur mes machines hébergées "dans le cloud", configurer mes quelques réseaux privés correctement pour que ça "juste marche(TM)" en IPv6 et développer la compatibilité des applications (lorsque c'est nécessaire) ne fait pas de moi un acteur ? Est-ce qu'il faut forcément être un AS pour prétendre au titre d'acteur ? Si oui, je ne comprend pas comment l'Internet tout court a pu exister (notons que je n'étais pas né). L'échelle était certes plus petite qu'aujourd'hui, mais si à l'époque on a réussi en partant de rien, je ne vois pas comment aujourd'hui on ne pourrait pas réussir en partant de quelque-chose de similaire. Les APIs sur nos OS sont déjà prêtes (même si ça reste un peu le bordel pour certains), il nous manque juste le réseau. Et puis il faut rester cohérent sur les critiques qu'on fait à l'IPv6. Si c'est un problème d'inertie, pourquoi est-ce que Google y arrive et pas les PMEs (ou "artisans") ? Si c'est une question de moyens, pourquoi Twitter n'y arrive pas, mais que Ungleich y arrive ? Et si c'est une question de lacunes, comment ça se fait que des réseaux (privés) dual-stack comme pur-IPv6 existent et tournent correctement ? Si ce n'est ni une question d'inertie, ni une question de taille, ni une question de moyens, ni une question technique, qu'est-ce qu'il reste ? Le facteur humain ? Je ne veux pas en arriver à ce "point godwin de l'IPv6" un peu facile, mais franchement je vois pas ce que ça peut être d'autre que "la flemme". Je veux bien qu'on ait des problèmes d'IPv6 ; rien qu'à mon échelle j'en ai rencontré une pelletée. Je blame en partie Linux et en partie les applications que j'utilise, mais surtout je me blame moi pour ne pas avoir pris le temps de considérer l'IPv6 comme ce que c'est : Un protocole différent, qui demande à ré-apprendre une partie du réseau, et qui, par sa nouveauté (si on peut encore dire ça) est encore mal intégré dans nos écosystèmes techniques. Enfin, je ne comprend pas ceux pour qui l'IPv6 donne de l'urticaire alors que le NAT ne leur en donne pas. My-2ct-qui-valent-moins-que-2ct --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 18:32, Laurent Barme wrote: Le 26/06/2023 à 18:07, Léo El Amri via frnog a écrit : On 26/06/2023 17:23, Laurent Barme wrote: l'IPv6 est [...] un danger potentiel pour la sécurité et une menace pour la vie privée. Comment ? Pourquoi ? (On est pas vendredi, je demande vraiment) Il n'y a pas de "vendredi" pour moi (je bosse tous les jours). Merci :) Si tu as des archives, tu peux retrouver la discussion suite à mon message sur le sujet le 26/04/21 08:45. Tiens, cela fait moins de 10 ans, Denis n'est pas encore complétement sorti de son hibernation :-). Elles sont parties en cold-storage, et les archives en ligne ne semblent pas remonter si loin :/ Sinon, pour le danger potentiel c'est lié pour moi au nombre d'IP qu'il faudrait bloquer. En ce sens, l'échange cité ci-dessus m'a permis de prendre sereinement la décision de bloquer les IPv6 par /64. Il ne me semble pas déraisonnable de bloquer des /64 (ou /56 voir /48 si on est vraiment pas content). Par contre je ne vois pas où est le danger. Si c'est une question de taille de table de blocage, tu ne peux de toute façon pas bloquer moins qu'un /64 dans un bloc IPv6, entre autre en raison du point suivant (les extensions de "vie privée" IPv6). Pour ce qui concerne la menace que je perçois pour la vie privée c'est lié à l'identification plus précise de l'utilisateur dont le poste n'est pas (un peu) masqué par une IP publique partagée. Il me semble que jusqu'à très très récemment, la plupart des équipements dans une "maison" étaient tous derrière une unique IPv4 publique. Et je ne vois pas en quoi les extensions de vie privée de l'IPv6 (pour le SLAAC), qui émulent plus ou moins le même niveau de """protection""" que le type de NAT IPv4 sus-mentionné, ne répondent pas au besoin. On peut certes mieux identifier une machine sur une session donnée, mais, pour Windows en tous cas, au prochain redémarrage l'adresse IPv6 aura changé. Je ne pense pas qu'on puisse faire mieux au niveau de la couche IP. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 19:06, Laurent Barme wrote: Le 26/06/2023 à 18:50, Léo El Amri via frnog a écrit : On 26/06/2023 18:32, Laurent Barme wrote: … Il ne me semble pas déraisonnable de bloquer des /64 (ou /56 voir /48 si on est vraiment pas content). Par contre je ne vois pas où est le danger. Si c'est une question de taille de table de blocage, tu ne peux de toute façon pas bloquer moins qu'un /64 dans un bloc IPv6, entre autre en raison du point suivant (les extensions de "vie privée" IPv6). 2^64 > 2^32 ; même en bloquant par /64, ça en fait potentiellement un peu plus quand même question taille de table de blocage. En effet, c'est possible. Mais je pense que ça dépend moins du nombre d'adresses disponibles que du nombre d'attaquants actifs. Un /64 en IPv6 c'est souvent l'équivalent d'un /32 en IPv4. Le problème de taille de la table de blocage se pose SI les attaquants ont accès à plus de /64 IPv6 qu'ils n'auraient accès à des /32 IPv4. Et dans ce cas, en effet, il faudrait faire des règles de blocages intelligentes ou carrément faire du DPI. Je n'ai jamais été exposé à ces problèmes donc je ne me rend pas compte de la "chance" que ça arrive. Mais des solutions existent, donc la (grande) taille de l’espace d'adressage me semble être un argument peu recevable pour justifier de ne pas utiliser l'IPv6. Pour ce qui concerne la menace que je perçois pour la vie privée c'est lié à l'identification plus précise de l'utilisateur dont le poste n'est pas (un peu) masqué par une IP publique partagée. Il me semble que jusqu'à très très récemment, la plupart des équipements dans une "maison" étaient tous derrière une unique IPv4 publique. Et je ne vois pas en quoi les extensions de vie privée de l'IPv6 (pour le SLAAC), qui émulent plus ou moins le même niveau de """protection""" que le type de NAT IPv4 sus-mentionné, ne répondent pas au besoin. On peut certes mieux identifier une machine sur une session donnée, mais, pour Windows en tous cas, au prochain redémarrage l'adresse IPv6 aura changé. Je ne pense pas qu'on puisse faire mieux au niveau de la couche IP. Tu as raison mais la ré-attribution d'une IPv6 par poste ça peut être désactivé, le NAT non. De plus, si entre deux redémarrage sous Windows, l'IPv6 reste constante alors, le port du NAT change à chaque nouvelle requête. Pour moi, si le comportement par défaut ne respecte pas la vie-privée, c'est un problème logiciel. À l'époque de la RFC 4941 on aurait pu dire que c'est un problème humain (de configuration), mais désormais la recommandation de NE PAS faire de cette option un comportement pas défaut a été retiré (RFC 8981). Linux est un assez mauvais élève par défaut, mais les solutions user-land sont très bonnes. Windows est curieusement un bon élève par défaut : activé et changement toutes les 24h ou à chaque redémarrage. Si l'utilisateur veut désactiver les options de "vie privée", qu'on le laisse faire ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 18:48, Laurent Barme wrote: Le 26/06/2023 à 17:38, Bertrand FRUCHET via frnog a écrit : Bonjour la liste, C'est pas l'IPv6 qu'il faut désactiver, c'est le logiciel qu'il faut changer quand vous avez des dysfonctionnements. Ce n'est pas toujours le logiciel qu'il suffit de changer. Voici un retour d'expérience comme exemple : Les symptômes étaient sibyllins : un nouveau site sur un nouveau nom de domaine se prend une erreur SSL d'emblée (le serveur n'est même pas sollicité) Je ne comprend pas très bien comment c'est possible. Est-ce qu'on parle d'un serveur HTTP ? Si oui, est-ce que "le serveur non contacté" est derrière un reverse-proxy ? Si non comment est-ce que le client peut avoir une erreur TLS si le serveur n'est jamais atteint ? depuis un mobile via la 4G (quelque soit le navigateur utilisé) alors qu'il fonctionne bien par ailleurs ! Depuis le même mobile, toujours en 4G, un autre site sur le même serveur fonctionne pourtant sans souci. Le blocage se produit sur le réseau Orange et Bouygues mais pas sur Free ni en WiFi (via une ADSL). La cause était une IPv6 aussi définie pour le nom de domaine alors que le serveur n’était pas configuré pour accepter les connexions IPv6. Comme Orange et Bouygues privilégient manifestement l'IPv6 quand il y en a une déclarée… évidemment ça coince. Pour moi c'est un problème logiciel : Le happy eyeballs n'a pas été utilisé. La solution aura été de simplement supprimer l'entrée de la zone DNS pour le nom de domaine. Configurer le serveur web pour de l'IPv6 aurait considérablement agrandi la surface d'attaques possibles. Et un problème humain ! Si le serveur n'accepte pas l'IPv6, l'administrateur n'aurait jamais du renseigner de dans la zone ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
On 26/06/2023 22:18, Laurent Barme wrote: Le 26/06/2023 à 21:23, Léo El Amri via frnog a écrit : Je ne comprend pas très bien comment c'est possible. Est-ce qu'on parle d'un serveur HTTP ? Si oui, est-ce que "le serveur non contacté" est derrière un reverse-proxy ? Il s'agit bien sûr d'un serveur HTTP (…non de domaine…). Il n'y avait pas de "reverse-proxy" (et je vois pas trop ce que cela vient faire ici). Alors du coup je n'ai rien compris à l'architecture. Il n'y a pas de concept d'erreur TLS dans un navigateur si le serveur ne répond pas. Si non comment est-ce que le client peut avoir une erreur TLS si le serveur n'est jamais atteint ? Le serveur n'est jamais atteint car il n'écoutait pas sur une IPv6. L'erreur de certificat est manifestement un bug (et une fausse piste qui m'a fait perdre du temps). Voici mon hypothèse : l'OS résout le nom de domaine en IPv6, le navigateur ne parvient pas à obtenir le certificat SSL pour cette IPv6 (pas de réponse du serveur) affiche une erreur TLS au lieu d'essayer de passer par l'IPv4 à moins que l'OS refuse de fournir une IPv4 puisqu'il a trouvé une IPv6 pour le nom de domaine. Je ne connais aucun navigateur avec ce comportement, mais soit. Déjà, l'OS résout le nom de domaine pour les familles d'adresse demandées par l'application. Si cette dernière ne supporte pas happy eyeballs, il y a de fortes chances qu'elle tente la première réponse qu'elle a obtenu. Admettons que ce soit une adresse IPv6. Si le navigateur essaye de se connecter en TLS sur l'adresse IP retournée par l'OS, mais que personne ne répond en face, l'application n'a même pas l'occasion de négocier du TLS, donc il ne devrait même pas y avoir d'erreur de certificat TLS. Enfin, l'OS n'a pas la responsabilité de se connecter sous une autre adresse IP, c'est l'application qui décide ça, et si elle est naïve, il y a de fortes chances qu'elle ne retente rien, et qu'elle affiche que le site est indisponible. Si l'application montre un autre comportement que celui-ci, c'est qu'elle est sérieusement cassée. (Par OS je sous-entend iOS ou Android) depuis un mobile via la 4G (quelque soit le navigateur utilisé) alors qu'il fonctionne bien par ailleurs ! Depuis le même mobile, toujours en 4G, un autre site sur le même serveur fonctionne pourtant sans souci. Le blocage se produit sur le réseau Orange et Bouygues mais pas sur Free ni en WiFi (via une ADSL). La cause était une IPv6 aussi définie pour le nom de domaine alors que le serveur n’était pas configuré pour accepter les connexions IPv6. Comme Orange et Bouygues privilégient manifestement l'IPv6 quand il y en a une déclarée… évidemment ça coince. Pour moi c'est un problème logiciel : Le happy eyeballs n'a pas été utilisé. Ok le "happy eyeballs" n'a manifestement pas été utilisé mais il est impossible d'intervenir au niveau du logiciel/OS des visiteurs d'un site. Je rappelle que ce sous-fil de discussion (désolé Louis pour la digression) part de mon témoignage à propos d'une intervention à faire impérativement sur le logiciel d'après une réponse de Bertrand. Je suis d'avis de ne pas supporter les logiciels cassés dans une certaine mesure. Là on est dans cette "certaine mesure". Les standards existaient avant les implémentations dans la nature (un bon contre exemple est IRC). Essayer de supporter ces logiciels défectueux ce serait comme lorsqu'on essayait de continuer de supporter IE5 en 2010. On voit l'impact que ça a eu sur le "web". Sauf que là on a même pas l'excuse de "c'est l'application la plus utilisée du monde". La solution aura été de simplement supprimer l'entrée de la zone DNS pour le nom de domaine. Configurer le serveur web pour de l'IPv6 aurait considérablement agrandi la surface d'attaques possibles. Et un problème humain ! Si le serveur n'accepte pas l'IPv6, l'administrateur n'aurait jamais du renseigner de dans la zone ! Tout à fait ; c'est toujours un problème humain si on remonte suffisamment la pile. D'ailleurs si l'humain n'avait pas inventé l'IPv6… :-)) C'est vrai, mais il ne faut pas abuser. Et là on parle de LA personne qui est sensée être le plus au courant de l'environnement qu'elle configure. En plus si le serveur est déjà utilisé pour d'autres sites et que les zones DNS de ces autres sites n'ont pas d'IPv6, ça met la puce à l'oreille. --- Liste de diffusion du FRnOG http://www.frnog.org/
[MISC] Triangulation ou trilatération ? (WAS: [FRnOG][MISC] [Émeutes] Interdiction des réseaux sociaux ?)
Bonjour la liste, Dans le cas de la géolocalisation dans un réseau de téléphonie cellulaire, est-il question de triangulation ou de trilatération ? Réponse : De la trilatération. Pareil pour le GPS, le WiFi RTT et n'importe quelle autre technologie qui utilise trois points ou plus aux coordonnées relatives connues, et une distance entre ces points et le point dont on cherche la localisation. Et vous, le saviez-vous ? Si non, pourquoi appeliez-vous la trilatération "triangulation" ? Pour ma part, ce qui explique pourquoi je n'ai jamais questionné le terme, c'est que des professionnels de la radio m'ont appris ça quand j'étais au Lycée en l'appelant "triangulation". Et ils mettaient le même mot sur la technique de triangulation et celle de trilatération. Pourtant ces techniques sont utilisées dans des situations et pour des besoins complètement différentes. Ce n'est que ce week-end, en travaillant sur un projet avec un ami, que j'ai découvert que ça s'appelle la "trilatération" et non la "triangulation". -- Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][MISC] Facturation RIPE et Chorus Pro
La seule vraie réponse ici. Merci Damien. Pour les intéressés, voici l'ordonnace qui (ne) précise (pas vraiment) quelles sont les entités concernées : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT29140226 Il faut lire entre les lignes, si la domiciliation des entreprises ne compte pas, c'est parce que seules les entreprises françaises y sont soumises (les formes de société listées étant françaises). Bien entendu, il est aussi possible de se placer en tant que mandataire pour la réalisation du paiement, je pense que ça doit être possible auprès du RIPE, mais ça serait utile seulement si la compta de l'administration est trop rigide. L'avantage de cette solution est qu'elle est sans frais (parfaitement optionnels), autres que ceux de la réalisation du mandat, qui, soyons honnêtes, ne dépasse pas 1h de travail. Cordialement, Léo On 31/07/2023 18:04, Damien DUJARDIN wrote: Bonjour à tous, Chorus Pro ne concerne que les fournisseurs français. Le RIPE ayant son siège aux Pays-Bas, aucun problème pour facturer à l'ancienne. Certaines administrations n'aiment pas ça, mais c'est parfaitement légal. Chez nous on a l'habitude, ça passe tout seul au service comptable. Là ou ça se complique c'est quand une grosse multinationale facture depuis un siège à l'étranger, mais en utilisant une adresse d'une entité (parfois fictive) en France. Ou comment faire appliquer la loi Chorus Pro à des polonais ou des japonais qui ne parlent pas anglais Le lun. 31 juil. 2023 à 17:47, Marc Abel a écrit : Bonjour, Jusqu'à ce jour on a réussi à régler nos factures RIPE directement. Notez qu'on paye d'un côté la partie HT au RIPE-NCC et de l'autre la TVA française (à l'état je suppose). Comme la facture n'arrive pas dans le SI facturation il faut la récupérer et l'y injecter (merci aux collègues qui font ça). Le souci vient du délai trop court donné par le RIPE-NCC pour régler la facture versus nos délais d'instruction et ceux du payeur qui effectue le virement in fine. Marc ABEL pour CD93 Le 31/07/2023 à 15:12, Olivier Pruneyrac a écrit : Bonjour, Nous intervenons pour accompagner une métropole dans sa déclaration en tant que LIR auprès du RIPE. A ce titre la métropole se demande comment la facturation pourra avoir lieu compte tenu de l'obligation de passer par Chorus Pro pour facturer une administration française. Le RIPE ne peut pas utiliser Chorus Pro. Une administration française LIR abonnée à frnog pourrait-elle nous indiquer comment elle réalise l'enregistrement de la facturation RIPE ? Passe elle par un intermédiaire pour cela ? Merci d'avance Cordialement Olivier Pruneyrac 06 26 65 68 43 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Distance MINIMUM pour utilisation fibre monomode et sfp 10G
On 26/08/2023 08:36, Guillaume Roux wrote: Bonjour à tous, Existe-t-il une documentation claire sur les contrindications à l’utilisation de fibre monomode et 10G sur des courtes distances. J’ai beau rappeler à mes collègues qu’en DC il n’y a que de la mono même pour de l’inter baie ou entre équipement intra baie on continue de me parler éblouissement et atténuateur et donc maintien de la multimode. Et si je trouve moult documents sur débits max et longueur max, je trouve assez peu de chose sur la longueur minimum pour ne pas avoir besoin d’atténuateur. Merci d’avance aux experts fibres pour leur partage d’info. Guillaume Avertissement : je n'avais jamais touché à de la fibre télécom avant le mois dernier, et je n'en ai installé qu'une seule pour mon homelab, mais j'ai fait plein de recherches à cette occasion, et j'ai fait appel à de vieilles connaissances acquises lors de mes cours de physique optique. Je ne connais rien à la fibre en application télécom, mais dans la fibre de façon générale ça se calcule avec l'atténuation par unité de longueur et le nombre de raccords sur le chemin. Il se trouve que (sur le terrain, pas en laboratoire) les fibres "multimode" ont une plus forte atténuation par unité de distance que les fibres "monomode". Il doit bien exister une "règle empirique", que tu dois connaître, sur l'affaiblissement aux raccords. Pour le reste j'ai l'impression que ça dépend beaucoup de l'équipement utilisé. Au niveau des modules SPF, je n'ai pas trouvé de "logique" sur les puissances d'émission/réception. J'en ai déduit que c'est du cas par cas. Personnellement je me suis simplement assuré que la puissance à la réception n'était pas supérieure à la valeur maximale admise par mon récepteur. Les modules SPF pour lesquels j'ai lu la fiche technique supportaient tous au moins leur puissance d'émission en réception. Dans mon cas j'ai juste eu à installer un atténuateur de 3dB parce que mon SFP Juniper émettait plus fort que ce que pouvait recevoir mon SFP Mikrotik. Bref. La distance en DC étant négligeable, ce n'est qu'une question de comptabilité de matériel. Je ne vois pas trop ce que viennent faire des atténuateurs dans une infra pro, puisqu'on devrait s'attendre à voir exactement les mêmes modèles de SPF au bout des câbles dans la plupart des cas. Les cas où ce n'est pas possible (routeurs de marques différentes avec vendor-lock par exemple), je vois mal comment ça peut être autre-chose qu'une configuration sur-mesure. Il faudra sortir son cerveau. En tous cas j'aimerais aussi une réponse à cette question. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre
On 12/09/2023 09:21, Toussaint OTTAVI wrote: Le 12/09/2023 à 00:06, br...@skiwebcenter.fr a écrit : Sur le résidentiel, la meilleure solution est sans doute de trouver un bon artisan qui va faire une pose "propre" jusqu'au PBO le plus proche. Dans la plupart des cas, les fourreaux ou poteaux ne sont pas accessibles librement. Il faudrait que chaque artisan ait obtenu l'accord de l'exploitant ou du responsable d'infrastructure pour poser des câbles. Et vu combien le processus semble automatisé et le rigide du côté des 4 gros, je vois pas comment ça peut marcher. Même la zone à faible densité de ma campagne est couverte par Orange plutôt que par un RIP. Si c'est une bonne idée sur le papier, ça a l'air d'être un cauchemar juridique, et il existe si peu d'artisan de la fibre que j'ai du mal à voir comment mettre ça en place concrètement. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre
On 12/09/2023 10:34, Toussaint OTTAVI wrote: Le 12/09/2023 à 09:39, Léo El Amri via frnog a écrit : Dans la plupart des cas, les fourreaux ou poteaux ne sont pas accessibles librement. Il faudrait que chaque artisan ait obtenu l'accord de l'exploitant ou du responsable d'infrastructure pour poser des câbles. Ah bon, il faut demander l'autorisation à quelqu'un ? :-D :-D :-D Les grossistes en matériel électrique vendent des bobines de fibre avec le PTO déjà soudé. N'importe quel électricien qui travaille proprement pourra faire le job. Dans la mesure où cela permet d'éviter un éventuel échec, je ne vois pas qui s'en plaindra. Ni le sous-traitant, qui n'aura que la soudure à faire, ni l'opérateur commercial, puisqu'il n'en saura probablement jamais rien :-) Quand le gestionnaire de réseau de déplacera pour raccorder un abonné et se rendra compte que c'est déjà fait, alors que ça n'est pas enregistré chez eux, plusieurs fois, ils va se poser des questions sur qui câble sans son accord. En vérité, je pense que ça leur posera problème quand même. En tous cas, j'éspère ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [France Inter] Les ratés de la fibre
On 12/09/2023 11:09, Toussaint OTTAVI wrote: Le 12/09/2023 à 10:57, Léo El Amri via frnog a écrit : Quand le gestionnaire de réseau de déplacera pour raccorder un abonné et se rendra compte que c'est déjà fait, alors que ça n'est pas enregistré chez eux, plusieurs fois, ils va se poser des questions sur qui câble sans son accord. Le technicien va forcément se déplacer, il va forcément devoir trouver un plot au PM et brasser vers le PBO. Dans le PBO, il n'aura que la soudure à faire (le reste étant déjà fait). Donc, c'est du gagnant-gagnant pour tout le monde. Et, si ledit tech fait son job correctement, la ligne sera correctement répertoriée. Si il est question de tirer un câble optique du DTIo jusqu'à la chambre en bordure de propriété, alors oui, "n'importe-qui" peut le faire sans aucune autorisation, en effet, quasiment tout le monde est gagnant (sauf peut-être l'abonné, pour qui cette installation aurait été gratuite s'il avait laissé son opérateur faire). Tirer jusqu'au PB, est aussi probablement faisable sans que ça ne gêne personne, mais ça reste probablement illégal. J'ai 5 DTIo à poser dans une ancienne ferme séparée en appartements, je tirerai 4 câbles jusqu'à la chambre en bordure de propriété, et un câble jusqu'au PB, on verra ce qu'on me dit (je suis desservi par un RIP de l'Agrume dans la diagonale du vide). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Déstockage Sniffing -> Surveillance qualité réseau électrique
On 18/09/2023 16:02, Toussaint OTTAVI wrote: Le 18/09/2023 à 12:01, Nicolas Vuillermet a écrit : Après, j'imagine qu'il faut d'abord qualifier le bruit avec un analyseur de spectre pour savoir si le filtre est dans la bonne gamme... Il y a quelques semaines, pas pour les mêmes raisons, je m'interrogeais sur un dispositif automatisable de surveillance de qualité des réseaux électriques. Un truc qui fait des mesures en permanence et les envoie dans un InfluxDB / Grafana. Dans mon cas, il s'agissait de caractériser des baisses de tension, ou micro-coupures, beaucoup plus fréquentes que la normale sur une zone géographique donnée. La surveillance des harmoniques, que ce soit du CPL de m..., des onduleurs défaillants, le voisin radioamateur :-) çà n'est pas non plus dénuée d'intérêt. A la fois pour identifier les "perturbateurs", mais aussi les conséquences potentielles sur les "perturbés". Par contre, je n'ai rien trouvé de tout fait (à part l'analyseur de spectre R&S qui coûte 10 fois le prix du matos à protéger, et encore, il faut rajouter un Raspberry Pi si on veut publier les résultats en MQTT). Je pensais donc me bricoler un truc, mais je me heurte au capteur à utiliser, et surtout au fait que çà soit relié au secteur. Pour mesurer la tension et la fréquence, çà va, ce ne sera pas trop compliqué, et surtout sans risques, derrière un transfo abaisseur calibré. Par contre, pour mesurer des harmoniques sur le 220V, c'est moins évident... Derrière un transfo abaisseur, çà risque d'atténuer sévère. A la rigueur, il faudrait un oscillo numérique bon marché capable de visualiser une onde secteur à 220V. Ensuite, un ESP8266 WiFi pour l'isolation galvanique, un peu de FFT, et çà pourrait le faire. Quelqu'un a déjà fait çà ? Ou a des idées ? J'en ai pas, mais ça fait plusieurs mois que je veux faire ça aussi. Je veux bien quelques plans ou quelques sources, si tu en as, du capteur de tension et de fréquence pour du monophasé. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Gestion du cycle de vide de développement applicatif en environnement cloud privé
Bonjour Eugène, On a bien reçu ton message, mais j'imagine que c'est un peu hors-scope dans la FRnOG. Mon avis sur la question (en tant que développeur - quelqu'un qui conçoit un logiciel (pas juste qui le programme, on appellerait ça un programmeur sinon)), c'est que tu montres par toi-même que tout ça est incompréhensible tant qu'on ne définit pas les termes qu'on emploie au cas par cas. Pendant un temps on disait que les DevOps était la capacité d'un "développeur" à faire de l'administration système, puis petit à petit c'est devenu l'automatisation de processus de développement (tests automatisés, vérification de la qualité de code, etc.). Pour ces questions de vocabulaire flou, je ne peux pas réagir sur les "anti-patterns" du DevOps. Ils peuvent être vrai ou faux en fonction de la définition du mot. Le "Platform Engineering" ne change rien au problème, ça sera, à mon avis, encore une expression utilisée à tort et à travers. On m'a souvent mit l'étiquette DevOps (je ne sais pas pourquoi) et je n'ai jamais fait de "cloud" à proprement parlé, chose qui était plutôt réservées à des équipes d'administration système (ceux qui gèrent des hyperviseurs de VMs ou du K8S en entreprise, par exemple). Ce à presque toute taille d'entreprise (les toutes petites ne peuvent pas se permettre d'avoir des salariés dédiés à certaines tâches, mais les autres semblent le pouvoir). En sachant que je ne suis pas admin réseau : Je ne pense pas que les administrateurs réseau soient spécifiquement concernés par la question du "platform engineering". Pour faire du GitOps, il faut pouvoir définir ton infra par du texte, ce qui n'est pas toujours possible. Ce n'est pas une solution miracle, tout comme ne le sont pas le DevOps, le SecOps et autres DevNetSecOps++. Pour moi, faire travailler un ensemble de gens spécialisés chacun dans un domaine, avec un outil commun et une méthode de définition d'infra commune, c'est sympa mais pas toujours possible. Ça s'appelle l'IaaS, et on ne le retrouve pas forcément dans tous les cloud, et dans ceux qui le pratiquent ça ne se retrouve pas à tous les niveaux. Pour le reste, ce que j'ai constaté en tant qu'acteur externe aux équipes réseau, c'est que c'est bien souvent séparés et que les équipes réseau n'utilisent pas les outils des équipes système, qui n'utilisent pas les outils des équipes développement logiciel. La seule fois où j'ai vu un système commun pour tout le monde (dans une boite du CAC40), c'était lourd et tout le monde s'en plaignait. Je pense que la clef dans tout ça, serait que les admin-sys restent experts de leur domaine, que les admins-réseau restent experts de leur domaine, et que les développeurs soit pluridisciplinaires et aient des connaissances de base sur le système et sur le réseau. Je trouve que les objets définis de base dans K8S offrent un découpage assez raisonnable des différentes responsabilités au sein d'une SI. - Léo On 06/09/2023 16:35, Eugène Ngontang wrote: Hello, Mon mail a été bloqué par l'équipe de modération ou alors il est totalement hors scope pour tout le monde? Ou bien il vaut mieux le formaliser sous forme de survey? Cordialement, Eugène NG Le mer. 23 août 2023 à 03:11, Eugène Ngontang a écrit : Hello tout le monde. Je reviens sur le sujet du DevNetOps, cette fois sous le prisme de la gestion du cycle de vie de développement logiciel (SDLC) en environnement cloud privé, mettant à contribution les équipes réseaux et système. En effet, je vais me permettre de rappeler que le DevNetOps ou NetOps ou encore NetDevOps, est l'application des pratiques DevOps aux opérations réseaux. Plus simplement ça vise principalement l'automatisation des opérations réseaux. Ainsi tout comme le DevOps a ouvert la porte aux anti-patterns, le DevNetOps a sûrement fait pareil. Quelques exemple d'anti-patterns : - Le DevOps coincé entre les Dev et les Ops - le NoOps des Dev qui n’ont pas besoin d’Ops - le DevOps est un outil - le SysOps ou le NetOps dont on a juste changé le nom en DevOps, - L’Ops intégré dans l’équipe Dev, - … C'est pour palier à tous ces écarts que l'on parle beaucoup plus du Platform Engineering (buzzword de 2023), dont le but n'est pas de substituer au DevOps, mais de l'implémenter correctement. Cependant la tendance est toujours d'aborder ces concepts xOps avec une vision cloud (public cloud) native, ce que je trouve personnellement très limitant. Alors ma question ou alors mes questions, dont les réponses dépendront bien sûr des entreprises/organisations et uses cases. : - Quid du platform engineering pour les gurus du réseau ? - Est ce que vous vous contentez d'automatiser et orchestrer exclusivement les flux de provisioning/déploiement réseau en traitant le réseau comme un produit, une application avec son propre SDLC? - Est ce que vous fournissez plutôt des landing zones : *backbone fiable, hautement flexible et pérenne pour le d
Re: [FRnOG] [TECH] problème PDU : courant de fuite
On 09/10/2023 19:18, fr...@r0m5.eu wrote: J'en arrive aux questions : - 1 mA de courant de fuite par alim de switch vous paraît-il cohérent ? Nous savons testé avec une autre marque, nous sommes plutôt aux alentours de 0,5mA. Ça me semble énorme dans les deux cas. Comment est-ce que vous avez mesuré le courant de fuite sur vos alims ? Est-ce que tu as testé les alimentations seules ? Si non, est-ce que tu as vérifié si ce n'est pas le switch ou les câbles/équipements qui y sont branchés qui posent problème ? - des différentiels 30mA sont-ils à votre connaissance utilisés en datacenter ? un différentiel pour chacune des deux sources d'alim redondées d'une baie ? J'aurai tendance à penser que oui pour la protection des personnes mais dans un job précédent nous remplissions bien nos baies dans nos datacenters parisiens et nous n'avons jamais à ma connaissance eu de problème de différentiel qui saute. Les différentiels 30mA sont obligatoires dans le tertiaire à partir du moment où des personnes peuvent intervenir à proximité de la BT (c'est normé par la NF C 15-100 et imposé par je ne sais quelle loi). Pour des questions de résilience, on adopte souvent une sélectivité fine dans son installation électrique, un différentiel par source d'alimentation ne me surprend pas, au contraire, ça me semble être une bonne pratique. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rayon de courbure FO mono vs. multi
On 16/10/2023 19:03, Émile Touron wrote: Son argument est que la multimode résiste mieux aux rayons de courbure forts, et que les chemins de câble pour accéder aux caméras disposent souvent d'angles assez serrés. Avec de la mono, dit-il, dans certains cas on n'aurait pas de signal. Absence de preuve n'est pas preuve d'absence, mais je n'ai jamais constaté de différence sur le terrain. Comme tout câble, le rayon de courbure dépend de plusieurs facteurs. Le procédé de fabrication d'une fibre est le même, que ce soit pour la monomode ou la multimode, seul l'enrichissement du dépôt change. Vu les diamètres en jeu, tant que la gaine n'est pas écrasée dans la courbure, il y a très peu de chance que l'âme ait souffert. Il faudrait vérifier les spécifications de votre câble. Personnellement sans trop me soucier des datasheet, j'ai toujours respecté la règle du "huit fois le diamètre du câble" sans que ça ne pose de problème observable. Dans le cas d'une fibre, cette règle autorise presque les angles francs à 90 degrés. Je classe ça dans les légendes urbaines jusqu'à preuve du contraire. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Provider mail pour collectivités
On 27/10/2023 10:25, Martin wrote: Je cherche donc une solution qui soit accessibles aux collectivités. Et par là j'entends qui permette une facturation par Chorus Pro pour ce que j'en sais. Si en plus elle est respectueuse de la vie privée des administrés qui nous envoient des mails, c'est parfait. Evidemment on va en profiter pour faire u mail 2.0 en remplaçant mairie@wanadoo.fr à mai...@xxx.fr. Témoignage anecdotique : Ma petite commune (moins de 1500 habitants) a franchi le pas cette année en passant de wanadoo.fr à un nom de domaine et une boite de courriel chez OVH. Je ne m'en suis pas occupé, pour le moment ils en sont contents. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
On 24/12/2023 13:12, Stéphane Rivière wrote: [...] Pour confirmer la forme de l'installation : * On a des cartes industrielles (C) (basées sur microprocesseur PIC) raccordées à un modem 4G. Ces cartes ont un client HTTP. * On a un serveur HTTP (S) codé en Ada (ailleurs que sur les cartes). * On a un reverse-proxy HTTP (P) Nginx (ailleurs que sur les cartes). * On a une machine (H) quelque-part sur le VPN, qui est capable de faire tourner tshark. * Tout ce beau monde communique sur un VPN basé sur OpenVPN. Le client HTTP sur les cartes réalisent des requêtes HTTP vers le reverse-proxy HTTP, on a donc le schéma "réseau" suivant : |=[ Tunnel OpenVPN ]=| [Client HTTP] ---> [Reverse-proxy HTTP] || Ta première capture tshark a été réalisée sur la machine H avec Firefox en guise de client, et a écouté l'interface OpenVPN. Ta deuxième capture tshark a aussi été réalisée sur la machine H, mais en écoute seulement, aussi sur l'interface OpenVPN. J'ai extrapolé des trucs, est-ce que c'est quand même bon ? Pour moi, sans pouvoir voir les données, la deuxième capture ne révèle pas de problème au niveau TCP, si ce n'est l'étrange fragmentation, mais ce n'est pas si surprenant pour de l'embarqué. À ce stade, je dirais que le problème se trouve au niveau du payload TCP, il faudrait que tu affiches les données pour en savoir plus. En tous cas, du SYN au FIN, la communication semble normale. Je ne connais pas tshark, et je ne comprend pas d'où vient l'affichage du début de requête GET. Est-ce qu'il affiche ça parce que le serveur a ACK ce morceau ? Ce n'est pas cohérent avec la quantité de données acknowledged par le serveur de toute façon. J'imagine que s'il ne l'affiche pas comme étant une requête HTTP, c'est que le flux est mal formé. - Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] 240/4 strikes back
On 11/02/2024 19:54, Philippe ASTIER via frnog wrote: Tout opérateur 5G est obligatoirement en IPv6, et ça inclut Free. "Obligatoirement" ? C'est une contrainte technique ? Je ne connais pas très bien la pile 3GPP, mais j'imaginais ça bien moins corrélé à l'IP que ça. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] 240/4 strikes back
On 12/02/2024 09:27, Philippe ASTIER via frnog wrote: "Obligatoirement" ? C'est une contrainte technique ? Je ne connais pas très bien la pile 3GPP, mais j'imaginais ça bien moins corrélé à l'IP que ça. Pas technique, réglementaire. Cela dit, la stack 3GPP a poussé le support du dual-stack assez « tôt » (plus de 10 ans maintenant), dès la 4G, avec une incitation plus forte en 5G. L’ARCEP, le 21 novembre 2019, a publié l’obligation pour les opérateurs de réseau mobile de rendre leur réseau IPv6 compatibles avant le 31 décembre 2020. (S’ils voulaient faire de la 5G dans la bande 3,4-3,8 GHz). Merci pour l'explication ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] 240/4 strikes back
Merci Philippe de rectifier les âneries qui ont été dites. À chaque fois qu'on parle d'IPv6 c'est pareil : "l'IPv6 fait pas ceci que l'IPv4 fait", "le protocole ne supporte pas telle configuration", "ouïn ouïn mon routeur clic-clic ne supporte pas ce que je veux faire, c'est de la faute à IPv6". Les gars, vous faites vraiment de l'Internet ? Maximus nous dit: > Dans notre cas, y’a 1 gros problème pour passer en IPv6 > Sur le site on a 2 opérateurs, chacun donne 1 /48. > Comment je fait pour adresser ? > > En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de l’interface utilisé pour soritr. Et en IPv6 tu choisirais un préfixe ULA pour ton réseau interne et tu utiliserais NPTv6 en bordure. IPv6 n'est pas moins bien qu'IPv4 sur ce point. Maximus nous dit: > Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je fais pour sortir par l’opérateur 2 ? > Du nat ? Depuis quand le choix du WAN dépend de l'adresse IP de l'hôte source ? Si dans ta configuration multi-WAN tu as choisi de déléguer le préfixe fournit par un de tes fournisseurs d'accès, alors oui tu vas devoir NAT. Tu peux NAT 1:1 ou bien choisir une configuration plus IPv4-esque. Libre à toi de te tirer une balle dans le pied si tu le souhaite. Sur ce point IPv6 est pareil qu'IPv4. Maximus nous dit: > Oh le nat évoqué en IPv6, de l’urticaire se déclenche chez certains ;) Jorropo nous dit: > La réponse des puristes c'est tu à ton propre /48 et tu fait du BGP avec tes deux opérateurs. > Sa peut être beaucoup plus de travail et coût, si le NAT fonctionne pour toi, utilise le NAT et osef les puristes. La solution décrite pas Jorropo serait la solution idéale, mais tout le monde n'a pas accès à un bloc, ni aux possibilités de faire du BGP soi-même. En effet c'est cher, et de ce point de vue, IPv6 est même beaucoup moins coûteux en temps que IPv4. Un NAT 1:1 en NPT et c'est réglé, tu n'auras plus jamais affaire à ton NAT. Les puristes anti-NAT sont aussi cons que ceux qui défendent l'IPv4 pour des raisons techniques. David Ponzone nous dit: > Ou sinon, tu fais en sorte que: > -en temps normal, tous les PC obtiennent leur IP en DHCPv6 (ou autre, y a 2 ou 3 moyens non ? *grin*) du /48 de l’opérateur 1 > -en failover, tous les PC ont un renew de leur IP dans le /48 de l’opérateur 2 > > Si IPv6 sait pas faire ça, c’est que c’est pas fini comme produit. > Tu t’en sors quand même en utilisant des leases très courtes. Le DHCPv6 n'est pas fait pour ça. Le NPTv6 ou bien un NAT sont bien mieux indiqués. Jérôme Marteaux nous dit: > Tu pointe les cas bien moisis d'ipv6, en plus d'être incompatible ipv6 ne copie pas les modes de fonctionnement bien compris et efficaces d'ipv4. > Pour adresser un périphérique il y a n méthodes possibles dont 1 seule qui ressemble à ipv4: DHCPv6. > Côté ISP l'adressage des CPE c'est carrément différent, rien n'est transposable: > - le mec qui avait compris ipv4 peut tout ré-apprendre; > - l'équipementier qui avait implémenté ipv4 peut tout refaire; > - le SI qui savait gérer ipv4 peut tout refaire. > En général on essaye de valoriser l'acquis pour progresser, il n'y a pas eu cette réflexion sur IPv6, ça ne m'étonne pas qu'IPv6 soit un échec. Incompatible avec quoi ? Quels modes de fonctionnements de l'IPv4 est-ce que l'IPv6 ne supporte pas ? Pourquoi est-ce que tu te plains d'avoir trop de choix, si tu aimes le DHCPv6, fais du DHCPv6. Tout ré-apprendre c'est le métier de l'informatique. Si les pionniers de l'IT ont pu le faire, il n'y a pas de raison qu'on y arrive pas nous non plus. Si tu ne veux pas apprendre, il faut changer de métier. L'équipementier qui avait implémenté l'IPv4 peut continuer de le faire (et de bien le faire) tout en sortant une nouvelle ligne de produits. Tu pointes un truc très juste : l'IPv6 c'est pas l'IPv4. Il faut arrêter d'essayer de les comparer en 1:1. IPv6 n'est pas né ex-nihilo. Il s'appuie beaucoup sur l'IPv4. On peut tout à fait capitaliser sur nos connaissances de l'IPv4, il est illusoire de penser que nos connaissances de l'IPv4 sont rendues obsolètes par l'IPv6. Jérôme Marteaux nous dit: > Mais pour au final quelle valeur ajoutée ? Est-ce que ça a servi à quelque chose qu'IPv4 ne permettait pas ? Si tu aimes le NAT alors en effet, IPv6 n'a rien apporté, excepté : * une taille d'adresse si grande que ça résout le problème de collision d'adresses entre deux réseau privés * une méthode d'adressage sans état qui permet aux hôtes de réseaux de toute taille d'avoir facilement des adresses * le multicast intégré (et sans effort) * des règles de traitement allégées (une seule extension à obligatoirement interpréter), ce qui le rend en théorie plus rapide que l'IPv4 * des options par noeud Eh bien en fait il semblerait que l'IPv6 ait apporté des trucs, rien que dans sa RFC cœur. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] 240/4 strikes back
On 13/02/2024 04:35, Maximus . wrote: Non, je ne fais pas de "l’internet". Je ne travaille pas chez des opérateurs tiers 1 2 3 4... Je travaille juste dans le SI d’une entreprise, et je suis inscrit à titre perso sur cette liste pour avoir des news sur ce qu’il se passe. Mon job aujourd’hui, c’est juste de faire en sorte que les machines communiquent entre elles et avec internet. On s’est intéressé à l’IPv6 car ça proposait un truc intéressant, la disparition du NAT. Et vu le nombre de serveurs, ce n’est pas toujours simple les VIP IPv4. On n'est pas des surdoués à développer et maintenir un linux qui permet de faire exactement ce que je veux. Donc on utilise un routeur qui nous aide avec du clic-clic. Et on fait un peu de CLI pour les fonctions qui ne sont pas dispo, mais on n’est pas capable de plus. Pour conf de la délégation, jusqu’à récemment, y’avait rien en clic-clic. Donc sur les sites avec 1 accès principal, et 1 backup, ça fonctionne, du NAT en v6. Entendu. Bien sûr, c'est pardonnable si tu ne fais pas de l'Internet, encore plus si tu es admin-sys, on est souvent le dernier maillon de la chaine. Ça reste quand même l'affaire de tout le corps de métier, à mon avis (voir la discussion parallèle sur l'enseignement de l'IPv6 en France). Pour les ULA, je ne sais si vous ne l’avez pas remarqué, mais un PC Windows adressé en ULA va préférer utiliser la couche IPv4. Quelle utilité de faire de l’IPv6 alors ? Tests réalisés y’a déjà un petit moment, ça a peut-être changé aujourd’hui. Si c’est le cas, je serais heureux de l’apprendre. C'est une regrettable conséquence de la RFC 6724. C'est un problème qui est apparu en 2012 et qui n'était pas là avant. Une sacrée régression. Ceci-dit, si tu contrôle les machines de ton parc, tu peux parfaitement modifier les règles de sélection d'adresse pour placer les ULA avant les IPv4. Je ne connais pas Windows, mais je ne serais pas surpris que ça soit modifiable facilement avec une GPO (peut-être même en clic-clic, mais je ne suis pas sûr). Pour le choix du WAN qui dépends de l’hôte source, c’est juste qu’on ne fait pas de routage asymétrique. On n'est pas propriétaire de nos IP, pas d’AS, pas de BGP. Si un PC avec une IPv6 de l’opérateur 1 sort sur le réseau de l’opérateur 2, 2 options : - l’opérateur détruit le paquet, car c’est pas du tout ce que le client est sensé avoir ; - l’opérateur laisse passer, mais sur le chemin retour, le paquet arrive par l’accès de l’autre opérateur, et on a dit pas de routage asymétrique, donc détruit. Il ne faut surtout pas faire ça. D'ailleurs tout bon FAI devrait interdire d'émettre des IPs dont il n'est pas responsable (et donc qu'il n'anonce pas), donc ça ne devrait même pas fonctionner. La solution à ça est la même que pour l'IPv4, pas de magie : c'est le NAT (mais attention, tous les NATs ne se valent pas). À ma connaissance, je ne vois pas comment fonctionne cette histoire de NAT 1:1 sur Fortigate. Si c’est ça qu’il faut faire, je vais me renseigner pour voir comment configurer ça. Mais vu la fin de la ligne, ou alors je n’ai pas compris, ça n’a pas l’air d’être la bonne solution. La balle dans le pied c'est si on avait choisi le NAT IPv4-esque. Ce que j'appelle "NAT 1:1" c'est le NTPv6 : sur tous les préfixes du réseau (ceux du WAN (normalement des GUA), et celui du LAN (un ULA dans notre cas)), la partie hôte de l'adresse est la même. Ainsi le NAT est entièrement sans état et a simplement besoin de connaître la valeur et la taille de chaque préfixe. Je profite juste de la discussion pour faire évoluer mes connaissances, par exemple avec l’histoire de NAT 1:1. Et je te félicite ! De mon point de vue aujourd’hui, si on peut faire fonctionner la double-stack, sans avoir à inventer la roue, car l’IPv6 est censé être l’adressage du futur, on essaye. Si ce n’est pas possible d’avoir les mêmes fonctionnalités, ben tant pis... Je suis bien d'accord. Mais il ne faut pas dire que ça ne marche pas. Je trouve aussi que le dual-stack est très difficile à mettre en place, là où un réseau IPv4 simple ou un réseau IPv6 avec NAT64 et DNS64 sont bien plus simples à mettre en place. Mais, tu dois le deviner, le réseau uniquement IPv6 c'est pas possible, ne serait-ce que à cause des imprimantes (: Car l’IPv4 est encore obligatoire. Aux Antilles, certains opérateurs ne proposent même pas l’IPv6. La 5G est là, mais pas l’IPv6. Et pas le petit opérateur local, c’est chez l’agrume (opérateur national Français, la filiale Antilles). Si vous voulez les captures d’écrans, y’en a pour 5 minutes. Même constat sur les abonnements maison. Chez l’agrume, y’a de l’IPv6, mais pas les autres. Ça on est bien d'accord que c'est pas normal. Eux, ils font de l'Internet, et ils n'ont aucune excuse. - Léo --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Les cabinets comptables & la cyber
On 19/02/2024 17:04, Vincent Duvernet wrote: Bonjour, J'avais déjà eu le cas il y a quelques temps avec un groupe Japonais mais là, ça fait 2 clients FR avec la même approche (visiblement par 2 cabinets différents). Leur commissaire aux comptes demande une évaluation des risques cyber'. On se tape des questions plus ou moins débiles / mal traduites du type : - Une solution antivirus est-elle installée sur chaque poste de l'entreprise ? Est-elle mise à jour régulièrement ? - La porte vers internet a-t-elle un pare-feu configuré ? Quels protocoles sont filtrés/interdits ? (ICMP, TCP, UDP,) [éviter nmap, SSH ou RDP .] Et d'autres plus sensibles : - Quels sont les sous-réseaux, leur IP et leur fonction ? - Quels sont les outils (logiciels) mis en place pour la connexion à distance pour le télétravail ? Là franchement, ça me hérisse le poil. Est-ce que c'est juste moi qui suis trop old school pour ne pas vouloir divulguer des informations à un tiers de "semi-confiance" potentiellement exploitables pour une attaque ? Quels sont vos retours sur la question ? Je ne sais pas ce que dit le droit international, mais pour moi il est hors de question de fournir un plan de mon réseau interne. Communiquer grossièrement quelles sont les mesures de sécurité mises en place, quelles sont les méthodes d'accès aux données pour les collaborateurs, ou comment on gère les droits d'accès en interne, pas de problème. Mais donner le détail de _quel_ anti-virus est installé, c'est trop. La sécurité par l'obscurité n'a jamais protégé personne, mais faut pas déconner quand même. Ils n'ont pas besoin de savoir tout ça. Il me semble que même les banques françaises ne demandent pas ça à leurs prestataires. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Obligation (ou pas) de maintenance des lignes
On 23/02/2024 11:39, Julien LIVENAIS via frnog wrote: Le 23/02/2024 à 09:57, Daniel Caillibaud a écrit : Mon FAI est SFR (ils ont eu un an d'exclusivité sur la fibre), qui m'a envoyé un tech mardi pour constater que ça marchait pas, et depuis, rien… Existe t-il vraiement un cas ou un opérateur d'infrastructure a une exclusivité commerciale sur le réseau FTTH qu'il a déployé ? A ma connaissance, c'est une légende urbaine. Si quelqu'un a des éléments, je suis preneur ! Légende urbaines maintes fois "débunkée" dans cette liste. Il y a confusion avec le délais obligatoire que doit laisser l'OI au marché entre l'annonce de disponibilité du génie civil et la première vente. Enfin, un truc comme ça. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Obligation (ou pas) de maintenance des lignes
On 23/02/2024 16:55, David Ponzone wrote: T’as pas vraiment répondu à ma question: est-ce que tu as vu ce repointage télécommandé par eux ? Je ne suis pas au courant d'un éventuel repointage. Personellement je n'ai rien remarqué (pour mon usage, c'est la connexion de la maison). Je viens de sortir vérifier l'orientation de l'antenne, et il semble qu'elle "regarde" plus à l'ouest qu'avant (avant étant la dernière fois que je l'ai observée, il doit y avoir 6 ou 7 semaines). Tu as des liens vers l'info comme quoi ils auraient réorienté des antennes ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] MTP Gender change
Ça semble pouvoir se faire à la mano avec deux punaises limées. On 25/03/2024 17:53, David Ponzone wrote: Je viens de le regarder mais faut l’outil vendu par Fibertronics je crois. Sérieusement, c’est quoi cette norme de merde, le MTP, qui est pas capable de préciser systématiquement si chaque extrémité est mâle ou femelle. Pas trouvé une doc correcte sur le sujet. Le 25 mars 2024 à 17:49, Paul Rolland (ポール・ロラン) a écrit : Hello, On Mon, 25 Mar 2024 17:26:32 +0100 Armel Chargé-Chauvet // frekences via frnog wrote: Nope, trop facile :) DYI ? https://www.youtube.com/watch?v=NDJbp1y9p4A Paul --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
