Re: [FRnOG] [TECH] Portail publication applis Http/https

2021-11-29 Par sujet Kirth Gersen
J'utilise tailscale.com pour ce genre de chose
on peut inviter des tiers dans son vpn (auth sso & mfa), limiter les accès
via des acl, etc


Le lun. 29 nov. 2021 à 13:09, Philippe M  a écrit :

> Bonjour,
>
> Quelqu'un a t-il des pointeurs interessants pour soft de portail de
> publication
> d'application pour des users nomades (pas simplement un nginx, haproxy).
>
> J'ai un tête un portail destiné à des prestataires externes qui présenterai
> facilement
> quelques icones sur une page Web, puis fonctionnerai en reverse proxy vers
> des serveurs
> internes (applis http/https).
>
> Contraintes:
> - Soft Linux ou Windows
> - Pas d'appliance ou soft Firewall plus complet sous forme de VM.
> - Mieux si MFA (type google authenticator)
> - Mieux si lien avec AD pour les applis publiées selon le user
>
> Merci.
> PM.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Question Free pro backup 4G

2021-11-12 Par sujet Kirth Gersen
bonjour

Le backup Freepro:

- c'est un port WAN spécifique  (format SFP et ils fournissent de base un
module RJ45)
- c'est juste une connexion simple via dhcp. Freepro fournit un petit
routeur 4G preconfiguré mais on peut brancher a la place n'importe quel
dispositif qui donne acces  a Internet (une box adsl/fibre chez un autre
opérateur par exemple, son propre routeur 4G).
- quand la connexion principale est down, la freebox pro sort par le port
backup donc en double NAT via le dispositif branché. A ce moment on change
donc d'ip public (on obtient une IP free mobile avec le modem 4G) et on n'a
plus de sortie IPv6 car voir ce bug :
https://github.com/LaFibre-info/Freepro/issues/10

C'est du backup minimaliste donc et pas très bien conçu.

Le ven. 12 nov. 2021 à 11:00, Thomas BRENAC via frnog  a
écrit :

> Bonjour la liste
>
>
> J'essaye de savoir et comprendre comment fonctionne le backup 4G de
> l'offre Free pro. Comment la box reconnais qu'un port Ethernet est aussi
> modem pouvant fournir un accès internet d'une part et, d'autre part
> suivant les dires du vendeur local, l'adresse IP publique fixe (v4 et
> peut etre v6 ?) est conservée a l'identique lorsque la fibre tombe et
> que le backup 4G fournis l’accès externe.
>
> Si quelqu'un a cette info je suis preneur. Merci !
>
>
> --
> Thomas BRENAC
> +33686263575
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu

2021-03-10 Par sujet Kirth Gersen
On me signale aussi qu'on peut via l'api:
https://fr.wikitwist.com/panne-ovh-comment-utiliser-lapi-pour-changer-votre-zone-dns/

le manager toujours down vu d'ici.

Le mer. 10 mars 2021 à 14:17, Barthélémy DELUY  a
écrit :

> La gestion des DNS via le manager remarche.
>
> C'est méga-lent, mais ça marche.
>
> OVH est comme toutes les autres boites en fait : pour se développer vite,
> ils font des rustines "temporaires" qui ne sont finalement patchées que
> lorsqu'il y a un incident (cf le souci des arrivées électriques il y a
> quelques années).
>
> Le mer. 10 mars 2021 à 14:02, Kirth Gersen  a écrit :
>
>> La priorité des priorités est de permettre de modifier nos DNS
>> hébergés chez OVH pour qu'on puisse faire pointer nos services ailleurs.
>>
>>
>> Le mer. 10 mars 2021 à 13:55, Olivier Breton > >
>> a écrit :
>>
>> > Merci pour les nombreux messages de soutien.
>> > Pour les sceptiques ou critiques, il y a plusieurs canaux officiels de
>> > communication au sein d'OVHcloud à commencer par : travaux.ovh.com
>> > Sinon les infos sont relayées sur LinkedIn (certes boîte US) sur le
>> compte
>> > officiel OVHcloud.
>> > Des communications auprès de la majeure partie des clients sont parties
>> > (où en cours car il y un gros boulot d'inventaire à faire).
>> >
>> > On s'est engagé à communiquer avec la plus grande transparence sur ce
>> gros
>> > incident mais comprenez qu'il y a temps pour tout.
>> > La priorité (une fois les personnels à l'abri) c'est de remettre up nos
>> > clients. Ensuite viendra le temps de la root cause, des explications
>> > détaillées, plan d'action associé etc. Chaque chose en son temps.
>> >
>> > Thanks
>> >
>> > Olivier
>> >
>> > __
>> > This message was sent from OVH Groupe SAS, or one of its subsidiaries or
>> > affiliated entities, and is intended only for the sole use of the
>> > designated recipient(s). It may contain confidential and proprietary
>> > information. If you are not a designated recipient, you may not review,
>> > copy, use or distribute this message. If you received this message in
>> > error, please notify the sender by reply e-mail and delete this message.
>> > Thank you.
>> >
>> >
>> > -Message d'origine-
>> > De : frnog-requ...@frnog.org  De la part de
>> > Mickael MONSIEUR
>> > Envoyé : mercredi 10 mars 2021 12:06
>> > À : Romain 
>> > Cc : Fabien Delmotte ; Emmanuel Jacquet <
>> > m...@formidable-inc.net>; Clement Cavadore ;
>> Johann
>> > ; Oliver varenne ;
>> frnog-alert <
>> > frnog-al...@frnog.org>
>> > Objet : Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu
>> >
>> > Non, ce n'est pas la meilleure option. Et pour plein de raisons.
>> > Je connais énormément d'IT qui ne sont pas sur cette plateforme,
>> > énormément qui l'ont quitté depuis qu'ils se sont montré au grand jour
>> > comme une plateforme ou la liberté d'expression n'a pas sa place, etc
>> etc.
>> > Ils ont une page incident, des ML, un blog, très peu d'informations via
>> > leur canaux internes.
>> > Avec 2500 employés ce n'est pas une excuse.
>> >
>> > Le mer. 10 mars 2021 à 11:56, Romain  a écrit :
>> > >
>> > > Ne crois-tu pas que dans l'urgence et l'idée de toucher un maximum de
>> > monde rapidement, Twitter est la meilleure option ?
>> > > Ce qui n'empêche pas aux équipes de faire les communications
>> nécessaires
>> > derrière.
>> > >
>> > > Le mer. 10 mars 2021 à 11:48, Mickael Monsieur <
>> > mickael.monsi...@gmail.com> a écrit :
>> > >>
>> > >> La communication d’ovh, hébergeur français, c’est avant tout en
>> anglais
>> > sur une plateforme américaine. Et ça viendra encore pleurer pour le
>> cloud
>> > souverain auprès de l’Etat.
>> > >>
>> > >> > Le 10 mars 2021 à 11:42, Fabien Delmotte via frnog <
>> frnog@frnog.org>
>> > a écrit :
>> > >> >
>> > >> > 
>> > >> >>
>> > >> >> Je suis à titre perso simple client pour des VPS. L'info de la
>> > >> >> localisation est dans le dashboard d'OVH. Et pour l'instant pas de
>> > >> >> mail officiel reçu d'OVH.
>> > >> >
>> > >> > Même remarque j’ai un VPS non joignable et aucune communic

Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu

2021-03-10 Par sujet Kirth Gersen
La priorité des priorités est de permettre de modifier nos DNS
hébergés chez OVH pour qu'on puisse faire pointer nos services ailleurs.


Le mer. 10 mars 2021 à 13:55, Olivier Breton 
a écrit :

> Merci pour les nombreux messages de soutien.
> Pour les sceptiques ou critiques, il y a plusieurs canaux officiels de
> communication au sein d'OVHcloud à commencer par : travaux.ovh.com
> Sinon les infos sont relayées sur LinkedIn (certes boîte US) sur le compte
> officiel OVHcloud.
> Des communications auprès de la majeure partie des clients sont parties
> (où en cours car il y un gros boulot d'inventaire à faire).
>
> On s'est engagé à communiquer avec la plus grande transparence sur ce gros
> incident mais comprenez qu'il y a temps pour tout.
> La priorité (une fois les personnels à l'abri) c'est de remettre up nos
> clients. Ensuite viendra le temps de la root cause, des explications
> détaillées, plan d'action associé etc. Chaque chose en son temps.
>
> Thanks
>
> Olivier
>
> __
> This message was sent from OVH Groupe SAS, or one of its subsidiaries or
> affiliated entities, and is intended only for the sole use of the
> designated recipient(s). It may contain confidential and proprietary
> information. If you are not a designated recipient, you may not review,
> copy, use or distribute this message. If you received this message in
> error, please notify the sender by reply e-mail and delete this message.
> Thank you.
>
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Mickael MONSIEUR
> Envoyé : mercredi 10 mars 2021 12:06
> À : Romain 
> Cc : Fabien Delmotte ; Emmanuel Jacquet <
> m...@formidable-inc.net>; Clement Cavadore ; Johann
> ; Oliver varenne ; frnog-alert <
> frnog-al...@frnog.org>
> Objet : Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu
>
> Non, ce n'est pas la meilleure option. Et pour plein de raisons.
> Je connais énormément d'IT qui ne sont pas sur cette plateforme,
> énormément qui l'ont quitté depuis qu'ils se sont montré au grand jour
> comme une plateforme ou la liberté d'expression n'a pas sa place, etc etc.
> Ils ont une page incident, des ML, un blog, très peu d'informations via
> leur canaux internes.
> Avec 2500 employés ce n'est pas une excuse.
>
> Le mer. 10 mars 2021 à 11:56, Romain  a écrit :
> >
> > Ne crois-tu pas que dans l'urgence et l'idée de toucher un maximum de
> monde rapidement, Twitter est la meilleure option ?
> > Ce qui n'empêche pas aux équipes de faire les communications nécessaires
> derrière.
> >
> > Le mer. 10 mars 2021 à 11:48, Mickael Monsieur <
> mickael.monsi...@gmail.com> a écrit :
> >>
> >> La communication d’ovh, hébergeur français, c’est avant tout en anglais
> sur une plateforme américaine. Et ça viendra encore pleurer pour le cloud
> souverain auprès de l’Etat.
> >>
> >> > Le 10 mars 2021 à 11:42, Fabien Delmotte via frnog 
> a écrit :
> >> >
> >> > 
> >> >>
> >> >> Je suis à titre perso simple client pour des VPS. L'info de la
> >> >> localisation est dans le dashboard d'OVH. Et pour l'instant pas de
> >> >> mail officiel reçu d'OVH.
> >> >
> >> > Même remarque j’ai un VPS non joignable et aucune communication. Je
> me suis rendu compte que mon service était « down » et je suis allé
> chercher l’information.
> >> >
> >> > Cordialement
> >> >
> >> >
> >> >
> >> >> Le 10 mars 2021 à 11:26, Emmanuel Jacquet 
> a écrit :
> >> >>
> >> >>> Le mer. 10 mars 2021 à 08:52, Clement Cavadore
> >> >>>  a écrit :
> >> >>>
> >> >>>
> >> >>> Je n'ai rien à SBG, et ne sais pas si c'est communiqué aux
> >> >>> clients,
> >> >>> mais: Les concernés savent dans quel site ils sont habituellement
> >> >>> hébergés ? SBG2 étant brûlé, et une partie de SBG1 impacté, ca
> >> >>> laisse espoir à ceux qui sont hébergés dans les autres salles...
> >> >>>
> >> >>
> >> >> 
> >> >> Je suis à titre perso simple client pour des VPS. L'info de la
> >> >> localisation est dans le dashboard d'OVH. Et pour l'instant pas de
> >> >> mail officiel reçu d'OVH.
> >> >> Manu
> >> >>
> >> >> ---
> >> >> 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/
>
>
> ---
> 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/


Re: [FRnOG] [TECH] IPV6 autoconfiguration stateful

2020-11-12 Par sujet Kirth Gersen
Hello

Le filtrage par adresse n'est peut-être pas la bonne solution (et n'a
jamais été trop une bonne solution pour un LAN).
Faut peut-être revoir la sécurité de façon globale et repenser les choses.
Aborder IPv6 en se contentant de refaire ce qu'on faisait en IPv4 n'est pas
du tout la bonne approche.
Par exemple, ne donner qu'une IPv6 (public) par poste n'est pas recommandé.

tl;dr: DHCPv6 stateful, bof bof. C'est juste chercher à refaire ce qu'on
faisait en IPv4.

Perso je ne recommande pas de vouloir filtrer sur les adresses ce n'est
plus d'actualité de nos jours.
Il faut faire cela plus haut dans les couches réseaux (applicatif
principalement).

C'est que mon avis bien sûr et beaucoup ne le partagent pas car ils veulent
rester dans l'ancien monde IPv4 qu'ils
maîtrisent et ne rien repenser.
Et la bonne approche n'est pas le dual stack non plus mais passer à "IPv6
only" en revoyant tout ou attendre avant
d'aborder IPv6 (bien prendre le temps de se former et d'être prêt).
Le plus gros défaut d'IPv6 c'est qu'il s'appelle IPv6. Cela induit en
erreur pas mal de gens.

Le jeu. 12 nov. 2020 à 22:22, Artur  a écrit :

> Bonsoir à tous,
>
> Je regarde actuellement dhcpv6 pour définir un adressage prévisible à
> l'avance sur un réseau local et permettre un filtrage qui va avec.
> Si ça marche bien entre un serveur Debian/radvd/wide-dhcpv6 et une
> machine Windows10 (pas encore testé avec Linux, mais a priori ça doit
> marcher tout seul), ça ne fonctionne pas du tout avec Android.
> En faisant quelques recherches j'ai vu que Google ne veut pas de dhcpv6
> sur Android
> (
> https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/
> ).
>
> C'est presque vendredi, mais je n'ai pas forcément envie de déclencher
> une polémique sur 350 posts.
> La question au-delà de la position de Google, c'est : A votre
> connaissance, quelle solution pour cette autoconfiguration IPv6 stateful
> sur Android, svp ?
> Ou encore, si dhcpv6 n'est pas la solution adaptée, comment pourrait-on
> mettre en place un filtrage "par terminal" Android en IPv6?
>
> Merci par avance.
>
> --
> Cordialement,
> Artur
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Un autre thread sur la 5G

2020-09-09 Par sujet Kirth Gersen
38 tweets ?! TMTDR (too many tweets didn't read)

https://www.twitlonger.com/

ou https://medium.com



Le mer. 9 sept. 2020 à 16:42, Jérôme Nicolle  a écrit :

> Plop,
>
> La semaine dernière, j'ai publié un thread sur la 5G qui a dépassé
> mes high-scores de vues. Over 120k.
> https://twitter.com/chiwawa_42/status/1301209720808787970
>
> Hier, un ami qui bosse à la commission EU m'a demandé de le refaire en
> anglais, pensant que ça leur servirait. Du coup je l'ai un peu étoffé,
> reformulé, et ça donne ça :
>
> https://twitter.com/chiwawa_42/status/1303676573531492352
>
> J'espère être fidèle à nos valeurs de rationalité technique, et vous
> invite à le lire, commenter et partager, ou surtout de m'engueuler si
> j'ai commis la moindre erreur.
>
> Merci chers confrères !
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Fournisseur de VPS pour du mail

2020-07-07 Par sujet Kirth Gersen
Tu devrais pouvoir mettre ton SPF & co chez Microsoft avec un seul compte
Office 365 Business puis utiliser des "connectors".
Du coup tout le trafic sortant passe par chez MS avec donc des IP de MS.

un truc du genre:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-for-multiple-locations#scenario-4-mx-record-points-to-my-on-premises-server-which-filters-and-provides-compliance-solutions-for-your-messages-your-on-premises-server-needs-to-relay-messages-to-the-internet-through-microsoft-365-or-office-365

(y'a plusieurs façon de faire, et avec l'essai gratuit tu peux tester).

Le mar. 7 juil. 2020 à 16:02, Anthony Bourguignon via frnog 
a écrit :

> Salut la liste,
>
> Je suis à la recherche d'un fournisseur de VPS qui serait ok pour de
> l'envoi de mails. Je m'explique. Pour le moment, mon serveur de mails est
> sur un
> serveur dédié Online. Régulièrement, des grosses plateformes de mails
> (Microsoft principalement, Orange régulièrement) bloquent toute la plage
> d'adresses sur laquelle se trouve le serveur. Je précise que je suis
> toutes les recommandations : SPF, DKIM, DMARC, ARC, ratelimiting en sortie,
> ceinture, bretelle, bref tout est clean. Le trafic qui sort du serveur
> n'est pas dingue (en moyenne, 3 à 4 mails par minute). Afin de contrer le
> passage régulier en denylist, j'ai pris une 2e ip pour le serveur et en
> cas de blocage, j'alterne. Mais comme l'ip n'est pas dans le même bloc, mais
> est quand même une ip notée comme faisant partie de Online pour des
> serveurs dédiés, ça fini par revenir.
>
> Et là, c'est dans le meilleur des cas. C'est à dire qu'on a un bounce qui
> montre que le serveur est bloqué. Chez MS, on aime bien accepter les mails,
> pas d'erreur, mais finalement ils sont envoyés dans /dev/null .
>
> Du coup, je recherche un fournisseur de VPS avec ces caractéristiques :
>   - serveurs en France
>   - IPv4 pas denylistée de base, pas dans un bloc avec des spammers
>   - de l'IPv6 aussi (même juste un /128 ça me va)
>   - prix réglos
>
> Pour la puissance du serveur, c'est pas un souci. Le VPS ne servira que
> comme relay. Donc pas besoin d'espace disque, ni de CPU.
>
> Si jamais vous avez une autre solution qu'un VPS, je suis preneur. Je me
> suis demandé si un VPN (genre celui de FDN) pourrait faire le boulot,
> histoire d'avoir une IP clean. Des idées ?
>
> Merci d'avance pour vos réponses.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] IPv6 forever : IP mais pas route ?

2020-06-11 Par sujet Kirth Gersen
la partie route de RA est par nature plus dynamique, si un routeur
s'annonce lui-même avec un temps infini et disparaît ça n'a pas trop de
sens.
alors que le serveur DHCPv6 peut disparaître ou changer cela n'impactera
pas les machines déjà configurées.

Sinon  on peut envoyer la route via l'option DHCPv6 RT_PREFIX  non ? (pas
testé).

Et RA peut être utiliser pour configurer des SLAAC avec une durée infinie
(ce n'est pas le meme timer, on peut mettre "infinity" sur le prefix
annoncé via RA).

Apres comparer IPv4 et IPv6 est toujours le truc a éviter de faire ;)
Il est mieux d'aborder IPv6 en oubliant complètement IPv4 et en ne
cherchant surtout pas a refaire comme on fait en IPv4.


Le jeu. 11 juin 2020 à 11:12, Laurent GUERBY  a écrit :

> Bonjour,
>
> Pour reproduire un setup IPv6 statique avec les protocoles dynamiques
> je suis arrivé a distribuer en DHCP6 des IPv6 (1) avec duree de vie
> "forever" en suivant la RFC8415 "The value 0x is taken to mean
> "infinity" when used as a lifetime" et j'ai bien "valid_lft forever
> preferred_lft forever" sur la machine.
>
> Mais par contre pour les routes en ICMP6/RA la duree maximum en
> secondes est 0x et je n'ai pas trouvé de moyen de distribuer en RA
> une route a durée de vie infinie.
>
> Est-ce que j'ai raté un bout de RFC qui permettrait de faire ça ?
>
> Sincèrement,
>
> Laurent GUERBY
>
> (1) detail amusant dans mes tests on peut distribuer une IPv6 link
> local statique en DHCP6 a un client, eg fe80::cafe/128 sur son eth0.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] NAT, Free et ports bas

2020-06-09 Par sujet Kirth Gersen
  > C'est totalement "normal". Le CG-NAT de Free à un pool et l'IP externe
> d'un client peut changer après 24h ou plus ou loto... (j'en sais quelque
> chose pour être chez eux... J'ai opté pour l'option "ip fixe").

Ce n'est pas vraiment "normal" car le CG-NAT de Free est différent des
autres CG-NAT.
Il utilise 4rd (rfc7600) donc c'est un système 'stateless': l'IPv4 public
partagée par 4
clients ne change jamais, elle est dérivée des préfixes IPv6 attribués aux
clients.
Il n'y a pas de pool dans lequel on pioche au hasard une IPv4.

Le mar. 9 juin 2020 à 16:09, Ducassou Laurent  a
écrit :

> Le 09/06/2020 à 13:52, fabrice prigent a écrit :
> > Le 09/06/2020 à 09:49, Ducassou Laurent a écrit :
> >> Hello collègue d'université ! :)
> > Hello :-),
> >> Déjà une première question me brule aux lèvres, IPv4 ou IPv6 ? Hélas
> >> je pense connaitre la réponse vu la question :/
> > Pessimisme (et priorités) oblige, l'IPV6 n'est pas géré du tout
> > chez nous.
>
> C'est étrange, j'ai le même son de écho d'église par chez nous dès que
> IP est suivi de "v6" ;)
>
>
> >> Il faut savoir que Free pour ces accès pour contourné le problème de
> >> limitation en IPv4 utilise massivement le CG-NAT comme aucun autre
> >> opérateur en France à ce jour. Tu peux donc sur une seule IPv4 fixe
> >> te retrouver avec 4 "box" (donc encore plus de client potentiellement
> >> !) sauf si le client à clairement demandé une IPv4 dédié définitive
> >> par son espace web. Tu te retrouve donc avec un routeur
> >> client/Freebox qui va "ouvrir" une instance vers ton port 80 depuis
> >> un port "haut" mais le CG-NAT qui peut rabaisser ce port entre
> >> 1-16000/16000-32000/32000-48000/48000-64000 (et des poussières) -si
> >> on considère 4 box par IPv4- de façon totalement random.
> >
> > Effectivement, cela ressemble beaucoup à ce que l'on voit chez
> > nous mais avec, apparemment, le fait que l'IP peut, d'un jour à
> > l'autre, changer de plage.
> >
> > [...]
>
> C'est totalement "normal". Le CG-NAT de Free à un pool et l'IP externe
> d'un client peut changer après 24h ou plus ou loto... (j'en sais quelque
> chose pour être chez eux... J'ai opté pour l'option "ip fixe").
>
>
> >
> >> Hélas, pas 50 solutions, autoriser les "ports bas vers bas" et
> >> configuré un IDS (pas firewall car disons le : chaqu'un son taff !)
> >> pour détecter les vrai scan-port car le CG-NAT tu va en avoir de par
> >> Free mais aussi d'autres opérateurs et PAS QUE Francais (je dis
> >> coucou Erasmus et aux autres étudiants dans des pays encore moins
> >> bien lotis en IPv4).
> > Nous avons une infra qui arrive déjà à gérer ces scan, mais bon,
> > c'était pratique de ne pas avoir à analyser ces tentatives
> > "simplistes" de scan. Je crains que l'option "accepter les ports bas"
> > soit la seule réellement disponible.
>
> Hélas "oui", c'est la seul solution. Après coté IDS, Snort que
> j'utilisais en admin serv était très bon pour envoyer dans les roses
> automatiquement les scan que çà soit sur du
> Web/ssh/ftp/CounterStrike/WoW *sifflote*
>
> Mais sinon, oui, moins vous filtrerez, moins vous aurez de problème du
> genre (je suis pas sur que chez nous les collègues fassent mieux j'admets)
>
>
> >> J'espère que ça t'aidera ce petit retour d'expérience.
> >> Laurent
> >> PS : Vive le rugby et les chocolatines ! :)
> >
> > Aïe, nous risquons de réveiller la team "pain au chocolat". Renvoi
> > au 22. On se prépare...
> Oui mais dans notre team on peux compter sur le Japon et le Canada en
> renfort pour transformer ! ;)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Firewall IPv6 chez Free (et les autres)

2019-05-01 Par sujet Kirth Gersen
Le 'bon sens' et le consensus a l'IETF est qu'il faut mettre
l'utilisateur dans la meme "situation" qu'il était avec IPv4 donc
avoir une espèce de filtrage stateful.

Mais il n'y a pas encore de consensus et best practice officiel sur sa
mise en oeuvre car un filtrage stateful peut avoir des conséquences
sur des futurs protocoles ou évolutions des protocoles actuels. Le
problème est que le code actuel des "stateful filter" en IPv6 copie la
version IPv4 : ca marche qu'avec UDP et TCP. Idéalement il faudrait un
truc qui 'stateful filter' plus largement (ou qui ne filtre qu'udp et
tcp et laisse passer le reste?). L'autre souci est l'ouverture a la
demande d'autres choses qu'UDP ou TCP.

cf aussi les 50 commendations  de la RFC 6902 (
https://tools.ietf.org/html/rfc6092#section-4 ). Je ne pas si la
Freebox les implémente.
La RFC 4864 ( https://tools.ietf.org/html/rfc4864#section-2 ) donne un
bonne base de réflexion aussi meme si elle date un peu sur certains
aspects.

Orange applique un stateful filter 'fort' (udp+tcp only et on ne peut
ouvrir une IPv6 "a tout" par exemple), Free laisse tout passer. Bref a
ce jour aucun des deux n'offre peut-être la bonne solution.

Apres, en pratique, pour le moment,  les usages c'est 99% du TCP ou de
l'UDP vu l'omnipresence du NAT IPv4.

Il faut voir aussi l'impact sur les performances de filtrer surtout
quand on promet du 10 gigabits ..(enfin du 8 Gbits:) ). Le stateful
filter du NAT IPv4 est souvent pris en charge par des accélérateurs
matériels fournit pas les composants hardware. Pas sur qu'ils soient
tous capables de faire cela en IPv6 vu que le NAT en IPv6 n'est pas
une demande. C'est peut-etre simplement pour cela que Free n'a pas de
stateful en IPv6...histoire de ne pas être derniers au speedtest en
IPv6 ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] IPV6 Name and Shame

2019-04-30 Par sujet Kirth Gersen
Ce n'est pas un excuse c'est juste leur méthode: le grand public en
1er, le pro ensuite. Ils ont tout a fait les compétences pour faire du
fixe en DHCP.

C'est du DHCPv6-PD qu'ils font ce qui est le mieux pour déléguer un
/56. On ne peut pas leur reprocher cela.

Pour l'auth c'est prévu ils utilisent les options d'auth de DHCP (v4
et v6). Ca rend d'ailleurs complexe le remplacement des livebox par
des routeurs perso: https://lafibre.info/remplacer-livebox/

On peut difficilement reprocher a Orange de mal faire les choses
niveau réseau (niveau box c'est un autre sujet).

C'est plus qu'ils prennent leur temps vu la taille de leur infra et du
nombre de clients que cela impactent.

Le mar. 30 avr. 2019 à 17:51, Philippe ASTIER
 a écrit :
>
> C’est marrant…
>
> On peut très bien attribuer des IP fixes en DHCP, d’autres le font.
> On peut faire de l’IPv6 sans DHCP, c’est même mieux, d’autres le font.
>
> Bref, c’est un peu des excuses à 2 cents, à
>
> Le souci probable est l’absence de traçage précis dans leurs SI du numéro de 
> série et/ou MAC addreses des box...
> Bref, une infra vieillissante d’un opérateur historique.
>
> Je ne critique pas, c’est un gros paquebot à faire évoluer.
>
> Ou alors je loupe quelque chose ?
>
> Le 30 avr. 2019 à 17:05, Kirth Gersen  a écrit :
>
> Les offres Pro chez Orange sont encore en PPPoE ce qui ne permet
> l'IPv6 sur leur infra mais cela permet l'ip fixe (cf dans l'interface
> de la livebox, page diagnostic/FTTH)
> Le grand public est en train de passer en DHCP ce qui permet IPv6 mais
> pas d'IP fixes (sauf si on ruse pour ne jamais libéré le bail DHCP.).
>
> A terme ils doivent tout passer en DHCP mais pas de date pour le moment.
>
> Le mar. 30 avr. 2019 à 16:37, Barthélémy DELUY  a 
> écrit :
>
>
> Bonjour la liste,
>
> D'ailleurs, en parlant d'IPv6, il y a quelque chose qui empêche Orange de
> l'activer sur les Livebox pro ?
> Je l'ai à la maison sur la box perso, mais sur l'abonnement pro, impossible
> de trouver la moindre info...
>
> On est en train de faire les tests pour rendre notre portail web accessible
> en IPv6, mais obligé de passer par un tunnel SSH à la maison pour vérifier
> que tout fonctionne, ça devient un peu usant à force.
> Si le principal opérateur français ne rend pas le protocole disponible aux
> TPE/PME, ça va devenir compliqué de le répandre.
>
> My 2 cents.
>
> Barth
>
> PS : merci pour le lien du MOOC, ça va servir à mieux dégrossir le sujet :)
>
> Le lun. 29 avr. 2019 à 17:51, Michel Py 
> a écrit :
>
> Michel Py a écrit :
> [...] Sans aucun risque pour moi d'être identifié comme un vieux con,
>
> je me rappelle
>
> de la pub de Léon Zitrone à la télé pour la nouvelle numérotation de
>
> France Télécon
>
> (un lien, quelqu'un ?). Peut-être qu'à l'époque c'était encore les
>
> P.T.T.
>
> Patrick Maigron a écrit :
> Les différents spots TV de l'époque sur le site de l'INA (onglet Pubs) :
>
> https://www.ina.fr/recherche/search?search=ptt+nouvelle+num%C3%A9rotation
>
> Et oui c'était bien les PTtouilles en 1985 !
>
>
> Merci 
> 1985, comme le temps passe.
>
> Et bien, au lieu d'IPv6, c'est ce qu'on aurait du faire : plus de bits,
> nouvelle adresse facilement devinable en connaissant l'ancienne.
>
>
> Xavier Beaudouin a écrit :
> Une PI IPv6 (/48) coûte 50Euros HT (coût LIR), y a de paperasse a faire,
>
> mais
>
> c'est pas le nombre de Lir Sympa qu'il manque sur cette liste. Si tu
>
> prends
>
> donc cette option alors tu as la garantie que tout le taf que tu as fait
>
> pour
>
> migrer en IPv6 est pérenne, bcp plus que ce que tu ferais en avec un /48
>
> chez HE.
>
> Je plussoie, et le raisonnement est valable pour v4 aussi. Faut pas
> investir trop d'argent dans des IP que ne sont pas les tiennes.
> Je compatis avec tes besoins, en v4 le plus petit que tu peux avoir c'est
> un /24 et çà coute quelques milliers d'euros.
>
> Michel.
>
> ---
> 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/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] IPV6 Name and Shame

2019-04-30 Par sujet Kirth Gersen
Les offres Pro chez Orange sont encore en PPPoE ce qui ne permet
l'IPv6 sur leur infra mais cela permet l'ip fixe (cf dans l'interface
de la livebox, page diagnostic/FTTH)
Le grand public est en train de passer en DHCP ce qui permet IPv6 mais
pas d'IP fixes (sauf si on ruse pour ne jamais libéré le bail DHCP.).

A terme ils doivent tout passer en DHCP mais pas de date pour le moment.

Le mar. 30 avr. 2019 à 16:37, Barthélémy DELUY  a écrit :
>
> Bonjour la liste,
>
> D'ailleurs, en parlant d'IPv6, il y a quelque chose qui empêche Orange de
> l'activer sur les Livebox pro ?
> Je l'ai à la maison sur la box perso, mais sur l'abonnement pro, impossible
> de trouver la moindre info...
>
> On est en train de faire les tests pour rendre notre portail web accessible
> en IPv6, mais obligé de passer par un tunnel SSH à la maison pour vérifier
> que tout fonctionne, ça devient un peu usant à force.
> Si le principal opérateur français ne rend pas le protocole disponible aux
> TPE/PME, ça va devenir compliqué de le répandre.
>
> My 2 cents.
>
> Barth
>
> PS : merci pour le lien du MOOC, ça va servir à mieux dégrossir le sujet :)
>
> Le lun. 29 avr. 2019 à 17:51, Michel Py 
> a écrit :
>
> > >> Michel Py a écrit :
> > >> [...] Sans aucun risque pour moi d'être identifié comme un vieux con,
> > je me rappelle
> > >> de la pub de Léon Zitrone à la télé pour la nouvelle numérotation de
> > France Télécon
> > >> (un lien, quelqu'un ?). Peut-être qu'à l'époque c'était encore les
> > P.T.T.
> >
> > > Patrick Maigron a écrit :
> > > Les différents spots TV de l'époque sur le site de l'INA (onglet Pubs) :
> > >
> > https://www.ina.fr/recherche/search?search=ptt+nouvelle+num%C3%A9rotation
> > > Et oui c'était bien les PTtouilles en 1985 !
> >
> > Merci 
> > 1985, comme le temps passe.
> >
> > Et bien, au lieu d'IPv6, c'est ce qu'on aurait du faire : plus de bits,
> > nouvelle adresse facilement devinable en connaissant l'ancienne.
> >
> >
> > > Xavier Beaudouin a écrit :
> > > Une PI IPv6 (/48) coûte 50Euros HT (coût LIR), y a de paperasse a faire,
> > mais
> > > c'est pas le nombre de Lir Sympa qu'il manque sur cette liste. Si tu
> > prends
> > > donc cette option alors tu as la garantie que tout le taf que tu as fait
> > pour
> > > migrer en IPv6 est pérenne, bcp plus que ce que tu ferais en avec un /48
> > chez HE.
> >
> > Je plussoie, et le raisonnement est valable pour v4 aussi. Faut pas
> > investir trop d'argent dans des IP que ne sont pas les tiennes.
> > Je compatis avec tes besoins, en v4 le plus petit que tu peux avoir c'est
> > un /24 et çà coute quelques milliers d'euros.
> >
> > Michel.
> >
> > ---
> > 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/


Re: [FRnOG] [MISC] IPV6 Name and Shame

2019-04-28 Par sujet Kirth Gersen
Je crois surtout qu'il vaut éviter de chercher a généraliser son cas
personnel a la planète entière.

Les problématiques sont très diverses suivent les tailles, topologies
et ou on se situe dans l'éco-systeme. Y'a rien de pire que les
phénomène des  'pensée unique'.
On le voit en ce moment dans les domaine du développement logiciel et
système ou certaines technos 'hyper scalaires' des gros GAFAM sont
reprises ou jugées par tout le monde meme ceux qui n'ont que 2
serveurs et 10 pc.

C'est pareil avec IPv6. Ca ne concerne pas tout le monde pour le
moment et pour ceux que cela concerne il y a plusieurs approches et
façon de faire.

Un opérateur télécom qui n'a pas assez d'IPv4 pour les appareils de
ces clients va chercher a utiliser IPv6. De la ceux qui font les OS de
ces appareils vont faire faire en sorte qu'IPv6 fonctionne
correctement. Ensuite viennent les éditeurs de logiciel pour ces
appareils, puis les hébergeurs des services utiliser par ces
logiciels, etc. Bref y'a un effet de dépendances et de propagation
inéluctable qu'on le veuille ou non. Par exemple, Microsoft est passé
en interne a IPv6 car l'espace IPv4 privé (RFC 1918) était trop petit
pour leur réseau mondial.

Pour le moment tout le monde n'est pas concernés de la meme façon. Si
votre business n'est pas encore impacté par cela, effectivement IPv6
sera superflu, coûteux et n'apportera rien. Et dans ce cas il est meme
sage de l'ignorer pour le moment. Mais gouverner c'est prévoir et un
peu de prospective n'a jamais fait de mal.

Le mieux est de suivre de pres les évolutions et l'adoption d'IPv6
pour savoir si, quand et comment l'adopter par rapport a son cas
personnel.
Bien comprendre la techno et voir comment elle évolue (regarder les
rfc récentes concernant IPv6 est un bon indicateur de tendance).
Échanger & discuter avec ceux qui l'ont mis en oeuvre pour de bonnes
raisons et pas juste pour la 'gloire'.

Bien comprendre aussi qu'IPv6 n'est qu'un protocole réseau, pas une
finalité en soi et qu'il peut cohabiter avec autre chose.
Ce n'est pas un changement disruptif ou fondamental comme la
micro-informatique, Internet, les mobiles voir le cloud l'ont été a
leur époque. Certains défenseurs d'IPv6 en font largement trop a ce
niveau d'ailleurs.

Apres y'a le camp des 'jamais'. Ceux qui croient vraiment que ca ne
servira jamais a rien...c'est un pari non garanti.


Le dim. 28 avr. 2019 à 05:25, Michel Py
 a écrit :
>
> > Barthélémy DELUY a écrit :
> > Le problème d'IPv6, c'est qu'il arrive pour prendre la place d'un protocole 
> > qui
> > est maîtrisé et déjà déployé, et qui répond de façon satisfaisante aux 
> > besoins.
>
> C'est pire que çà. Ce que tu écris est vrai, mais ce n'est pas tout. La 
> relative rareté d'IPv4 est un problème pour ceux qui n'en ont pas, mais est 
> une bénédiction pour ceux qui en ont.
> Si on voulait qu'IPv6 soit adopté, à part les difficultés techniques que tu 
> décris plus bas, il faudrait que tout le monde rame dans la même direction.
> Ce qui n'est pas le cas. Les gens qui ont suffisamment d'IPv4 voient d'un 
> très bon oeuil leur monopole et font tout ce qui est en leur pouvoir pour 
> saboter IPv6.
> Quand la majorité établie qui en plus possède le pognon ne veut pas que çà 
> change, çà ne change pas.
>
> > C'est facile de déployer IPv6 sur de nouvelles infras/nouveaux équipements, 
> > mais c'est
> > beaucoup plus difficile voire impossible de le déployer sur du legacy, ou 
> > simplement de
> > "dépenser du temps" pour mettre à jour une infrastructure existante et qui 
> > fonctionne.
>
> +1
> Du temps et surtout de beaucoup d'argent aussi.
>
> > Tout ça sans compter les dizaines, centaines d'applis propriétaires qui 
> > trainent dans
> > un coin, impossibles à mettre à jour (développeur parti, sources perdues, 
> > éditeur ayant
> > fermé, etc), et dont les librairies de vérification d'IP ne prennent en 
> > compte qu'IPv4.
> > Une petite entreprise n'aura pas les ressources suffisantes pour réaliser
> > cette migration, et un grand groupe n'en verra pas l'intérêt.
>
> +1000
> J'ai éliminé IPX, mais je ne peux pas me permettre d'éliminer DECNET.
> Quand l'outil de production meurt, j'irai boire un bon coup mais pour 
> l'instant je garde.
> J'essaie même pas. Cà va couter des millions, quel est le gain ? IPv6 c'est 
> l'avenir ?
>
> Yàkà faukon. Vieux proverbe Français : les conseilleurs ne sont pas les 
> payeurs.
>
> > Je pense qu'IPv6 va se déployer peu à peu, mais on est pas prêt d'éteindre 
> > IPv4, quand
> > on voit qu'on a encore des serveurs du milieu des années 90 encore en prod 
> > 25 ans après...
>
> Cà c'est bien le truc que les conseilleurs d'IPv6 qui ne payent pas n'ont 
> toujours pas compris : on n'est pas prêt d'éteindre IPv4.
> La seule stratégie de migration a toujours été : dans 2-3 ans tout le monde 
> va avoir IPv6 et on va éteindre IPv4.
> Depuis 20 ans tous les ans il y a une nouvelle génération de petits branleurs 
> arrivistes à la con qui nous ressortent la même FUD d'ont 

Re: [FRnOG] [TECH] IPV6 Name and Shame

2019-04-26 Par sujet Kirth Gersen
Ca fera comme avec HTTPS, un jour Google va décider seul dans son coin
que les sites web sans IPv6 auront un rank réduit et tout le monde va
se précipiter...au debut ca ne concernera que les sites web mais par
effet buzz + influençabilité des DSI ca se propagera.

Le ven. 26 avr. 2019 à 22:30, Pierre Colombier  a écrit :
>
> Critique facile mais non, je ne baisse pas les bras en me disant que ça
> ira bien comme ça jusqu'à ma retraite (d'ailleurs, non, ça n'ira
> probablement pas jusque là.)
>
> Simplement, disposant d'une énergie limitée, je l'emploie
> prioritairement à répondre à la demande exprimée et si il y en avait une
> avec ipv6, je serais prêt à y répondre. C'est pas franchement compliqué
> voir même largement plus simple que de se faire des noeuds au cerveau
> avec des dizaines de règles de dst-nat et des problèmes de conntracking.
> Si le monde entier éteinds le v4 dans 8 jours, ça va être beaucoup de
> taf mais je suis partant et plutôt confiant .
>
> Par contre, me cogner la double stack pour le plaisir de dire que je
> fais de l'internet du futur dont personne n'a rien à branler, bah
> non...  De mon point de vue, il n'y a toujours pas de demande et je suis
> de toute façon trop petit pour espérer avoir la moindre influence en
> jouant la locomotive.
>
> Pour le moment, ce qui est impensable, c'est d'oser se passer de v4 (y
> compris avec 3 nat empilés et autres trucs sales). ça, c'est juste pas
> possible.
>
> Note : 70% ipv6 pour le mail?
>
> Pas sûr qu'il y ait lieu de s'en réjouir. Quel est le niveau de
> corrélation avec gmail+ hotmail+ aws ?
>
>
>
> On 26/04/2019 17:57, Wallace wrote:
> >
> > Ca me fait penser à un client qui refuse à présent tout évolution de
> > ses applications et de son infra pour cause de départ à la retraite
> > dans 4 ans et qu'il ne voit pas l'intérêt de mener toutes ces
> > évolutions et par dépit se dit que ça tiendra bien jusqu'à sa retraite.
> >
> > Dommage de baisser les bras.
> >
> > Y a quelques années au FRNOG Orange avait dit on a suffisamment d'IPv4
> > pour en donner plusieurs à tous les français donc IPv6 n'a pas
> > d'intérêt pour nous, Leboncoin avait dit qu'ils ne voyaient pas non
> > plus l'intérêt et que cela était un coût / contrainte qui n'apportait
> > rien. Mais fin 2019 voir cet été car il va y avoir un dernier rush il
> > n'y aura plus d'IPv4 disponible en Europe. Certes il y aura sans doute
> > de petits subnets par ci par là réattribué au RIPE mais aucun nouvel
> > acteur dans les FAI ne pourra voir le jour sans faire un rachat d'une
> > structure ayant des v4.
> >
> > Les nouveaux acteurs internet ferront du v6 only et utiliseront des
> > CDN ou autre prestations pour avoir une connectivité en v4.
> >
> > Franchement rien pour tout cela je suis content de faire bouger de mon
> > côté et au final 30% du trafic c'est déjà pas mal. En mail on est à
> > 70% comme quoi ça bouge.
> >
> > Le 26/04/2019 à 17:33, Pierre Colombier a écrit :
> >> Bon, c'est trolldi et le sujet s'y prête, il faut bien que je me
> >> lâche...
> >>
> >> Je fais le diagnostique inverse de Wallace.
> >>
> >> IPv6, j'en ai fait mais j'ai arrêté, ou en tout cas j'ai levé le pied.
> >>
> >> Parce-que je me suis rendu compte que ça me consommait pas mal de
> >> temps pour une très faible proportion de trafic.
> >>
> >> Alors désormais je n'en fait que si on me le demande, c'est à dire
> >> moins de 10% des cas.
> >>
> >> Et dans ceux là, les 3/4 n'en veulent pas vraiment. Ils veulent juste
> >> s'assurer que ça ne serait pas un problème si ils le voulaient dans
> >> quelques années.
> >>
> >> A moins que de très gros acteurs ne décident subitement d'éteindre
> >> leur pile v4 (et pourquoi le feraient-ils ?) je pense que dans 10 ans
> >> on aura certainement généralisé le NAT pour tout ce qui n'a pas
> >> impérativement besoin d'ip publique mais que le v4 sera encore
> >> largement majoritaire.
> >>
> >>
> >>
> >>
> >>
> >> On 26/04/2019 10:30, Wallace wrote:
> >>>
> >>> Tous nos serveurs sont IPv6 par défaut avec tous les services
> >>> configurés pour écouter dessus depuis 10 ans, on a banni le NAT IPv4
> >>> on en veut plus.
> >>>
> >>> L'IPv4 est optionnelle surtout pour des serveurs back / DB / ...
> >>> Quand les développeurs veulent y accéder, soit ils font des forwards
> >>> de ports ssh soit on les motive à mettre l'IPv6 et ça marche bien
> >>> après un peu de politique vis à vis des DSI.
> >>>
> >>> C'est à notre échelle mais au moins nos clients sont dans la quasi
> >>> majorité actif en IPv6, ça se voit dans les traffic des serveurs /
> >>> DNS / SMTP 1/3 des connexions se font en v6 only.
> >>>
> >>> Le 26/04/2019 à 09:36, Kevin CHAILLY | Service Technique a écrit :
>  C'est clair, le jour ou Pornhub est en IPv6 only, le taux
>  d'adoption va bondir.
> 
>  29 % D'adoption aux USA et seulement 10 % en France,
> 
>  Nos administrateurs systèmes sont-ils fainéants ? Frileux ? Ou tout
>  simplement entre l'ulcère et la cirrhose ?
> 

Re: [FRnOG] [MISC] Adoption de nouveaux protocoles

2019-03-11 Par sujet Kirth Gersen
> Qui peut citer un seul exemple d'une application concrète, dans laquelle
> 3 milliards de machines ou de personnes ont besoin d'en contacter 3
> milliards d'autres ?

Dans ce cas la téléphonie est un gachi aussi ... Pourquoi on a chacun
un numéro différent et par appareil qui plus est ! Je ne vais jamais
contacter autant de personnes.

Le lun. 11 mars 2019 à 12:34, Toussaint OTTAVI  a écrit :
>
>
> Le 11/03/2019 à 10:27, Samuel Thibault a écrit :
> > Pour que tout reste possible, oui.
>
> C'est quoi, "tout" ?
>
> Mon congélateur a besoin de me prévenir quand la température augmente
> trop. Eventuellement, il peut avoir besoin de prévenir le dépanneur. Et,
> très hypothétiquement, il pourra peut-être un jour commander tout seul
> de la glace à la vanille au Drive du coin quand il détecte qu'il n'y en
> a plus. Cà nous fait donc 3 destinataires, pas 3 milliards.
>
> Par ailleurs, sur ces trois destinataires, un seul aura le droit de se
> connecter sur ledit congélateur pour voir ce qu'il y a dedans. Et en
> aucun cas trois milliards d'illustres inconnus, parmi lesquels un nombre
> incalculable de bots aux intentions peu louables.
>
> Certes, je sais bien que le routage est une chose totalement
> indépendante de la sécurité. Je passe assez de temps à le rabâcher ;-)
> Cependant, je m'interroge sur la pertinence d'un routage vers plusieurs
> milliards de milliards de destinations, sachant que je vais devoir
> toutes les firewaller sauf 3.
>
> Qui peut citer un seul exemple d'une application concrète, dans laquelle
> 3 milliards de machines ou de personnes ont besoin d'en contacter 3
> milliards d'autres ?
>
> Dans tous les domaines de la vie courante, sur ce qui reste encore de
> notre sympathique planète, on cherche aujourd'hui à optimiser,
> rationaliser, économiser, réduire les consommations et les empreintes
> carbone. Et nous, nous devrions nous permettre le luxe de gaspiller des
> milliards de milliards d'adresses, dont seul un pourcentage
> infinitésimal de combinaisons sera réellement utilisé ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Adoption de nouveaux protocoles

2019-03-08 Par sujet Kirth Gersen
De mon coté je constate:

La plupart des gens du métier abordent IPv6 comme si c'était IPv4 avec
plus adresses et des adresses plus grandes. Ils essaient de transposer
leur savoir faire IPv4 directement sans creuser plus la question ou
comprendre les différences fondamentales entre les 2 protocoles. Ce
manque de rigueur et de formation nuit le plus a IPv6. En fait, le
plus grand tord des créateurs d'IPv6 est de l'avoir appelé IPv6...idem
pour DHCPv6, les gens transposent sans chercher a comprendre les
nuances. Les noms portent a confusion et on croit que c'est la meme
chose en "version 2.0"...

On le voit dans ce sujet, plein de personnes font juste la
transposition directe de qu'ils connaissent en IPv4 a IPv6 (sécurité,
renumérotation si changement de FAI, interco de réseaux privés, etc).

La meilleur façon d'aborder IPv6 c'est de complètement oublié IPv4. Ne
pas chercher a refaire comme c'était en IPv4. Bien se former et
comprendre les concepts propre a IPv6.
Par exemple: on a des tonnes d'adresses dispo et de types différents
(link-local, ula, gua). On n'est pas forcé d'utiliser les IP public
(gua) pour causer en interne. On peut avoir plein d'addresses par
machines notamment plusieurs gua et plusieurs ula. On peut ainsi
changer les adresses gua de tout un parc d'un coup en quelques
secondes sans perturber les flux internes . On peut utiliser les
link-local pour l'imprimante ou l'iot qui se trouve sur le meme
segment, pour la gateway locale ou pour un lien point a point, etc et
non SLAAC sur un serveur ce n'est pas forcement "le mal", il y a les
"ip token" notamment.

Bref y'a plein de façons de faire suivant sa typo, sa taille, ses
ressources humaines, son contexte, ses prestataires, sa sécurité,
etc. faut juste oublier comment on faisait avec IPv4 et faire un
design propre et adapté...commencer par se forcer correctement.

Un autre grand tord fait a IPv6 c'est de vouloir imposer le "dual
stack" et parler de transition. Pour un petit serveur web public
pourquoi pas, derriere une box grand public pourquoi pas. Mais en
entreprise sur un réseau interne complexe non. D'ailleurs pas mal de
gens attendent que les environments 'ipv6 only' soit stables pour
basculer (IPv6 only + passerelles vers legacy IPv4 ) plutôt que de
devoir gérer le complexité et le coût d'un dual stack, surtout si ca
n'apporte rien en pratique...

Le ven. 8 mars 2019 à 14:04, David Ponzone  a écrit :
>
> Côté sécu IPv6, je viens de recevoir ça:
>
> https://www.internetsociety.org/deploy360/ipv6/security/faq/ 
> 
>
>
> > Le 8 mars 2019 à 11:57, Radu-Adrian Feurdean 
> >  a écrit :
> >
> > On Fri, Mar 8, 2019, at 00:23, Florent H. CARRÉ (COLUNDRUM) wrote:
> >> À l'heure actuelle, le passage en full IPv6 est actuellement bloqué de
> >> mon côté parce qu'on perdrait l'avantage d'avoir un firewall d'étage,
> >> un firewall global de site …
> >
> > N'importe quoi.
> > Deployer du v6 (v6-only ou dual-stack, peu importe) ne t'emepeche pas 
> > d'avoir un firewall. Ou plusieurs firewalls. Cote securite, c'est meme 
> > reccomande a un certain moment.
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] DHCPv6 Server sur MikroTIK

2019-02-28 Par sujet Kirth Gersen
au vue de la conf, c'est le serveur DHCPv6 qui envoi les parametres
DNS aux postes. C'est donc dans la conf du serveur DHCPv6 qu'il faut
régler cela.

managed-address-configuration=yes -> indique aux postes de se
configurer une IPv6 avec DHCPv6 (= pas de SLAAC sur les postes)
other-configuration=yes -> indique aux postes de configurer leur
autres parametres (dont la config DNS) avec DHCPv6
advertise-dns=yes -> c'est RDNSS = config DNS dans les "router
advertisement" (RA)  mais les postes peuvent l'ignorer vu que
other-configuration=yes

Windows 7 ne supporte RDNSS il faut donc du DHCPv6 pour régler la conf DNS IPv6
Windows 10 supporte les 2 modes mais je ne connais pas son
comportement quand les 2 sont actifs (pas que qu'ils respectent la
reco de: https://tools.ietf.org/html/rfc8106#section-5.3.1 ).

En mixte Windows 7 & 10 comme ca, autant faire du DHCPv6 (pas
forcement statefull comme ici).

Le jeu. 28 févr. 2019 à 17:52, Sébastien 65  a écrit :
>
> Bonsoir à tous,
>
> Je n'arrive pas à faire monter les @ IPV6 des DNS dans "Serveurs DNS" des 
> cartes réseaux sous Windows 10. Sous Windows 7 je n'ai pas de problème...
>
> J'ai la configuration suivante :
>
> /ip dns
> set allow-remote-requests=yes servers=\
> 2001:4860:4860::,2620:0:ccc::2,8.8.8.8,8.8.4.4
> /ipv6 nd
> set [ find default=yes ] advertise-dns=yes interface=bridge \
> managed-address-configuration=yes other-configuration=yes
> /ipv6 nd prefix
> add autonomous=no interface=bridge
>
> Est-ce que je fais une erreur quelque part sur la configuration ?
>
> Une autre question mais sur le service DHCP IPv4, pourquoi dans la liste 
> "Serveurs DNS" de la carte Windows 7 ou 10 j'ai aussi l'IPv4 du routeur 
> MikroTIK, je ne trouve pas comment enlever 192.168.88.1 pour laisser 
> uniquement ceux définis dans la liste "/ip dns" ?
>
> Sébastien
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] SD-WAN encore !

2019-02-05 Par sujet Kirth Gersen
s/TECH/BIZ/

merci

Le mar. 5 févr. 2019 à 15:34, Michel Hostettler
 a écrit :
>
> Bonjour,
>
> Le SD-WAN peut être traité avec mépris, et même être ignoré... Le seul ennui, 
> il nous rattrapera un jour et nous réveillera crûment.
> https://www.hubone.fr/oneblog/sd-wan-vagues/
>
> Je rappelle que nous avons lancé une formation sur cette technique de gestion 
> des réseaux :
> https://www.telecom-evolution.fr/fr/formations-courtes/la-revolution-sd-wan-chez-les-operateurs-de-transport-de-donnees
>
> Cordialement, Michel
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Solution/Software pour corrélation d'IPs unitaires avec une liste de subnets

2019-02-04 Par sujet Kirth Gersen
Un exemple en ruby trouvé sur gist: https://gist.github.com/Eising/1923695

En cherchant sur gist on devrait trouver la même dans d'autres languages.

Le lun. 4 févr. 2019 à 15:04, Francois Petillon 
mailto:fan...@proxad.net>> a écrit :
On 2/4/19 3:01 PM, David Ponzone wrote:
> Python est ton ami:
> https://docs.python.org/3/library/ipaddress.html 
> 

Et, pour PERL, il y a le module Net::IP::Match::Regexp

François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] solution serveur IM/chat libre

2018-12-20 Par sujet Kirth Gersen
Attention Mattermost c'est payant si on veut l'intégration LDAP/AD
pour la base de comptes ($30/user/an). Mais c'est le meilleur du
moment. C'est vraiment le Slack self-hosted.

L'installation est simple et rapide. Docker est optionnel. Et il y a
des tonnes d'intégrations possibles (in, out et sous forme de slash
commandes )...dont Giphy et Hubot qui sont indispensables ...

sinon: 
https://github.com/Kickball/awesome-selfhosted#custom-communication-systems

On Thu, Dec 20, 2018 at 10:32 AM Rémy Grünblatt  wrote:
>
> Bonjour,
>
> j'ai comparé récemment les solutions disponibles.
>
> Dans ce que j'ai retenu, il y a:
>
> - IRC;
> - XMPP ( https://xmpp.org/ );
> - Mattermost ( https://mattermost.com/ );
> - Rocket.chat ( https://rocket.chat );
> - Zulip ( https://zulipchat.com/ );
> - Matrix ( https://matrix.org/blog/home/ );
>
> Dans les questions importantes à se poser, à mon avis:
>
> - Quelles intégrations avec les systèmes existants: authentification
> centralisée, intégration des barbus avec leur client IRC préféré?
> - Quelles interfaces et pour quel public?
> - Quel volume d'utilisateurs: 10, 100, 1000 ?
> - Quel besoin de modération?
> - Quelle communauté, quelle pérennité?
> - Quels « à côté » (par rapport à l'IM): partage de fichiers, vidéo, audio?
>
> Sans ces informations, c'est compliqué de se prononcer.
>
> Par exemple, mattermost, c'est assez convivial (pour non-tech), y'a une
> grosse communauté, mais pour 1000 utilisateurs il va falloir sortir les
> ressources. À l'opposé, XMPP (serveur) va être très léger, mais les
> interfaces (clients) sont en général moins conviviales et l'écosystème
> plus « fragmenté » (deux clients quelconques n'auront pas les mêmes XEPs
> implémentées). Matrix, c'est nouveau, ça tente de tout faire (et de
> rassembler plusieurs réseaux différents), mais pour l'instant
> l'interface principale (riot.im) est très brouillon et surchargée. Bref,
> y'a plein de solutions, et elles ont toutes leurs spécificités.
>
>
> Rémy
>
> Le 20/12/2018 à 01:08, Michel Py a écrit :
> > Bonsoir à tous et à toutes,
> >
> > Je recherche une solution d'IM / chat, installée localement, logiciel libre.
> > Au hasard je suis tombé sur https://rocket.chat, est-ce que quelqu'un a un 
> > retour ?
> > Je prends les suggestions aussi, un truc tout emballé qui juste marche çà 
> > me conviendrait.
> > Probablement basé sur XMPP, mais là aussi je prends les idées.
> >
> > Michel.
> >
> >
> > ---
> > 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/


Re: [FRnOG] [MISC] [INFO][FREE] Arret du service SIP le 31/12/2018

2018-12-13 Par sujet Kirth Gersen
Oui, je crois que la grande majorité des usagers aptes a utiliser ce
genre de chose a quitté Free depuis longtemps :)

On Thu, Dec 13, 2018 at 6:33 PM Guillaume GARNIER
 wrote:
>
> Salut salut,
>
> il n'y a que moi que ça émeut ?
> on est si peu nombreux à l'utiliser ?
>
>
> ++
>
> Guillaume
>
>
>  Message transféré 
>
>
> Cher(e) Freenaute,
>
> A compter du 31/12/2018, le service SIP permettant d'utiliser votre
> ligne téléphonique Freebox à partir de n'importe quel ordinateur
> connecté à Internet disposant d'un micro et de haut-parleurs sera
> arrêté.
>
> Le service téléphonique classique, via un téléphone branché derrière
> votre Freebox, n'est pas impacté.
>
> L'équipe Free
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Collecteur de logs réseau

2018-11-18 Par sujet Kirth Gersen
 +1 pour ne pas confondre 'time series" (TSDB) fait pour accumuler des metrics 
(compteurs,etc) genre utilisation cpu ou température avec l'indexation et le 
stockage de logs (document database).

Sinon pour convertir des logs en metrics, il y a mtail  ( 
https://github.com/google/mtail ) ou grok-exporter ( 
https://github.com/fstab/grok_exporter )

mtail est particulièrement simple et efficace, on peut matcher la chaine 'Port 
x disconnected' par exemple pour extraire le 'x' et en faire un metric.

On Mon, Nov 19, 2018 at 2:39 AM DUVERGIER Claude 
mailto:frnog...@claude.duvergier.fr>> wrote:
Je m'incruste...

> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient
> plus clair.

Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé
de transformer un message d'événement :
* "Port x disconnected"
* "User x logged-in"
* etc.

En métrique :
* "port_x_connected=false"
* "port_x_disconnection_count=42"
* "user_x_logged=true"
* "user_x_login_count=666"

Soit parce qu'on a pas le contrôle sur le générateur de l'événement
(équipement fermé) soit parce qu'on pense que ça n'est pas à
l'application instrumenté de se souvenir des événements -nombre
d'authentification- pour les transformer en métriques).

Donc je me demande si vous n'auriez pas 2/3 suggestions de solution
(logiques ou logicielles) à ce "problème"...

--
Duvergier Claude

Le 18/11/2018 à 17:41, Raphael Mazelier a écrit :
>
>>
>> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU,
>> par rapport à une time-series basique, que c'est totalement
>> disproportionné.
>
> Désolé mon petit José mais je crois qu'on confond un peu tout la ;)
>
> ES et une TSDB ce sont bien évidement deux type d'outils complètement
> différends qui sont parfois employé/dévoyé de leur fonction originale.
>
>
> En très gros résumé :
>
> - on stocke des métriques dans un tsdb et on fait des graphs et de
> l'alerting avec. Prometheux/Influxdb sont les candidats du moment.
>
> - on on stocke des documents indexés dans ES, parfait pour stocker des
> logs structurés et faire des queries dedans.
>
> Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de
> l'alerting avec des logs, ce qui est théoriquement assez faux.
>
>>
>> C'est pratique à mettre en place et exploitable à petite échelle, mais
>> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis
>> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à
>> nouveau prochainement.
>
> ES est le truc le plus scalable du monde. Je connais des petites société
> smart qui exploitent sereinement des clusters de plusieurs Peta.
>
>>
>> Reste à assurer la corrélation d’évènements, et le déclenchement
>> d'alertes sur certains combos, mais là on rentre dans du compliqué.
>> Tendance obligatoirement du code custom. Sauf si vous avez trouvé
>> autre chose ?
>
> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient plus
> clair.
>
> Cdt,
>
> --
> Raphael Mazelier
>
>
>
> ---
> 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/


Re: [FRnOG] [TECH] Collecteur de logs réseau

2018-11-16 Par sujet Kirth Gersen
l’agrégateur a la mode c'est https://www.fluentd.org/  (une des briques du 
https://www.cncf.io/projects/ ). voir ensuite les 'output' ou plugins qui 
conviendrai.

cdt

On Fri, Nov 16, 2018 at 3:56 PM David Ponzone 
http://gmail.com>> wrote:
Pattern de logs, oui.

Je pense que je vais tester logstash comme aggrégateur de syslog 
Cisco/Mikrotik/Juniper/… vers une stream unique GELF à destination de l’offre 
Graylog en SaaS d’OVH, qui a le bon goût d’avoir un pricing progressif sans 
singularités (ça va de 1€ à 9€/mois, oui oui, 90k€…), parfait pour un petit 
besoin.


> Le 16 nov. 2018 à 14:42, Raphael Mazelier 
> mailto:r...@futomaki.net>> a écrit :
>
> On 16/11/2018 10:18, David Ponzone wrote:
>> Je me pose des questions existentielles pour trouver LE collecteur de logs 
>> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
>> faible et peu critique.
>
> Pour la collecte de log d'équipements réseaux tu n'as globalement pas le 
> choix d'utiliser le protocole syslog pour envoyer.
>
> Hormis les outils SAAS voici ce que je connais.
>
> En pur collecteur tu peux utiliser rsyslog/logstash/fluentd.
> Ensuite tu veux sans doute stocker tes logs dans un format qui permet 
> l'analyse. ES est parfait pour cela.
>
> Pour la gui Kibana evidement.
>
> Si tu veux une solution plus intégré essaye Graylog2, personnelement je 
> trouve cela assez sympa.
>
> En revanche pour l'alerting je ne sais pas ce que tu veux faire ?
> Alerting sur les trap snmp ? Alerting sur des patterns de logs ?
>
>
>
> Cdt,
>
> --
> Raphael Mazelier
>
>
>
> ---
> 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/


Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-22 Par sujet Kirth Gersen
Docker c'est relativement 'bas niveau' par rapport au besoin  exprimé.
je partirai plutôt sur du Kubernetes (abrégé en k8s) ou au dessus (OpenShift, 
Tectonic, etc).
Les 3 gros cloud providers du moment (Google GCP, Amazon AWS , Microsoft Azure) 
ont des solutions k8s avec un net avantage a Google pour docker/k8s (c'est la 
techno interne utilisé chez Google donc en terme de 'ca marche en prod' c'est 
plus rassurant que chez Microsoft par exemple)

Mais être 'provider' agnostic ca ne va pas être forcement simple et introduite 
une complexité plus grande que de modif le code en cas de changement de 
provider. C'est l'avantage de k8s: c'est juste des fichiers de conf a changer 
pour passer du stockage Google au stockage AWS par exemple, le 'driver' de k8s 
s'occupe du reste. Avec la notion de namespace (prod, preprod, dev) çà rejoint  
un peu le 'rêve' exprimé par l'OP.

Et pour ce qui est des anti-Docker en prod, ils sont soient resté bloqués 
quelques années en arrière soit leur job est menacé par ce genre de techno donc 
leur propos sont a relativiser fortement :)



Le ven. 22 sept. 2017 à 08:35, Stéphane Cottin 
> a écrit :
Bonjour Gaël,

Je peux te faire un retour d'expérience sur du docker en prod, ça
fonctionne très bien ... si tu n'utilises pas docker ( ça c pour
trolldi )

J'ai monté plusieurs archis avec Apache Mesos, qui te permet
d'instancier des containers à partir d'images docker sans avoir a
installer aucun outil docker.
Par rapport à la génération précédente (Mesos < 1.0) qui utilisait
le daemon docker, cela n'a plus rien à voir en terme de stabilité /
fluidité (plus de GC, tout est en c++) / consommation CPU "à vide" /
heures de support.

ArangoDB dispose d'un framework Mesos, cela peut être une bonne
solution pour ton besoin.

Stéphane

On 21 Sep 2017, at 23:04, Gaël Demette wrote:

> Bonsoir la liste,
>
> Aujourd'hui se pose la question de modifier notre infrastructure,
> actuellement exclusivement chez AWS (Ireland), en effet notre stack à
> la base assez simple commence à se complexifier avec nos évolutions
> à venir. Du coup, Elastic Beanstalk commence à ne plus être
> suffisant. On voudrait surtout en profiter pour abstraire le
> fournisseur de Cloud. Malheureusement, notre petite startup n'a pas le
> temps de faire tout cela, et souhaiterait étudier la possibilité
> d'externaliser ces évolutions.
>
> J'avais en tête de tout passer sur Docker. Il faudrait donc faire
> cette prestation, ainsi que nous former sur le fonctionnement de
> l'infrastructure faite.
>
> Stack actuel :
>
> * S3 pour deux applications EmberJS (SPA)
> * AWS Elastic Beanstalk (Avec nginx + NodeJS) -> Deux environnements,
> le premier l'API (REST et websockets), le second une app NuxtJS (SPA
> avec server-side rendering)
> * AWS ElastiCache (Redis)
> * Simple replicaset MongoDB (sur des EC2)
>
> Stack cible :
>
> * ArangoDB
> * RabbitMQ (non fixé, si vous avez des suggestions sur des
> alternatives, on est ouvert)
> * MongoDB (On ne souhaite pas tout migrer sur ArangoDB d'un coup sans
> plus de feedbacks)
> * Plus de EmberJS
> * Probablement plus de Redis (Pub/Sub couverte par RabbitMQ, key-value
> storage couvert par ArangoDB), ça ne me gène pas de rester sur
> ElastiCache le temps que nos devs fassent le nécessaire ;)
> * Trois environnements "AWS Elastic Beanstalk like", API + Website
> (NuxtJS) + Backoffice (Anciennement les deux apps EmberJS,
> nouvellement NuxtJS avec Server side rendering)
>
> Mon rêve serait d'avoir une infra qu'on puisse utiliser tant pour
> mettre en place des environnements à la volée, identiques à la
> prod, et ce de manière agnostique du fournisseur de serveurs / cloud,
> Docker semblait faire sens ici. "Plus qu'à" ajouter un système
> permettant de scale, monitor, et self heal et on est bon.
>
> Il me faudrait des propositions commerciales pour ce genre de
> prestation, n'hésitez pas à me contacter en privé, avec un ordre de
> prix. Et en me demandant les informations qu'il vous faudrait pour un
> devis. Il me faudra un devis assez détaillé pour que je puisse
> choisir en retirant des choses dedans si le budget ne correspond pas.
> Il va falloir que l'on fasse ces évolutions, mais peut être pas tout
> d'un coup (Si seulement mes budgets étaient illimités...)
>
> En vous souhaitant une bonne soirée,
>
> Gaël
>
>
> ---
> 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/


Re: [FRnOG] [BIZ] Refonte infrastructure

2017-09-22 Par sujet Kirth Gersen
Docker c'est relativement 'bas niveau' par rapport au besoin  exprimé.
je partirai plutôt sur du Kubernetes (abrégé en k8s) ou au dessus (OpenShift, 
Tectonic, etc).
Les 3 gros cloud providers du moment (Google GCP, Amazon AWS , Microsoft Azure) 
ont des solutions k8s avec un net avantage a Google pour docker/k8s (c'est la 
techno interne utilisé chez Google donc en terme de 'ca marche en prod' c'est 
plus rassurant que chez Microsoft par exemple)

Mais être 'provider' agnostic ca ne va pas être forcement simple et introduite 
une complexité plus grande que de modif le code en cas de changement de 
provider. C'est l'avantage de k8s: c'est juste des fichiers de conf a changer 
pour passer du stockage Google au stockage AWS par exemple, le 'driver' de k8s 
s'occupe du reste. Avec la notion de namespace (prod, preprod, dev) çà rejoint  
un peu le 'rêve' exprimé par l'OP.

Et pour ce qui est des anti-Docker en prod, ils sont soient resté bloqués 
quelques années en arrière soit leur job est menacé par ce genre de techno donc 
leur propos sont a relativiser fortement :)



Le ven. 22 sept. 2017 à 08:35, Stéphane Cottin 
> a écrit :
Bonjour Gaël,

Je peux te faire un retour d'expérience sur du docker en prod, ça
fonctionne très bien ... si tu n'utilises pas docker ( ça c pour
trolldi )

J'ai monté plusieurs archis avec Apache Mesos, qui te permet
d'instancier des containers à partir d'images docker sans avoir a
installer aucun outil docker.
Par rapport à la génération précédente (Mesos < 1.0) qui utilisait
le daemon docker, cela n'a plus rien à voir en terme de stabilité /
fluidité (plus de GC, tout est en c++) / consommation CPU "à vide" /
heures de support.

ArangoDB dispose d'un framework Mesos, cela peut être une bonne
solution pour ton besoin.

Stéphane

On 21 Sep 2017, at 23:04, Gaël Demette wrote:

> Bonsoir la liste,
>
> Aujourd'hui se pose la question de modifier notre infrastructure,
> actuellement exclusivement chez AWS (Ireland), en effet notre stack à
> la base assez simple commence à se complexifier avec nos évolutions
> à venir. Du coup, Elastic Beanstalk commence à ne plus être
> suffisant. On voudrait surtout en profiter pour abstraire le
> fournisseur de Cloud. Malheureusement, notre petite startup n'a pas le
> temps de faire tout cela, et souhaiterait étudier la possibilité
> d'externaliser ces évolutions.
>
> J'avais en tête de tout passer sur Docker. Il faudrait donc faire
> cette prestation, ainsi que nous former sur le fonctionnement de
> l'infrastructure faite.
>
> Stack actuel :
>
> * S3 pour deux applications EmberJS (SPA)
> * AWS Elastic Beanstalk (Avec nginx + NodeJS) -> Deux environnements,
> le premier l'API (REST et websockets), le second une app NuxtJS (SPA
> avec server-side rendering)
> * AWS ElastiCache (Redis)
> * Simple replicaset MongoDB (sur des EC2)
>
> Stack cible :
>
> * ArangoDB
> * RabbitMQ (non fixé, si vous avez des suggestions sur des
> alternatives, on est ouvert)
> * MongoDB (On ne souhaite pas tout migrer sur ArangoDB d'un coup sans
> plus de feedbacks)
> * Plus de EmberJS
> * Probablement plus de Redis (Pub/Sub couverte par RabbitMQ, key-value
> storage couvert par ArangoDB), ça ne me gène pas de rester sur
> ElastiCache le temps que nos devs fassent le nécessaire ;)
> * Trois environnements "AWS Elastic Beanstalk like", API + Website
> (NuxtJS) + Backoffice (Anciennement les deux apps EmberJS,
> nouvellement NuxtJS avec Server side rendering)
>
> Mon rêve serait d'avoir une infra qu'on puisse utiliser tant pour
> mettre en place des environnements à la volée, identiques à la
> prod, et ce de manière agnostique du fournisseur de serveurs / cloud,
> Docker semblait faire sens ici. "Plus qu'à" ajouter un système
> permettant de scale, monitor, et self heal et on est bon.
>
> Il me faudrait des propositions commerciales pour ce genre de
> prestation, n'hésitez pas à me contacter en privé, avec un ordre de
> prix. Et en me demandant les informations qu'il vous faudrait pour un
> devis. Il me faudra un devis assez détaillé pour que je puisse
> choisir en retirant des choses dedans si le budget ne correspond pas.
> Il va falloir que l'on fasse ces évolutions, mais peut être pas tout
> d'un coup (Si seulement mes budgets étaient illimités...)
>
> En vous souhaitant une bonne soirée,
>
> Gaël
>
>
> ---
> 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/


Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange

2017-03-31 Par sujet Kirth Gersen
a priori si ça marche , on peut avoir 2 IP, du moins pour le moment...et donc 
on  peut même mettre un switch derrière l'ONT et brancher un routeur pppoe en 
parallèle avec sa livebox (si celle ci est en DHCP bien sur).


Le ven. 31 mars 2017 à 12:28, Bensay 1 
> a écrit :
Il y a de forte chance que tu n'obtiennes pas 2 adresse car tes identifiants ne 
seront autorisé qu'une seule fois.

À tester mais je doute.

Cdt

Benjamin

> Le 31 mars 2017 à 11:23, Laurent CARON 
> > a écrit :
>
>> Le 30/03/2017 à 13:19, Arnaud Launay a écrit :
>>
>> Typiquement sur un SG300:
>>
>>
>> qos advanced
>>
>> ip access-list extended dhcp
>>  permit udp any bootps any bootpc ace-priority 20
>>  permit udp any bootpc any bootps ace-priority 40
>> exit
>>
>> mac access-list extended vlan-832
>>  permit any any vlan 832 ace-priority 20
>> exit
> 
>>
>> Un grand merci à x0r pour une bonne partie de la conf :-)
>>
>>
>> Et en passant je confirme que le dhcp v6 fournit bien un PD.
>>
>
> Bonjour,
>
> Je viens de vérifier, nous sommes bien vendredi.
>
> Je me suis posé la question suivante:
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 832 via dhcp 
> (options 77 et 90)
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 835 via ppp
>
> Est-il possible d'obtenir 2 @IP différentes (une dans le VLAN 832 et une dans 
> le 835) ?
>
> Dans quel but ?
>
> Adresser 2 machines, ... adresser un serveur VPN, carte d'admin, ...
>
> Qui se lance et nous fait un test ?
>
> Il est bien sûr possible qu'orange ait prévu le coup...
>
>
>
>
> ---
> 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/


Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange

2017-03-31 Par sujet Kirth Gersen
a priori si ça marche , on peut avoir 2 IP, du moins pour le moment...et donc 
on  peut même mettre un switch derrière l'ONT et brancher un routeur pppoe en 
parallèle avec sa livebox (si celle ci est en DHCP bien sur).


Le ven. 31 mars 2017 à 12:28, Bensay 1 
> a écrit :
Il y a de forte chance que tu n'obtiennes pas 2 adresse car tes identifiants ne 
seront autorisé qu'une seule fois.

À tester mais je doute.

Cdt

Benjamin

> Le 31 mars 2017 à 11:23, Laurent CARON 
> > a écrit :
>
>> Le 30/03/2017 à 13:19, Arnaud Launay a écrit :
>>
>> Typiquement sur un SG300:
>>
>>
>> qos advanced
>>
>> ip access-list extended dhcp
>>  permit udp any bootps any bootpc ace-priority 20
>>  permit udp any bootpc any bootps ace-priority 40
>> exit
>>
>> mac access-list extended vlan-832
>>  permit any any vlan 832 ace-priority 20
>> exit
> 
>>
>> Un grand merci à x0r pour une bonne partie de la conf :-)
>>
>>
>> Et en passant je confirme que le dhcp v6 fournit bien un PD.
>>
>
> Bonjour,
>
> Je viens de vérifier, nous sommes bien vendredi.
>
> Je me suis posé la question suivante:
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 832 via dhcp 
> (options 77 et 90)
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 835 via ppp
>
> Est-il possible d'obtenir 2 @IP différentes (une dans le VLAN 832 et une dans 
> le 835) ?
>
> Dans quel but ?
>
> Adresser 2 machines, ... adresser un serveur VPN, carte d'admin, ...
>
> Qui se lance et nous fait un test ?
>
> Il est bien sûr possible qu'orange ait prévu le coup...
>
>
>
>
> ---
> 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/


Re: [FRnOG] [TECH] max MTU sur ONT FTTH Orange

2017-03-31 Par sujet Kirth Gersen
a priori si ça marche , on peut avoir 2 IP, du moins pour le moment...et donc 
on  peut même mettre un switch derrière l'ONT et brancher un routeur pppoe en 
parallèle avec sa livebox (si celle ci est en DHCP bien sur).


Le ven. 31 mars 2017 à 12:28, Bensay 1 
> a écrit :
Il y a de forte chance que tu n'obtiennes pas 2 adresse car tes identifiants ne 
seront autorisé qu'une seule fois.

À tester mais je doute.

Cdt

Benjamin

> Le 31 mars 2017 à 11:23, Laurent CARON 
> > a écrit :
>
>> Le 30/03/2017 à 13:19, Arnaud Launay a écrit :
>>
>> Typiquement sur un SG300:
>>
>>
>> qos advanced
>>
>> ip access-list extended dhcp
>>  permit udp any bootps any bootpc ace-priority 20
>>  permit udp any bootpc any bootps ace-priority 40
>> exit
>>
>> mac access-list extended vlan-832
>>  permit any any vlan 832 ace-priority 20
>> exit
> 
>>
>> Un grand merci à x0r pour une bonne partie de la conf :-)
>>
>>
>> Et en passant je confirme que le dhcp v6 fournit bien un PD.
>>
>
> Bonjour,
>
> Je viens de vérifier, nous sommes bien vendredi.
>
> Je me suis posé la question suivante:
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 832 via dhcp 
> (options 77 et 90)
> - Sachant qu'il est possible d'obtenir une IP dans le VLAN 835 via ppp
>
> Est-il possible d'obtenir 2 @IP différentes (une dans le VLAN 832 et une dans 
> le 835) ?
>
> Dans quel but ?
>
> Adresser 2 machines, ... adresser un serveur VPN, carte d'admin, ...
>
> Qui se lance et nous fait un test ?
>
> Il est bien sûr possible qu'orange ait prévu le coup...
>
>
>
>
> ---
> 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/


Re: [FRnOG] [TECH] SiXXs Sunset

2017-03-27 Par sujet Kirth Gersen
cela a commencé depuis peu: 
https://lafibre.info/orange-les-news/actualites-ipv6-orange/msg425076/#msg425076

Le lun. 27 mars 2017 à 20:08, Alarig Le Lay 
> a écrit :
On lun. 27 mars 19:55:06 2017, Pierre Emeriaud wrote:
> > Effectivement, mais je ne suis pas éligible fibre ou VDSL chez Orange.
> > Merci pour le retour.
>
> ça arrive sur adsl (en collecte ethernet).

T’as une idée de l’ETA approximatif des premières mises en prod ?

--
alarig

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] SiXXs Sunset

2017-03-27 Par sujet Kirth Gersen
cela a commencé depuis peu: 
https://lafibre.info/orange-les-news/actualites-ipv6-orange/msg425076/#msg425076

Le lun. 27 mars 2017 à 20:08, Alarig Le Lay 
> a écrit :
On lun. 27 mars 19:55:06 2017, Pierre Emeriaud wrote:
> > Effectivement, mais je ne suis pas éligible fibre ou VDSL chez Orange.
> > Merci pour le retour.
>
> ça arrive sur adsl (en collecte ethernet).

T’as une idée de l’ETA approximatif des premières mises en prod ?

--
alarig

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] IPv6 chez Orange (grand public)

2017-02-28 Par sujet Kirth Gersen
La livebox envoi un lifetime de 180s dans des RA toutes les minutes environ. Ca 
ne doit pas sauter en principe:

conf RA dans les livebox a fin 2016:
parameter MaxRtrAdvInterval = 60;
parameter MinRtrAdvInterval = 30;

Par contre si c'est via wifi et que la réception est très mauvaise et que 3 
annonces RA de suite sont perdues alors cela pourrait expliquer le problème...

Le mar. 28 févr. 2017 à 13:49, adrien nayrat 
> a écrit :
Bonjour

J'ai un abonnement Fibre (play fibre) avec une livebox 4.

Je constate régulièrement des lenteurs lorsque je navigue sur internet.
Après investigation, mon pc (linux) perd sa route par défaut régulièrement.

J'ai fait une trace et visiblement la livebox envoie des RA avec un
lifetime de 180s. Sauf qu'elle ne les envoie pas très souvent :

Router lifetime (s): 180

No. Time  Source
Destination   Protocol Length Info
   4036 2017-02-28 13:25:39.829938563 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
   6048 2017-02-28 13:30:12.737962534 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
   8619 2017-02-28 13:32:37.232300684 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  12062 2017-02-28 13:33:17.329002478 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  16980 2017-02-28 13:34:15.568686585 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  23659 2017-02-28 13:36:35.986103345 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  25414 2017-02-28 13:40:04.637073659 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  25812 2017-02-28 13:40:55.418318032 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0

Parfois toutes les minutes, parfois moins souvent. Du coup mon pc perd sa
route par défaut régulièrement :(

Feb 28 13:05:53 anayrat-dalibo NetworkManager[3460]: 
[1488283553.7873] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:09:39 anayrat-dalibo NetworkManager[3460]: 
[1488283779.9362] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:25:39 anayrat-dalibo NetworkManager[3460]: 
[1488284739.8316] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:30:12 anayrat-dalibo NetworkManager[3460]: 
[1488285012.7401] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:40:04 anayrat-dalibo NetworkManager[3460]: 
[1488285604.6390] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS


Constatez vous les mêmes choses?

Merci

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] IPv6 chez Orange (grand public)

2017-02-28 Par sujet Kirth Gersen
La livebox envoi un lifetime de 180s dans des RA toutes les minutes environ. Ca 
ne doit pas sauter en principe:

conf RA dans les livebox a fin 2016:
parameter MaxRtrAdvInterval = 60;
parameter MinRtrAdvInterval = 30;

Par contre si c'est via wifi et que la réception est très mauvaise et que 3 
annonces RA de suite sont perdues alors cela pourrait expliquer le problème...

Le mar. 28 févr. 2017 à 13:49, adrien nayrat 
> a écrit :
Bonjour

J'ai un abonnement Fibre (play fibre) avec une livebox 4.

Je constate régulièrement des lenteurs lorsque je navigue sur internet.
Après investigation, mon pc (linux) perd sa route par défaut régulièrement.

J'ai fait une trace et visiblement la livebox envoie des RA avec un
lifetime de 180s. Sauf qu'elle ne les envoie pas très souvent :

Router lifetime (s): 180

No. Time  Source
Destination   Protocol Length Info
   4036 2017-02-28 13:25:39.829938563 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
   6048 2017-02-28 13:30:12.737962534 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
   8619 2017-02-28 13:32:37.232300684 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  12062 2017-02-28 13:33:17.329002478 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  16980 2017-02-28 13:34:15.568686585 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  23659 2017-02-28 13:36:35.986103345 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  25414 2017-02-28 13:40:04.637073659 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0
--
No. Time  Source
Destination   Protocol Length Info
  25812 2017-02-28 13:40:55.418318032 fe80::267f:20ff:fe2c:67c0
ff02::1   ICMPv6   158Router Advertisement from
24:7f:20:2c:67:c0

Parfois toutes les minutes, parfois moins souvent. Du coup mon pc perd sa
route par défaut régulièrement :(

Feb 28 13:05:53 anayrat-dalibo NetworkManager[3460]: 
[1488283553.7873] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:09:39 anayrat-dalibo NetworkManager[3460]: 
[1488283779.9362] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:25:39 anayrat-dalibo NetworkManager[3460]: 
[1488284739.8316] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:30:12 anayrat-dalibo NetworkManager[3460]: 
[1488285012.7401] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS
Feb 28 13:40:04 anayrat-dalibo NetworkManager[3460]: 
[1488285604.6390] policy: set 'Livebox-67C0' (wlp3s0) as default for IPv6
routing and DNS


Constatez vous les mêmes choses?

Merci

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

2016-10-01 Par sujet Kirth Gersen
faut se méfier des apparences aussi. le site orange.fr a 
peut-etre sa page principale en IPv6 mais celle-ci pour afficher correctement 
fait appel a encore pas de mal de choses en IPv4...y compris chez 
orange.fr

donc c'est plus compliqué que ca.

résultat avec IPvFoo:

www.orange.fr 2a01:c9c0:b3:3000::73
all.orfr.adgtw.orangeads.fr 
193.252.149.167

assistance.orange.fr   193.252.133.9

boutique.orange.fr   79.99.35.99

c.orange.fr 193.252.122.51

c.woopic.com   81.52.142.226

cdn.adgtw.orangeads.fr   193.252.133.109

encrypted-tbn1.gstatic.com   
2a00:1450:400c:c0b::71

hp5.a.woopic.com   2a01:c9c0:a3:8::71

hp5.b.woopic.com   2a01:c9c0:b3:3000::74

hp5.d.woopic.com   2a01:c9c0:a3:8::71

iapref.orange.fr   80.12.255.80

mdsp.orange.fr   194.250.131.65

media.pns.orange.fr 81.52.142.240

proxymedia.woopic.com 193.252.122.108

pushinternet.woopic.com 193.252.122.44

s.gstat.orange.fr 193.252.148.221

statsv6.woopic.com   193.252.122.43

tags.tiqcdn.com 68.232.35.180

test-ds.woopic.com   2a01:c9c0:b3:170::43

test-v4.woopic.com   193.252.122.43

test-v6.woopic.com   2a01:c9c0:b3:170::43

vra.outbrain.com   104.85.41.231

vrp.outbrain.com   64.202.112.26

vrt.outbrain.com   64.202.112.26

www.googletagservices.com 
2a00:1450:4007:80e::2002


www.mediapeo3.com 79.99.33.235

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Conférence Network@Scale

2016-05-24 Par sujet Kirth Gersen
J'ai mis les vidéos sur Youtube ici:
https://www.youtube.com/playlist?list=PLyB_05G-OKOFOSyWhZFmme-SNU-TQUVRc
car les videos Facebook ca n'est pas mon truc...

Il se peut que je les supprime quand/si la chaîne officielle @scale les
publiera elle-même:
https://www.youtube.com/channel/UCd9I8ZkgoR1d7GeSj_wi_LQ/feed

K.

Le mar. 24 mai 2016 à 23:15, Eugène Ngontang  a écrit :

> Nice 
> Le 24 mai 2016 21:38, "Florian Stosse"  a écrit
> :
>
> > Plop la liste,
> >
> > Les vidéos de la conférence Network@Scale, avec des choses intéressantes
> > sur les infras de Facebook, AT, Google, le JPL, and more, sont dispos
> > à cette adresse :
> >
> >
> https://code.facebook.com/posts/1036362693099725/networking-scale-may-2016-recap/
> >
> > Il y a même quelques trucs intéressants pour les fans d'IPv6.
> >
> > Bonne soirée,
> >
> > Florian STOSSE | Apprenti-ingénieur sécurité informatique
> > Bureau Veritas - Service Sûreté de fonctionnement | ESIEA Paris
> >
> > PGP : 0x6DEC51D1
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Question assez basique sur routage ipv6

2015-11-16 Par sujet Kirth Gersen
en IPv6 il faut éviter de 'transposer' ce qu'on sait et fait en IPv4 mais
plutôt repartir de zéro et utiliser les nouveautés qu'apporte IPv6.

Entre autres: l'autoconf (stateless config) et les messages ICMPv6 RA et
le DHCPv6 (qui est différent du v4).

IPv6 est censé rendre plus simple la configuration des adresses et du
routage.
Y'a guerre que dans les routeurs qu'on est encore tenu de configurer des IP
a la main et encore pas tout le temps car il y a le mécanisme de PD (prefix
delegation).

Dans l'exemple indiqué si la passerelle est bien configurée elle enverra
des 'RA' (Router Advertisement) pour se signaler et signaler aussi le
prefix réseau.
Les machines sur le segment peuvent s'autoconfigurer avec ca. Les machines
statiquement configurées peuvent apprendre la route de sortie.

Ne pas oublier aussi que en principe les machines s'autoconfigurent aussi
une IPv6 "link-local" (qui commence par fe80:) qui leur permet de
communiquer en IPv6 sur un meme segment.
Ces IP link-local peuvent aussi servir pour la route publique par défaut.
Donc dans l'exemple ici on peut utiliser l'ip link-local comme passerelle
par défaut si on veut vraiment faire une config manuelle (non recommandé)
mais en principe cette info vient du RA.

Apres comme quelqu'un a déjà dit , il faudrait avant toute chose faire un
plan d’adressage et découper le /29.


Le 16 novembre 2015 14:18, Julien Escario  a écrit :

> Bonjour,
> Nous sommes en train de déployer ipv6 sur notre backbone (no troll inside)
> et
> j'aurais une petite question qui va certainement vous paraître basique sur
> la
> façon de monter la gateway.
>
> On a obtenu une /29 du RIPE (c'est tout frais) : 2a06:ac00::/29
> On va filer un /64 par VM (on verra ensuite pour les serveurs mais ça
> risque
> d'être du /56 ou /48).
>
> J'ai fait l'annonce BGP et collé l'ip 2a06:ac00::1/29 sur l'interface côté
> LAN.
> Ca pingue, on est contents.
>
> Maintenant, je voudrais filer l'IP 2a06:ac00:4201::1/64 à une VM. J'ai
> fait :
> # ifconfig eth0 inet6 add 2a06:ac00:4201::1/64
>
> Et c'est là que c'est plus chiant : cette VM va avoir besoin d'une gateway
> par
> défaut :
> # route -A inet6 add default gw 2a06:ac00::1 dev eth0
> SIOCADDRT: Aucun chemin d'accès pour atteindre l'hôte cible
>
> Ah ben ouais, ce n'est pas le même subnet ...
>
> Du coup, j'ai triché en rajoutant ça :
> # route -A inet6 add 2a06:ac00::1 dev eth0
>
> Mais ça me paraît bien crado comme façon de faire.
>
> J'ai loupé un truc mais pas moyen de mettre le doigt dessus. Ou alors c'est
> normal en ipv6 et il me manque encore quelques bases.
>
> Une idée sur la façon de faire ça ?
>
> Merci
> Julien
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Question assez basique sur routage ipv6

2015-11-16 Par sujet Kirth Gersen
Oui c'est fréquent parce qu'ils n'ont pas fiabilisé cette partie, ou mal
réglé des lifetimes ou pas penser aux points de failure (spof).
Souvent la solution est de revenir en arrière et faire comme en IPv4, ce
qui se comprend et c'est très humain (moindre effort et domaine connu).
Il faudra du temps pour qu'on abandonne nos habitudes issue d'IPv4, surtout
tant qu'on fera du double stack.

Apres y'a serveurs et serveurs aussi. Tout le monde n'en a pas le même
nombre et ils n'ont pas tous la même criticité.
Il n'y a pas de recette unique et heureusement.

ps: il y a un MOOC en cours sur IPv6 ici:
https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about


Le 16 novembre 2015 17:41, Wallace <wall...@morkitu.org> a écrit :

> Oui il y a des avantages à utiliser ces mécanismes pour des objets, des
> postes utilisateurs, des mobiles mais clairement pas sur des serveurs.
> Les quelques prestataires que j'ai testé en qualité ipv6 tout ceux qui
> ont des mécanismes automatiques d'attribution n'ont pas su apporter la
> fiabilité sur la stack v6, perte du lease et dhcp qui répond plus, RA HS
> du coup isolation réseau, 
> Mettre des ip en static sur des serveurs ça n'a rien de choquant et au
> contraire on s'assure que ça ne changera pas et que cette partie ne
> tombera pas en cas de problème sur l'annonce ou la découverte de
> l'environnement.
>
>
> Le 16/11/2015 16:59, Kirth Gersen a écrit :
> > en IPv6 il faut éviter de 'transposer' ce qu'on sait et fait en IPv4 mais
> > plutôt repartir de zéro et utiliser les nouveautés qu'apporte IPv6.
> >
> > Entre autres: l'autoconf (stateless config) et les messages ICMPv6 RA
> et
> > le DHCPv6 (qui est différent du v4).
> >
> > IPv6 est censé rendre plus simple la configuration des adresses et du
> > routage.
> > Y'a guerre que dans les routeurs qu'on est encore tenu de configurer des
> IP
> > a la main et encore pas tout le temps car il y a le mécanisme de PD
> (prefix
> > delegation).
> >
> > Dans l'exemple indiqué si la passerelle est bien configurée elle enverra
> > des 'RA' (Router Advertisement) pour se signaler et signaler aussi le
> > prefix réseau.
> > Les machines sur le segment peuvent s'autoconfigurer avec ca. Les
> machines
> > statiquement configurées peuvent apprendre la route de sortie.
> >
> > Ne pas oublier aussi que en principe les machines s'autoconfigurent aussi
> > une IPv6 "link-local" (qui commence par fe80:) qui leur permet de
> > communiquer en IPv6 sur un meme segment.
> > Ces IP link-local peuvent aussi servir pour la route publique par défaut.
> > Donc dans l'exemple ici on peut utiliser l'ip link-local comme passerelle
> > par défaut si on veut vraiment faire une config manuelle (non recommandé)
> > mais en principe cette info vient du RA.
> >
> > Apres comme quelqu'un a déjà dit , il faudrait avant toute chose faire un
> > plan d’adressage et découper le /29.
> >
> >
> > Le 16 novembre 2015 14:18, Julien Escario <esca...@azylog.net> a écrit :
> >
> >> Bonjour,
> >> Nous sommes en train de déployer ipv6 sur notre backbone (no troll
> inside)
> >> et
> >> j'aurais une petite question qui va certainement vous paraître basique
> sur
> >> la
> >> façon de monter la gateway.
> >>
> >> On a obtenu une /29 du RIPE (c'est tout frais) : 2a06:ac00::/29
> >> On va filer un /64 par VM (on verra ensuite pour les serveurs mais ça
> >> risque
> >> d'être du /56 ou /48).
> >>
> >> J'ai fait l'annonce BGP et collé l'ip 2a06:ac00::1/29 sur l'interface
> côté
> >> LAN.
> >> Ca pingue, on est contents.
> >>
> >> Maintenant, je voudrais filer l'IP 2a06:ac00:4201::1/64 à une VM. J'ai
> >> fait :
> >> # ifconfig eth0 inet6 add 2a06:ac00:4201::1/64
> >>
> >> Et c'est là que c'est plus chiant : cette VM va avoir besoin d'une
> gateway
> >> par
> >> défaut :
> >> # route -A inet6 add default gw 2a06:ac00::1 dev eth0
> >> SIOCADDRT: Aucun chemin d'accès pour atteindre l'hôte cible
> >>
> >> Ah ben ouais, ce n'est pas le même subnet ...
> >>
> >> Du coup, j'ai triché en rajoutant ça :
> >> # route -A inet6 add 2a06:ac00::1 dev eth0
> >>
> >> Mais ça me paraît bien crado comme façon de faire.
> >>
> >> J'ai loupé un truc mais pas moyen de mettre le doigt dessus. Ou alors
> c'est
> >> normal en ipv6 et il me manque encore quelques bases.
> >>
> >> Une idée sur la façon de faire ça ?
> >>
> >> Merci
> >> Julien
> >>
> >>
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Fwd: New TLD in IANA whois: CISCO

2015-05-16 Par sujet Kirth Gersen
C'est en cours:
https://gtldresult.icann.org/application-result/applicationstatus/viewstatus
puis saisir 'juniper'

2015-05-16 13:24 GMT+02:00 Stephane Bortzmeyer bortzme...@nic.fr:

 Un TLD pour les routeurs. À quand le .JUNIPER ?

 [Querying whois.iana.org]
 [whois.iana.org]
 % IANA WHOIS server
 % for more information on IANA, visit http://www.iana.org
 % This query returned 1 object

 domain:   CISCO

 organisation: Cisco Technology, Inc.
 address:  170 West Tasman Drive San Jose, CA 95134 USA
 address:  United States

 contact:  administrative
 name: Joshua Bourne
 organisation: FairWinds Partners, LLC
 address:  170 West Tasman Drive San Jose, CA 95134 USA
 address:  United States
 phone:+1 202 223 9252
 fax-no:   +1 202 223 9256
 e-mail:   bourne...@fairwindspartners.com

 contact:  technical
 name: Sean Kaine
 organisation: Neustar, Inc.
 address:  46000 Center Oak Plaza, Sterling VA 20166
 address:  United States
 phone:+1 571 434 5168
 fax-no:   +1 571 434 5401
 e-mail:   registrytechnic...@neustar.biz

 nserver:  NS1.DNS.NIC.CISCO 156.154.144.44 2610:a1:1071:0:0:0:0:2c
 nserver:  NS2.DNS.NIC.CISCO 156.154.145.44 2610:a1:1072:0:0:0:0:2c
 nserver:  NS3.DNS.NIC.CISCO 156.154.159.44 2610:a1:1073:0:0:0:0:2c
 nserver:  NS4.DNS.NIC.CISCO 156.154.156.44 2610:a1:1074:0:0:0:0:2c
 nserver:  NS5.DNS.NIC.CISCO 156.154.157.44 2610:a1:1075:0:0:0:0:2c
 nserver:  NS6.DNS.NIC.CISCO 156.154.158.44 2610:a1:1076:0:0:0:0:2c
 ds-rdata: 45115 8 1 E59D3DC3DA29339EC585252997B1B02D9679DF86
 ds-rdata: 45115 8 2
 F1EA02F8D77CB5BB395497D4EFDFCD33C545284EE32C53F78E3FF5443E477402

 status:   ACTIVE
 remarks:  Registration information: http://www.cisco.com

 created:  2015-04-16
 changed:  2015-05-15
 source:   IANA

 - End forwarded message -


 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/