Re: [FRnOG] [TECH] Migration de switch HP vers Cisco

[Thierry Chich]

Bonjour,

Fudrait peut-être faire un show int FastEthernet0/1 histoire de voir dans quel 
état elle est, 
cette interface ?

Le mardi 23 mai 2017, 18:25:57 CEST Alarig Le Lay a écrit :
> Bonsoir,
> 
> J’ai voulu traduire une conf de switch HP vers Cisco, mais le port
> cogent ne veut pas remonter avec la conf Cisco. Quand je dis « ne monte
> pas », rien que la LED ne clignote pas (ni en orange ni en vert). Et
> bien sûr, si je branche autre chose que cogent dessus, ça marche.
> 
> Ça me parait tellement bête que je me demande si je n’ai pas raté un
> truc qui est juste sous mon nez. Ou alors, il y a quelque chose qui
> dérange cogent…
> 
> Voici la conf HP :
> interface 1
>speed-duplex 100-full
>exit
> vlan 20
>name "interco cogent"
>untagged 1,6
>tagged 2,4,Trk1
>no ip address
>exit
> 
> Et la conf Cisco :
> interface FastEthernet0/1
>  switchport access vlan 20
>  switchport mode access
>  speed 100
>  duplex full
> 
> Merci pour vos idées,


Cordialement 



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

Re: [FRnOG] [TECH] Qualité 3G+ en baisse ?

[Thierry Chich]

Bonjour,


C'est tout à fait ma perception aussi. A telle point que fût un temps, j'avais 
préféré 
désactiver la 4G de mon téléphone.


Cdt
Le mercredi 31 mai 2017, 10:55:46 CEST Toussaint OTTAVI a écrit :
> Le 30/05/2017 à 17:07, David Ponzone a écrit :
> > Ca fait un moment que je me demande si avec l’essor de la 4G, il n’y
> > aurait pas une baisse de qualité plus ou moins naturelle sur la 3G+.
> 
> Ce que je constate, en me déplaçant au milieu de mes montagnes, c'est
> que la perception globale de la qualité du réseau est de plus en plus
> dégradée. Chez nous, il y a de la 3G de façon assez homogène de partout,
> et de la 4G dans les grandes villes ou les lieux touristiques. La
> technologie du handover n'était déjà pas optimale dans une seule
> technologie. Alors avec plusieurs technologies, çà pédale dans la
> semoule... Ce que je constate souvent, c'est que, dès que le terminal
> détecte "un peu" de 4G, il tente de basculer dessus. Sauf que la 4G est
> reçue faiblement depuis un site lointain, et disparaît au bout de
> quelques centaines de mètres. Alors qu'il y a de la 3G bien stable à
> coté. Ce qui amène à des situations ubuesques où je passe au pied d'un
> pylône 3G, mais les communications data sont interrompues pendant
> plusieurs minutes :-(
> 
> J'ai cru bien faire en mettant un routeur 3G/4G avec deux antennes en
> MIMO sur le toit de la voiture. Résultat : c'est pire, car çà capte plus
> de signaux 4G lointains, et le terminal passe plus de temps à "pomper"
> entre 3G et 4G (quand il n'est pas tout simplement dans les choux...)
> 
> Une solution consiste à bloquer le terminal en 3G. Je perds les
> avantages de la 4G là ou il y en a. Mais j'ai un fonctionnement perçu
> comme plus stable lorsque je me déplace.
> 
>   (Ceci étant, je reconnais que mon besoin est assez atypique : je
> cherche de la stabilité pendant que je me déplace, alors que la plupart
> des gens veulent un réseau stable depuis un point fixe).
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/




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

Re: [FRnOG] [TECH] Qualité 3G+ en baisse ?

[Thierry Chich]

En fait, je faisais ça pour avoir moins de perturbations sur la voix. Parce que 
ça sert aussi à ca, le téléphone.

Cela dit, je n'ai jamais trop su si l'amélioration relevait juste du placébo. 
N'étant pas spécialiste de la téléphonie mobile, je m'expliquais la chose d'une 
manière similaire à celle exposée plus bas. Mais je suis tout à fait ouvert à 
une infirmation argumentée.Le 1 juin 2017 09:39, Richard Klein 
<varicap@gmail.com> a écrit :
>
> Et vous avez essayé de brider en 2G pour faire de la Data . Très souvent il 
> y a des applis qui sont en timeout tellement les réseaux sont performants. 
>
> Richard 
>
>
> Le 1 juin 2017 à 09:27, Thierry Chich <thierry.ch...@ac-clermont.fr> a 
> écrit : 
>
> > Bonjour, 
> > 
> > 
> > C'est tout à fait ma perception aussi. A telle point que fût un temps, 
> > j'avais préféré 
> > désactiver la 4G de mon téléphone. 
> > 
> > 
> > Cdt 
> > Le mercredi 31 mai 2017, 10:55:46 CEST Toussaint OTTAVI a écrit : 
> > > Le 30/05/2017 à 17:07, David Ponzone a écrit : 
> > > > Ca fait un moment que je me demande si avec l’essor de la 4G, il n’y 
> > > > aurait pas une baisse de qualité plus ou moins naturelle sur la 3G+. 
> > > 
> > > Ce que je constate, en me déplaçant au milieu de mes montagnes, c'est 
> > > que la perception globale de la qualité du réseau est de plus en plus 
> > > dégradée. Chez nous, il y a de la 3G de façon assez homogène de partout, 
> > > et de la 4G dans les grandes villes ou les lieux touristiques. La 
> > > technologie du handover n'était déjà pas optimale dans une seule 
> > > technologie. Alors avec plusieurs technologies, çà pédale dans la 
> > > semoule... Ce que je constate souvent, c'est que, dès que le terminal 
> > > détecte "un peu" de 4G, il tente de basculer dessus. Sauf que la 4G est 
> > > reçue faiblement depuis un site lointain, et disparaît au bout de 
> > > quelques centaines de mètres. Alors qu'il y a de la 3G bien stable à 
> > > coté. Ce qui amène à des situations ubuesques où je passe au pied d'un 
> > > pylône 3G, mais les communications data sont interrompues pendant 
> > > plusieurs minutes :-( 
> > > 
> > > J'ai cru bien faire en mettant un routeur 3G/4G avec deux antennes en 
> > > MIMO sur le toit de la voiture. Résultat : c'est pire, car çà capte plus 
> > > de signaux 4G lointains, et le terminal passe plus de temps à "pomper" 
> > > entre 3G et 4G (quand il n'est pas tout simplement dans les choux...) 
> > > 
> > > Une solution consiste à bloquer le terminal en 3G. Je perds les 
> > > avantages de la 4G là ou il y en a. Mais j'ai un fonctionnement perçu 
> > > comme plus stable lorsque je me déplace. 
> > > 
> > >   (Ceci étant, je reconnais que mon besoin est assez atypique : je 
> > > cherche de la stabilité pendant que je me déplace, alors que la plupart 
> > > des gens veulent un réseau stable depuis un point fixe). 
> > > 
> > > 
> > > --- 
> > > 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] Attaques en série

[Thierry Chich]

Bonjour,



Le mercredi 27 septembre 2017, 22:57:08 CEST Raphael Mazelier a écrit :
> Yep c'est une technique. (et cogent doit faire).
> Ceci dit il faut que ton trafic in passe déjà naturellement par le
> transitaire qui te fournit le port poubelle. Si n'est pas le cas tu es
> obligé de désagréger, ce qui est pénible si le ddoseur s'amuse à faire
> du random.
> 
> Sinon vu que tu te fais quand même attaquer souvent je pense que prendre
> un transit qui propose une vrai solution de filtrage anti ddos sera un
> bon investissement.
> 


Tout à fait. D'autant que toute cette histoire de DDoS sur base de spoofing 
d'adresse est 
quand même essentiellement une question économique. On a des opérateurs qui ne 
veulent pas faire filtrage sur les adresses sources de chez eux parce que ça ne 
leur 
rapporte rien et des transitaires qui s'enfichent parce qu'au fond, ça ne pose 
des 
problèmes qu'aux destinataires qui eux n'ont aucun moyen sérieux de réaction.

Si les transitaires qui s'en fichent perdent de l'argent, ils vont investir 
dans des solutions 
de filtrage, augmenter leurs prix, mais aussi commencer à se dire qu'en 
identifiant les 
opérateurs les plus laxistes, en les bridant , ils pourront faire des économies 
et redevenir 
concurrentiels. On peut imaginer que si ça se généralise, les opérateurs 
commenceront à 
intégrer de l'anti-spoofing chez eux pour éviter de voir leurs clients s'en 
aller chez le 
concurrent.

Je ne sais plus dans quel article de Sigcomm j'avais lu ça, mais effectivement, 
ça parait de 
bon sens que si un marché se créé sur la question du ddos, voire de la sécu en 
général au 
niveau des FAI, il pourrait y avoir des progrès intéressants.

Thierry 

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

Re: [FRnOG] [MISC] SFR à la ramasse, ne produit plus de SDSL ?

[Thierry Chich]

Bonjour,

Il ne faut pas oublier la latence, surtout pour un lien dédié téléphonie. 
D'expérience, sur 
un même site, on peut avoir 8ms sur de la SDSL et 40 en ADSL. Qui est plus est, 
sur le 
second, cette latence varie dans le temps (indépendamment de la charge, cela va 
sans 
dire). 

D'ailleurs, si quelqu'un peut m'expliquer à quoi correspondent ses grandes 
variations ? J'ai 
sous les yeux un site qui pendant 6 mois était à 35ms et qui est passé à 40 
depuis, avec 
des pics sur un mois à 45ms. C'est du à des changements de routes chez les 
opérateurs ?


Le mercredi 6 décembre 2017, 10:43:09 CET Michel Hostettler a écrit :
> Pour SDSL, un débit de 2 Mbit/s, symétrique, par paire, est possible sur une
> distance maximum de 1,5 km (avec GTR).
> 
> A cette distance, pour VDSL2, le débit peut être de 25 Mbit/s en descendant,
> et 5 Mbit/s en montant, pour le profil 17a (...donc sans GTR). En outre, si
> l'équipement le permet, vous pouvez avoir un chemin de transmission E1
> sécurisé, doublé d'un chemin de transmission Ethernet à faible latence.
> 
> Quand vous dites "c'est trop loin", à quelles encablures du DSLAM vous
> situez-vous ?
> 
> Cordialement,
> Michel
> 
> 
> - Mail original -
> De: "Toussaint OTTAVI" 
> Cc: "frnog" 
> Envoyé: Mercredi 6 Décembre 2017 10:21:21
> Objet: Re: [FRnOG][MISC] SFR à la ramasse, ne produit plus de SDSL ?
> 
> Le 05/12/2017 à 18:59, Michel Hostettler a écrit :
> > En 2017, bientôt 2018, je trouve qu'il existe mieux que SDSL à 2 Mbit/s,
> > symétrique, par paire, sur une distance maximum de 1,5 km.
> 
> En secours d'une fibre 10M, un SDSL ne me paraît pas du tout
> inapproprié. C'est une technologie distincte, sur une adduction
> (presque) distincte. Et c'est fiable. Le VDSL est soumis à une
> contrainte de distance. Dans mon cas, c'est trop loin. Et, même si cette
> notion reste assez virtuelle chez nous, il n'y a pas de GTR sur un VDSL.
> Personnellement, j'aurais choisi un SDSL chez un opérateur distinct de
> l'opérateur fibre. Mais dans ce cas, la solution technique est définie
> par la maison mère. Donc, j'essaye simplement de faire mon mieux avec ce
> que l'on me donne ;-)
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


Cordialement-- Thierry 

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

Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?

[Thierry Chich]

Bonjour,

PhpIPAM m'a déçu. On gère bien ses adresses, mais on a des difficultés à gérer 
des sites. 

Je m'explique: soit tu crées des répertoires pour tes sites et tu mets tes 
réseaux dedans, 
soit tu fais ta hiérarchie de réseaux-sous-réseaux. 
Dans ce dernier cas,  mais tu n'a pas la notion de site (à moins qu'un site= 1 
réseau, mais 
c'est trop facile dans ce cas-là). 
Problème dans le premièr cas, tu perds tous les gains de la vue par 
réseaux-sous-réseaux 
(comme de savoir facilement quelles sont tes adresses encore libre, quel 
pourcentage tu 
utilise vraiment, etc.)



Le mercredi 23 mai 2018, 08:31:48 CEST Sylvain COUTANT a écrit :
> On 05/23/2018 02:51 AM, Michel Py wrote:
> > Pour IPAM je suis en train de regarder, je pensais aller sur PHPIPAM. Je
> > lirai avec attention les contribs à ce sujet.
> Utilisateur globalement satisfait de phpIPAM, quelques minutes sur
> Netbox ont suffit à me convaincre de migrer. Le périmètre est bien plus
> large, l'interface bien plus agréable à l’œil, etc.
> 
> phpIPAM, c'est sympa, c'est free, c'est open, c'est classique et ça rend
> des services. Mais c'est justement resté classique et sauf
> renouvellements majeurs de l'outil, le moment est venu de changer, une
> nouvelle génération est la ;)
> 
> 
> /Sylvain.


Cordialement-- Thierry

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

Re: [FRnOG] [MISC] Point d'accès Wifi ouvert au public et législation

[Thierry Chich]

Bonjour,



Le lundi 29 janvier 2018, 16:09:24 CET Raphael Jacquot a écrit :
> On 01/29/2018 04:02 PM, Florent Bautista wrote:
> 
> Bonjour,
> 
> > Après on revient toujours au "problème de l'adresse mac" : le jour où
> > les flics viennent taper à la porte pour une connexion sur un site
> > louche, le simple fait de leur dire "c'est pas moi c'est mon client
> > 00-1E-33-1D-6A-79" suffit-il vraiment ?! Ca me parait simple comme
> > histoire. D'une part ça ne désigne personne, ça ne désigne qu'un
> > périphérique (et encore... ok !) et non son utilisateur, et ensuite ce
> > périphérique peut avoir été vendu/perdu/volé par n'importe qui...
> > 
> > Enregistrer ça ou rien, pour moi, revient à la même chose...
> 
> ca tombe bien...
> 
> > https://www.cnil.fr/fr/conservation-des-donnees-de-trafic-hot-spots-wi-fi-> 
> > > cybercafes-employeurs-quelles-obligations
> la règlementation francaise actuelle est illégale, et donc nulle et non
> avenue
> 

Alors personnellement, quand il y a des contradictions entre deux systèmes 
juridiques, ma 
position, c'est plutôt d'être du côté de celui qui risque me taper dessus en 
premier. Ceci en 
vertu de la jurisprudence  qui montre qu'avoir raison 15 ans plus tard n'est 
qu'une maigre 
consolation aux emmerdements qui ont précédés.

Dans les cas les plus extrêmes - on voit parfois des choses sinistres, ne pas 
être capable de 
remonter ce qui est demandé dans la loi française, même si elle est contraire à 
un obscur 
arrêt européen peut se révéler tout à fait inconfortable. Je ne conseille pas.



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

RE: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

> De : Michel Py 
> Envoyé : lundi 16 juillet 2018 19:10
> À : Thierry Chich ; 'Richard Klein'
> 
> Cc : 'FRench Network Operators Group' 
> Objet : RE: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL
> 
> >>> Thierry Chich a écrit :
> >>> Je n’ai pas accès à tout les compteurs, mais le seul qui est
> >> vraiment élevé, c’est le FEC. Le CRC reste assez contenu.
> >> Michel Py a écrit :
> >> Tu regardes les compteurs ou ? chez toi, ou sur le DSLAM de Bouygues ?
> > Je suis pas aussi skillé que les hackers des séries US qui corrèlent
> > en 30 secondes les photos de passeports chopées sur les sites
> > gouvernementaux avec l'ensemble des vidéos de surveillance de la ville
> pour trouver où est le méchant. Donc c'est chez moi sur ma box. Hélas.
> 
> Un truc que j'ai remarqué en regardant des deux cotés à la fois (dans le
> passé) c'est que, spécialement si le matos est de 2 marques différentes et de
> 2 origines différentes, les compteurs peuvent être vachement différents. Il y
> a de fortes chances que le DLM de Bouygues regarde les compteurs de leur
> DSLAM, pas de ta box; tout çà pour dire que regarder les compteurs de ton
> coté c'est intéressant mais pas forcément utile. :-(
> 
> >> T'es à quelle distance ?
> > 900 mètres.
> 
> As-tu changé le modem ? As-tu demandé à Bouygues de te mettre sur un
> autre modem sur leur DSLAM ?

Je vais tenter le coup. Good idea.

> As-tu nettoyé le câblage interne (pas de boucles avec 3 téléphones et
> autres) ?

Non, c'est assez clean, je pense. A part le câble externe qui date des années 
60, le reste est récent, et j'ai fait virer toutes les prises au moment de la 
rénovation. 

> Michel.
> 



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

RE: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

> > Thierry Chich a écrit :
> > Je n’ai pas accès à tout les compteurs, mais le seul qui est vraiment 
> > élevé, c’est
> le FEC. Le CRC reste assez contenu.
> 
> Tu regardes les compteurs ou ? chez toi, ou sur le DSLAM de Bouygues ?

Je suis pas aussi skillé que les hackers des séries US qui corrèlent en 30 
secondes les photos de passeports chopées sur les sites gouvernementaux avec 
l'ensemble des vidéos de surveillance de la ville pour trouver où est le 
méchant. Donc c'est chez moi sur ma box. Hélas.

> T'es à quelle distance ?

900 mètres.

> 
> Michel.



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

Re: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

Bonjour

Je n’ai pas accès à tout les compteurs, mais le seul qui est vraiment élevé, 
c’est le FEC. Le CRC reste assez contenu. Le nombre de desynchronisation reste 
de l’ordre de 2/j au maximum. De mon point de vue d’utilisateur, le DLM tel 
qu’il est mis en place chez Bouygues est trop brutal dans sa décroissance, et 
trop mollasson pour sa croissance (et c’est un euphémisme, car je ne l’ai pas 
vu remonter pour l’instant).
Pour ce qui est de la latence, j’ai bien essayer de superviser depuis le 
boulot, mais j’ai l’impression que ça natte dans tous les sens. Je ne crois pas 
que ce soit bien représentatif de la réalité.

En tout cas, je ne regrette pas d’en avoir parlé ici, car j’ai appris des 
choses tout à fait intéressantes sur le sujet.

Thierry
Le 12 juil. 2018 à 20:52 +0200, Richard Klein , a écrit :
> Bonsoir à tous
>
> Après il faudrait garder à l esprit que nous n'avons pas Tous le nez sur le
> débit pour savoir qui a la plus grosse ... bande passante .
> Le DLM est la pour garantir "une qualité de service" .
> Si ta ligne arrive à se synchroniser à un super débit mais que tes
> compteurs d erreurs CRC,ES et SES s'affollent tu vas le payer en bande
> passante et délais d affichage sur une page web. Sur de la VOIP c est
> encore plus perceptible.
> De mémoire sur de l ADSL 1 le débit est imposé sur le profil dslam et le
> modem ADSL va prendre sa synchro/debit sur le dslam.
> Sur de l ADSL 2 (12) et 2+(22M) le modem et dslam vont négocier et adapter
> le débit en fonction de plusieurs paramètres.
>
> Sur l interface OVH sur une ligne longue il est parfois souhaitable via l
> interface client de jouer avec les profils/normes et de brider en adsl 1 a
> 8M plutot que de laisser la ligne monter a 12-13M en adsl 2 /2+ et d avoir
> des CRC et pertes de synchro toutes la journée
> Pour les utilisateurs qui ne lisent pas FRNOG (ils ont tort) le DLM est une
> solution efficace qui permet d avoir un compromis .
>
> Richard
>
> Le jeu. 12 juil. 2018 à 17:36, Thierry Chich 
> a écrit :
>
> > Bonjour
> >
> >
> >
> > J’aimerais connaître le nom d’un algorithme d’optimisation qui est
> > couramment appliqué sur les lignes ADSL par les opérateurs. Celui auquel je
> > pense semble diminuer le débit à chaque désynchronisation jusqu’à ce que :
> >
> > 1) Le client râle
> >
> > 2) Une stabilité apparaisse sur le chemin
> >
> > 3) Un seuil minimum soit atteint
> >
> > Je sais de source sûre que ce style de chose fonctionne chez Orange et chez
> > Bouygues.
> >
> > Pour ne rien cacher, j’aimerais savoir le nom de cet algorithme pour
> > arriver à trouver quelqu’un chez Bouygues qui soit en mesure de me le
> > supprimer, parce que bon, j’en suis à une dizaine d’appel à la hotline, 2
> > remontées à leur cellule d’expertise, et je ne peux quand même pas les
> > appeler toutes les semaines pour leur demander de me réinitialiser
> > l’optimisation et repasser des 12 Mb seuil au 26 Mb normaux.
> >
> >
> >
> > Surtout si c’est pour qu’on m’explique que si ça ne marche pas, c’est parce
> > que j’ai beaucoup trop d’appareils sur mon wifi.
> >
> >
> >
> > Thierry
> >
> >
> >
> >
> > ---
> > 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/

[FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

Bonjour

 

J’aimerais connaître le nom d’un algorithme d’optimisation qui est
couramment appliqué sur les lignes ADSL par les opérateurs. Celui auquel je
pense semble diminuer le débit à chaque désynchronisation jusqu’à ce que :

1)  Le client râle

2)  Une stabilité apparaisse sur le chemin

3)  Un seuil minimum soit atteint

Je sais de source sûre que ce style de chose fonctionne chez Orange et chez
Bouygues. 

Pour ne rien cacher, j’aimerais  savoir le nom de cet algorithme pour
arriver à trouver quelqu’un chez Bouygues qui soit en mesure de me le
supprimer, parce que bon, j’en suis à une dizaine d’appel à la hotline, 2
remontées à leur cellule d’expertise, et je ne peux quand même pas les
appeler toutes les semaines pour leur demander de me réinitialiser
l’optimisation et repasser des 12 Mb seuil  au 26 Mb normaux. 

 

Surtout si c’est pour qu’on m’explique que si ça ne marche pas, c’est parce
que j’ai beaucoup trop d’appareils sur mon wifi.

 

Thierry 

 


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

RE: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Richard Klein
> Envoyé : jeudi 12 juillet 2018 17:51
> À : Thierry Chich 
> Cc : FRench Network Operators Group 
> Objet : Re: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL
> 
> DLM = Digital Line Management
> 
> Chez Orange il y a un formulaire:
> https://espaceclientv3.orange.fr/formulaire-dlm
> 
> Chez Free la ligne est toujours au Max
> Chez les autres il faudra passer par le service client
> 

Merci ! Un formulaire, avec pas des humains qu'il faut convaincre d'escalader 
le cas ? J'en rêverai ! 

> https://fr.wikipedia.org/wiki/VDSL2
> 
> Richard
> 
> Le 12 juillet 2018 à 17:36, Thierry Chich  a 
> écrit
> :
> 
> > Bonjour
> >
> >
> >
> > J’aimerais connaître le nom d’un algorithme d’optimisation qui est
> > couramment appliqué sur les lignes ADSL par les opérateurs. Celui
> > auquel je pense semble diminuer le débit à chaque désynchronisation
> jusqu’à ce que :
> >
> > 1)  Le client râle
> >
> > 2)  Une stabilité apparaisse sur le chemin
> >
> > 3)  Un seuil minimum soit atteint
> >
> > Je sais de source sûre que ce style de chose fonctionne chez Orange et
> > chez Bouygues.
> >
> > Pour ne rien cacher, j’aimerais  savoir le nom de cet algorithme pour
> > arriver à trouver quelqu’un chez Bouygues qui soit en mesure de me le
> > supprimer, parce que bon, j’en suis à une dizaine d’appel à la
> > hotline, 2 remontées à leur cellule d’expertise, et je ne peux quand
> > même pas les appeler toutes les semaines pour leur demander de me
> > réinitialiser l’optimisation et repasser des 12 Mb seuil  au 26 Mb normaux.
> >
> >
> >
> > Surtout si c’est pour qu’on m’explique que si ça ne marche pas, c’est
> > parce que j’ai beaucoup trop d’appareils sur mon wifi.
> >
> >
> >
> > Thierry
> >
> >
> >
> >
> > ---
> > 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] Nom d'algorithme d'optimisation en ADSL

[Thierry Chich]

> -Message d'origine-
> De : David Ponzone 
> Envoyé : jeudi 12 juillet 2018 17:40
> À : Hugues Voiturier 
> Cc : Thierry Chich ; frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] Nom d'algorithme d'optimisation en ADSL
> 
> J’allais le dire :)
> Algo, c’est un grand mot….
> 
Merci pour le nom !

On peut le dire effectivement. Si j'avais utilisé le mot qui me venait 
spontanément, je ne suis pas sûr que j'aurais vraiment été courtois. 
Ce qui me surprend dans ce DLM, c'est son coté ultra bourrin: je te décrois ton 
débit jusqu'au minimum et je n'en bouge plus. Si tu continues à avoir des 
désynchros, je te laisse là comme un misérable, avec tes désynchros ET ton 
débit diminué.


> 
> > Le 12 juil. 2018 à 17:38, Hugues Voiturier  a
> écrit :
> >
> > Bonjour,
> >
> > Le DLM, non ?
> >
> >> On 12 Jul 2018, at 17:36, Thierry Chich 
> wrote:
> >>
> >> Bonjour
> >>
> >>
> >>
> >> J’aimerais connaître le nom d’un algorithme d’optimisation qui est
> >> couramment appliqué sur les lignes ADSL par les opérateurs. Celui
> >> auquel je pense semble diminuer le débit à chaque désynchronisation
> jusqu’à ce que :
> >>
> >> 1)  Le client râle
> >>
> >> 2)  Une stabilité apparaisse sur le chemin
> >>
> >> 3)  Un seuil minimum soit atteint
> >>
> >> Je sais de source sûre que ce style de chose fonctionne chez Orange
> >> et chez Bouygues.
> >>
> >> Pour ne rien cacher, j’aimerais  savoir le nom de cet algorithme pour
> >> arriver à trouver quelqu’un chez Bouygues qui soit en mesure de me le
> >> supprimer, parce que bon, j’en suis à une dizaine d’appel à la
> >> hotline, 2 remontées à leur cellule d’expertise, et je ne peux quand
> >> même pas les appeler toutes les semaines pour leur demander de me
> >> réinitialiser l’optimisation et repasser des 12 Mb seuil  au 26 Mb normaux.
> >>
> >>
> >>
> >> Surtout si c’est pour qu’on m’explique que si ça ne marche pas, c’est
> >> parce que j’ai beaucoup trop d’appareils sur mon wifi.
> >>
> >>
> >>
> >> Thierry
> >>
> >>
> >>
> >>
> >> ---
> >> 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] Qualité de service IP

[Thierry Chich]

Bonjour,



Le mercredi 7 mars 2018, 18:47:23 CET Michel Py a écrit :
> > David Ponzone a écrit :
> > Moi je pense que ça se résume en un acronyme qui est très à la mode sur
> > FRnOG: KISS.
> > Quand tu QoS, tu KISS pas.
> > Quand tu QoS, c'est souvent pour faire des économies de bouts de
> > chandelle.
> > Donc risquer de se taper des problèmes pour économiser quelques € / mois ?
> 
> +1
> 
> Le problème de QOS, c'est que çà ne marche jamais longtemps, avec un
> (relativement) nouveau empêcheur de tourner en rond : blufferbloat. Les
> économies je voudrais bien voir aussi, car çà ne compte généralement pas MON
> temps à essayer d'ajuster tous les réglages. La QOS, c'est une fenêtre très
> étroite quand tu as _juste_ un peu moins de BP que nécessaire; si la BP est
> très insuffisante çà ne marche pas.
> 

Ce n'est pas du tout mon ressenti. Il y a des réseaux qui sont toujours 
saturés, et sur 
lesquels on veut que certaines personnes puissent travailler correctement, ne 
serait-ce 
que ceux qui doivent prendre la main sur les équipements en cas de souci. Sans 
QoS, c'est  
impossible. 

Le problème de la QoS, c'est quand les demandes deviennent excessives. Le QoS 
ne peut 
pas faire que tout marche mieux. Ca peut faire que quelque chose d'important 
continue à 
fonctionner au dépend du reste. 

Et sur le fond, si la QoS n'a pas la cote, c'est peut-être tout simplement 
qu'on ne peut 
l'appliquer que quand on a la maîtrise (au moins contractuelle) de tout les 
points de 
saturation. On est rarement dans cette position.


> AMHA QOS c'est bon pour gagner du temps, pas pour sauver de l'argent.
> 
> Michel.
> 



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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Thierry Chich]

Je connaissais pas et j'adore ! La minimisation de la bêtise, de 
l'incompétence, de la négligence voire des simples aléas est la cause 
majeure de la paranoïa galopante qui pollue tout débat construit de nos 
jours.


Le 09/11/2018 à 15:37, Jérôme Nicolle a écrit :

Je dirais même plus :

« Ne jamais attribuer à la malveillance ce que la bêtise suffit à
expliquer »

(Rasoir d'Hanlon : https://fr.wikipedia.org/wiki/Rasoir_d%27Hanlon)

@+



--




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

Re: [FRnOG] [TECH] Brainstorming VSAT - Economies de bande passante

[Thierry Chich]

Bonjour

Nous avions, il fut un temps, des collèges derrière des lignes 
satellitaires, et ça a toujours été assez misérable à cause de la 
latence que ne peut totalement compenser le débit. Cerains appareils qui 
modifient le comportement de TCP font des tas de promesses dont je ne 
sais pas vraiment jusqu'à quel point elles sont honnêtes...


Les solutions de caching de type squid apporte un gain, mais il est 
assez faible, de l'ordre de 10 à 15% de la bande passante. Cela  a de 
plus tendance à diminuer à cause ou grâce à l'utilisation de plus en 
plus massive du SSL.  Mais de toute manière, les gains n'ont jamais été 
miraculeux. Ce qui l'aurait été, à une époque, c'est de faire un réseau 
de proxy dont le maître (à Terre, pour vous) se charge de compresser les 
flux qui ne le sont pas (parce que les serveurs en face n'ont pas 
intérêt à le faire et qu'on ne peut pas les forcer à le faire). Je ne 
sais pas qui implante cette solution et à quel coût, par contre.


Mon expérience tend à me faire dire que les gains les plus importants 
sont obtenus en optimisant ces énormes bouffeurs de bande passante que 
sont les mises-à-jour en tout genre (WSUS, antivirus, applicatifs, etc). 
Cela semble assez conforme à votre expérience, à ce que je lis.


Cordialement

Le 15/01/2019 à 00:09, jgour...@free.fr a écrit :

Bonjour la liste (et meilleurs vœux a tous!)

Pour bien commencer l'année, on fait un brainstorming pour trouver des idées 
afin d’optimiser l'utilisation de la bande passante sur nos sites distants 
(navires connectes par des liaisons satellites (maritimes)) et, pour sortir de 
nos sentiers battus, je me suis dit que je ferai appel à vous. Je suis à la 
recherche de suggestions, d’idées, de produits ou technos à explorer pour 
améliorer les liens vers nos bateaux. Nouvelles technos VSATs, outils de 
compressions, d’optimisation, avec toujours cette contrainte de latence 
importante et de bande passante couteuse.

Pour vous donner une idée, dans notre config de base, nos sites distants 
étaient, à la base, connectés au siège en VPN, avec derrière, comme principale 
consommateur de bande passante, une infrastructure de serveurs Windows et les 
clients associes... Petit a petit, on a ajoute des riverbed, déplace une partie 
de nos équipements réseaux sur le téléport du fournisseur, ajoute des proxys a 
bord.. On a gagné en qualite mais je pense qu’on a toujours une bonne marge de 
progression.  On entend par exemple parfois que Riverbed n’est pas le meilleur 
choix pour des sites avec une telle latence, avez-vous testé d’autres solutions 
? Auriez-vous des suggestions d’outils du type IBM aspera pour le transfert de 
fichier ? Outils de filtrage et caching de type squid ? Aussi, si vous 
connaissez des outils de tests de débits qui prennent en compte ce genre de 
contraintes, n’hésitez pas. Je sais que le sujet est vaste mais si vous avez 
des suggestions à faire, à n’importe quelle couche de l’infrastructure, ça 
m’intéresse.

Merci d’avance.

Jeremy


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

--
Thierry




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

Re: [FRnOG] Re: [MISC] le prix de l'essence / chomage et taux d'emploi

[Thierry Chich]

Le 21/12/2018 à 14:10, David Ponzone a écrit :

Taux d'emploi France : 80.5% USA : 79.4%
Taux chomage  France :  8.2% USA :  3.1%

Laurent,

Tes chiffres voudraient dire qu’il y a:
-soit plus de rentiers qui ne bossent pas et ne sont pas chômeurs aux US qu ‘en 
France (79,4+3,1=82,5%, où sont les 17,5% ?)
-soit les US trichent encore plus que nous sur le chiffre du chômage

Y a surtout pas mal de gens qui sortent carrément du système parce qu'il 
n'y a rien à y gagner à y rester et qui vivent comme ils peuvent. On me 
souffle dans l'oreille que c'est plus mal que bien.


--





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

Re: [FRnOG] [MISC] le prix de l'essence

[Thierry Chich]

Mais non. Non !

Je suis scandalisé !

Mais comme c'est trop facile comme troll !

Le 21/12/2018 à 04:42, Michel Py a écrit :

En lisant la presse qui parle des gilets jaunes, et comme nous les Américains 
on aime bien foutre le boxon dans les autres pays ;-)

J'ai fait le plein de ma camionnette (Nissan Frontier, en Français Nissan 
Navara King Cab) ce matin.
69,2 litres (18,28 Gallons)
Prix "blaireau" à la pompe : 0,68 € / l  ($2.979 / G) c'est cher, mais je suis 
en Californie.
Coupon Safeway (le même supermarché ou je fais mes courses, il ya a une station 
essence aussi) : 1 dollar par gallon.
Prix payé à la pompe : 31,48 €
Cashback American Express 5% (j'en vois la couleur le mois prochain) : 1,57 €
Mon plein m'a donc couté : 29.91 €, soit 0,43 € le litre.

Et c'est une camionnette ! Une voiture de petite taille on fait le plein pour 
15 €.

J'ai l'impression que vous vous faites empapaouter :-)

Michel.


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





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

Re: [FRnOG] [MISC] Smartphone et enfants

[Thierry Chich]

Le 27/11/2018 à 22:46, Michel Py a écrit :

+1

En plus, faudrait pas blâmer tous les maux sur l'Internet. Le cul à l'école, çà 
existait avant. En 6ème on échangeait les pages de Playboy et de Lui plus ou 
moins collées dans le bus. Quand les ordinateurs personnels sont apparus les 
échanges de disquettes avec quelques malheureux GIFs 320x240 çà existait aussi, 
ce n'est pas l'évolution vers le tout numérique qui a crée le contenu. Le porno 
çà existe depuis l'invention de l'appareil photo; c'était peut-être un peu 
moins crade il y a 40 ans, mais faut pas dire que c'est une calamité que 
l'Internet nous a apporté.


Le contenu est quasiment inépuisable, il est accessible en permanence, 
et sans avoir à affronter le regard des autres. C'est ça que l'internet 
amène de nouveau. Ce n'est d'ailleurs pas seulement dans le domaine de 
la pornographie que cette caractéristique pose problème.









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

Re: [FRnOG] [TECH] Iperf

[Thierry Chich]

Le 07/12/2018 à 11:06, David Ponzone a écrit :

Et c’est de l’UDP ?
J’ai tendance à penser que non :)
J’ai oublié de préciser que le choix d’iperf est de pouvoir prouver à un « 
prestataire » en utilisant le même outil que lui que: non, je n’ai pas de 
limite à 1Mbps en UDP sur mes VDSL, et que oui, si on ne précise pas -b avec 
-u, iperf s’autolimite à 1Mbps :)



La confiance règne.

En fait, c'est plutôt l'apprentissage de la commande man qui serait 
utile, non ?


Thierry





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

Re: [FRnOG] Re: [MISC] Smartphone et enfants

[Thierry Chich]

Le 29/11/2018 à 10:07, Stéphane Rivière a écrit :
Ensuite, faut laisser les gens faire. Les gens savent. Ce qui est bon 
pour eux. Tout le reste n'est que censure.


Certains utilisent exactement cet argument pour prôner la suppression de 
toute aide sociale.






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

Re: [FRnOG] Re: [MISC] Smartphone et enfants

[Thierry Chich]

Le 29/11/2018 à 12:56, Arnaud BRAND a écrit :

Le 2018-11-29 10:07, Stéphane Rivière a écrit :

Ensuite, faut laisser les gens faire. Les gens savent. Ce qui est bon
pour eux. Tout le reste n'est que censure.


+/- 1

Je suis assez d'accord, mais je vais nuancer.

Pas les enfants. D'où l'importance de les éduquer pour leur apprendre 
à éviter les contenus toxiques pour eux.
Et les contenus qui au regard de notre morale toute subjective sont 
néfastes directement ou indirectement pour les autres ou la société en 
général.


Mais de là à essayer de se placer en censeur tout puissant, c'est se 
voiler la face et ne pas traiter le problème.

Qu'est ce qui se passe quand ils sont hors du firewall ?


Censeur tout puissant ? Sur internet ? Faut déjà avoir un sacré melon 
pour croire qu'on peut l'être, ou alors on travaille avec des listes 
blanches.


Non, dans les établissements et les écoles, on aimerait simplement qu'au 
milieu d'une visite au musée, on se retrouve pas subitement téléporté 
avec les enfants au milieu d'une boite échangiste (si je peux oser cette 
métaphore).



Thierry





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

Re: [SPAM MEDIUM]Re: [FRnOG] Re: [MISC] Smartphone et enfants

[Thierry Chich]

Le 29/11/2018 à 18:40, frnog.kap...@antichef.net a écrit :

On jeudi 29 novembre 2018 17:28:01 CET Thierry Chich - thierry.chich@ac-
clermont.fr wrote:

Le 29/11/2018 à 17:07, Simon Morvan a écrit :

On 29/11/2018 09:52, Thierry Chich wrote:

Non, dans les établissements et les écoles, on aimerait simplement
qu'au milieu d'une visite au musée, on se retrouve pas subitement
téléporté avec les enfants au milieu d'une boite échangiste (si je
peux oser cette métaphore).

J'aimerais bien qu'on m'explique comment reproduire localement ce bug
afin de le fixer...

Ca n'arrive jamais, ni à moi, ni à mes enfants. Selon mon expérience, il
faut *activement* chercher à tomber sur ce genre de contenu. Ou alors le
site du musée en question est peut être douteux, à la base.

C'est cool. Mais dans la réalité vrai, ça arrive assez souvent.

Ca m'est même arrivé une fois alors que le safesearch était activé sur
Google. J'ai tapé Nymphéa pour montrer les tableaux de Monet à mon
gamin. Je suis tombé sur une charmante dame de ce nom qui publiait des
photos sur doctissimo.

Alors quand le safesearch n'est pas activé, on n'en parle même pas. Et
le safesearch, c'est soit un DNS menteur, soit des configurations de
postes. Et croyez-le ou non, les écoles, les collèges et les lycées, à
gérer informatiquement, c'est pas exactement tout petit.

Quant aux parents, ils sont tellement dépassés qu'il n'y pas une
solution que nous ayons proposé ici (y compris moi) qui soit tenable. A
part la suppression de l'accès, effectivement.

Il s'agit ici d'un problème évident d'interface chaise clavier.


C'est ce que je me suis tout de suite en vous lisant.


En prenant un outil inadapté à l'attente, et en ne s'en servant pas
correctement il n'est pas surprenant de ne pas obtenir l'effet recherché.

Google n'est pas un outil adapté car trop générique, wikipédia semble bien
plus adapté pour s'éviter les écueils rapportés ici.

Taper Nymphéa dans google en espérant n'avoir des résultats en rapport avec
"Les Nymphéas" de Monet, et obtenir des résultats en rapport avec Nymphéa
c'est simplement le moteur de recherche qui fait ce qu'on lui a demandé.
On est donc bien dans le cas de figure d'une recherche active d'un contenu qui
n'est pas approprié.


Tout à fait. Comment ai-je pu ne pas me rendre compte immédiatement ce 
que chercher une image sur google image avait d'absurde !



Ce qui est intéréssant de noter c'est que l'apparition de cette Nymphéa dans
les résultats de google est probablement dûe a la personnalisation des
résultats de google en fonction de votre profil puisque celle-ci n'apparait
pas lorsqu'on fait la recherche de manière anonymisée. Je n'obtiens que des
photos de nénuphars comme on peut le voir sur la capture d'écran ci-dessous.
https://framapic.org/Vm2sDdGvrRlq/lHpLg0WKTSgC.png
J'ai une révélation à vous faire. Ce qui s'affiche sur Google change 
avec le temps. Mais je vous remercie d'avoir pris le soin de nous le 
confirmer en prenant une belle capture d'écran.

La gestion d'un collège du point de vue informatique ce n'est pas si
gigantesque au point qu'on ne puisse pas configurer les postes. Selon moi, le
problème relève plus d'un manque de formation et d'utilisation d'outil adapté
de pour gérer le parc informatique.
Ce n'est pas gigantesque, certes, mais nous avons géré ici les parcs 
pédagogiques de 200 établissements (environ 2 postes), et je vous 
assure que ce n'est pas tout à fait la même chose que de bidouiller un 
rasberry pi à sa maison.






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

Re: [FRnOG] Re: [MISC] Smartphone et enfants

[Thierry Chich]

Le 29/11/2018 à 17:07, Simon Morvan a écrit :

On 29/11/2018 09:52, Thierry Chich wrote:

Non, dans les établissements et les écoles, on aimerait simplement
qu'au milieu d'une visite au musée, on se retrouve pas subitement
téléporté avec les enfants au milieu d'une boite échangiste (si je
peux oser cette métaphore).

J'aimerais bien qu'on m'explique comment reproduire localement ce bug
afin de le fixer...

Ca n'arrive jamais, ni à moi, ni à mes enfants. Selon mon expérience, il
faut *activement* chercher à tomber sur ce genre de contenu. Ou alors le
site du musée en question est peut être douteux, à la base.


C'est cool. Mais dans la réalité vrai, ça arrive assez souvent.

Ca m'est même arrivé une fois alors que le safesearch était activé sur 
Google. J'ai tapé Nymphéa pour montrer les tableaux de Monet à mon 
gamin. Je suis tombé sur une charmante dame de ce nom qui publiait des 
photos sur doctissimo.


Alors quand le safesearch n'est pas activé, on n'en parle même pas. Et 
le safesearch, c'est soit un DNS menteur, soit des configurations de 
postes. Et croyez-le ou non, les écoles, les collèges et les lycées, à 
gérer informatiquement, c'est pas exactement tout petit.


Quant aux parents, ils sont tellement dépassés qu'il n'y pas une 
solution que nous ayons proposé ici (y compris moi) qui soit tenable. A 
part la suppression de l'accès, effectivement.







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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Thierry Chich]

Les DNS menteurs, c'est le mal, le non chiffrement, c'est le mal. Ok !

Mais les gamins de 12 ans qui s'abîment sur des sites pornos, c'est pas 
le bien non plus. J'aurais aimé un peu plus d'ardeur de la part des 
différents grands à la manœuvre du chiffrement de partout (Google, 
Mozilla, etc.) pour mettre en place des systèmes simples utilisables 
pour la protection des mineurs, dans les écoles ou les familles.


Le 23/11/2018 à 21:19, Stephane Bortzmeyer a écrit :

La vie privée sur l'Internet fait aujourd'hui l'objet d'innombrables
attaques et l'une des techniques de défense les plus efficaces contre
ces attaques est le chiffrement des données. Il protège également
contre une autre menace, la modification des données en transit, comme
le font certaines FAI. Il y a de nombreuses campagnes de
sensibilisation pour promouvoir le chiffrement , avec des bons
résultats. Évidemment, ce chiffrement gène ceux qui voudraient
espionner et modifier le trafic, et il fallait donc s'attendre à voir
une réaction. Ce RFC est l'expression de cette réaction, du côté de
certains opérateurs réseaux, qui regrettent que le chiffrement empêche
leurs mauvaises pratiques.

https://www.bortzmeyer.org/8404.html








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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Thierry Chich]

Le 26/11/2018 à 15:53, Bruno Pagani a écrit :

Et c’est tant mieux, car c’est effectivement un gros manque pour la
protection de la vie privée.

La réponse pour la protection des enfants, c’est que ça se passe sur le
terminal de l’utilisateur, pas ailleurs sur le chemin. Si on n’est pas
capable de contrôler le terminal des enfants et l’usage qu’ils en font,
le problème ne se situe pas au niveau des protocoles utilisés sur Internet.



Ca, c'est la théorie. La pratique, c'est qu'il n'y a rien. On a family 
link sur android, un truc chez apple, un peu du n'importe quoi sur les 
PC, mais rien qui soit simple, centralisable, gérable depuis une école 
ou un collège.


Thierry




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

[FRnOG] Re: [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Thierry Chich]

Le 26/11/2018 à 17:19, Stephane Bortzmeyer a écrit :

C'est à Google et à Mozilla d'éduquer les enfants ? Je croyais que
c'était le travail des parents et de l'école.
C'est à Google et à Mozilla de décider s'il faut du HTTPS partout ? Eh 
bien, il semble que oui. Ce que j'aurais aimé, c'est que les décisions 
prises par Google de forcer le HTTPS (qui, au passage, n'avaient pour 
but que de faire contre-feu au scandale Snowden) aient inclue un volant 
"protection des mineurs".


Quand aux parents et à l'école, ils font comment concrètement  ? Parce 
que la seule solution accessible, c'est de couper Internet.


Thierry





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

Re: [FRnOG] Re: [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Thierry Chich]

Le 27/11/2018 à 13:49, Raphael Jacquot a écrit :

De toutes facons, ils ont tous un mobile, quoi que Blanquer fasse, dise
ou décrète...
C'est un combat d'arrière garde, le bateau est déja sorti du port...


Tout à fait. C'est un combat d'arrière garde. Je n'ai d'ailleurs jamais 
pensé que l'absence de chiffrement était la panacée sur ces questions.  
Ce qui n'est pas un combat d'arrière garde en revanche, c'est que des 
solutions gratuites gérables soient mises à disposition pour les parents 
et les écoles.


Thierry
--




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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Thierry Chich]

D’autre part, comme dit Stéphane, c’est aux parents de s’occuper de
leurs enfants. On va pas interdire de vendre des briquets et des
couteaux parce que même si c’est très utile, les enfants peuvent faire
des bêtises avec donc voilà. La solution, c’est qu’on laisse pas ces
outils à portée de main des enfants, sauf éventuellement sous
surveillance. Bah Internet c’est pareil.
Non, c'est pas pareil du tout. Sur Internet, il y a l'ENT des élèves, il 
y a youtube, de la musique,  des jeux vidéos, ides ressources 
pédagogiques, et puis il y a aussi de la pornographie, crade et même au 
delà du crade.

C'est trop facile de dégager sur les parents et les éducateurs comme ça.





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

[FRnOG] Re: [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[thierry . chich]

Le 28 nov. 2018 à 13:38 +0100, Stephane Bortzmeyer , a écrit 
:
> On Tue, Nov 27, 2018 at 01:38:22PM +0100,
> Thierry Chich  wrote
> a message of 76 lines which said:
>
> > C'est à Google et à Mozilla de décider s'il faut du HTTPS partout ?
> > Eh bien, il semble que oui. Ce que j'aurais aimé, c'est que les
> > décisions prises par Google de forcer le HTTPS
>
> La décision de mettre du HTTPS partout faisait l'objet d'un large
> consensus, logique après les révélations Snowden. Si tous les gens qui
> ont dit que HTTPS c'est bien étaient payés par Google, je vais
> demander mon chèque

Il y a eu un vote ? Google a simplement dit « je favorise les https en haut du 
classement ». Comme ça, on a oublié qu’en backend, la NSA avait accès 
directement aux bases des uns et des autres et se tamponnait du HTTPS.

>
> > Quand aux parents et à l'école, ils font comment concrètement  ?
>
> Tiens oui, j'ai élevé deux millenials, il faudrait que je leur demande
> comment j'ai fait.

Des fois, quand on leur pose des questions sur ce sujet, on a des surprises.

Quoiqu’il en soit, je ne suis pas contre le HTTPS, ce serait idiot. Je suis 
juste surpris qu’on ne voit pas que certains problèmes graves ne sont pas 
adressés.
Ce qui ne manque d’ailleurs pas d’être utilisé par ceux qui veulent du contrôle 
pour des raisons politiques.

Thierry

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

Re: [FRnOG] [TECH] autoneg et non autoneg sur des ports 10G et 40G

[thierry . chich]

En ces temps de froidure (relative, il faut bien le dire, y a plus de saison, 
ma bonne dame), on peut se chauffer avec.
Le 19 déc. 2018 à 16:27 +0100, Alexis , a écrit :
> Juste pour culture, y-a-t'il un quelconque intérêt à faire du 40G en
> cuivre au lieu d'utiliser de la fibre ?
>
> Alexis Prodhomme
> Support Technique Gen-IP
> email : supp...@gen-ip.fr
> tel : 02.90.75.30.50
>
> Le 19/12/2018 à 16:13, Manuel Guesdon a écrit :
> > On Wed, 19 Dec 2018 15:57:55 +0100 (CET)
> > Michel Hostettler  wrote:
> > > | > le 40G est forcément en optique...
> > > |
> > > | J'en avale mon chapeau... En bûche de Noël, cela doit être délicieux.
> > > |
> > > | 40GBase-T est en paire torsadée, sur une distance d'au moins 30 m.
> > Hum, faut pas mettre de rhum sur le chapeau avant de le manger: "sur une
> > distance de moins de 30m" ca me semble mieux...
> >
> > Manuel
> >
> > --
> > __
> > Manuel Guesdon - OXYMIUM
> >
> >
> > ---
> > 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] Re: iptables me rendra fou

[Thierry Chich]

Il est fait avec quoi, ton tunnel ? parce qu'avec strongswan/freeswan, 
il avait tout un système "alternatif" (les SPD) qui outrepassait 
iptables, et qu'on voit avec la commande setkey -PD. Aucune idée de si 
ça fonctionne encore comme ça.


Le 25/01/2019 à 17:10, Kevin Thiou a écrit :

Au niveau routage on est bien aussi :

172.22.0.0/24 via 172.31.254.1 dev tun4
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.254

Le ven. 25 janv. 2019 à 17:07, Kevin Thiou  a écrit :


Bonjour, bonsoir,

depuis quelques temps je me bats avec iptables pour un accès tout con mais
que je ne parviens pas à faire fonctionner.

ce que je souhaite :

-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j ACCEPT et le retour

je vois les paquets arriver sur l'interface de la machine iptables avec un
tcpdump :

tcpdump -i tun4 -n host 172.22.0.101 and host 192.168.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun4, link-type RAW (Raw IP), capture size 65535 bytes
16:50:39.455349 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489719 ecr
0,nop,wscale 7], length 0
16:50:40.456679 IP 172.22.0.101.33832 > 192.168.0.10.22: Flags [S], seq
3417624197, win 29200, options [mss 1270,sackOK,TS val 2543489970 ecr
0,nop,wscale 7], length 0

tous les prerouting (raw, mangle, nat) sont à accept.

  iptables -vL -t mangle -n
Chain PREROUTING (policy ACCEPT 25G packets, 23T bytes)
  pkts bytes target prot opt in out source
  destination
Chain INPUT (policy ACCEPT 8470M packets, 9683G bytes)
  pkts bytes target prot opt in out source
  destination
Chain FORWARD (policy ACCEPT 17G packets, 13T bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 4864M packets, 1008G bytes)
  pkts bytes target prot opt in out source
  destination
Chain POSTROUTING (policy ACCEPT 22G packets, 14T bytes)
  pkts bytes target prot opt in out source
  destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3640K packets, 2649M bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 86560 packets, 31M bytes)
  pkts bytes target prot opt in out source
  destination

iptables -vL -t raw -n
Chain PREROUTING (policy ACCEPT 3650K packets, 2655M bytes)
  pkts bytes target prot opt in out source
  destination
Chain OUTPUT (policy ACCEPT 86795 packets, 31M bytes)
  pkts bytes target prot opt in out source
  destination

j'ai donc voulu tracer le paquet dans iptables vu que je n'arrive pas à
l'autoriser, j'ai donc mis les lignes suivantes :

iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -s 172.22.0.0/24 -d 192.168.0.0/24 -j LOG --log-prefix HELLO
-A FORWARD -s 192.168.0.0/24 -d 172.22.0.0/24 -j LOG --log-prefix HELLO

et j'ai rien dans les logs.

Où peuvent donc passer ces paquets ?

Merci de votre aide.


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

--





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

[FRnOG] Re: [TECH] DNS Additional

[Thierry Chich]

Mon résolveur aurait pris sur lui d'interroger les tld pour connaître 
les NS ? Ca pourrait vouloir dire que dans certains cas, le forward-only 
serait suboptimal ?


Le 22/02/2019 à 14:02, Stephane Bortzmeyer a écrit :

On Fri, Feb 22, 2019 at 01:56:08PM +0100,
  Thierry Chich  wrote
  a message of 87 lines which said:


;; ADDITIONAL SECTION:
ns1.google.com. 283703  IN  A 216.239.32.10
ns1.google.com. 297774  IN   2001:4860:4802:32::a
ns2.google.com. 283137  IN  A 216.239.34.10
ns2.google.com. 285158  IN   2001:4860:4802:34::a
ns3.google.com. 283369  IN  A 216.239.36.10
ns3.google.com. 284065  IN   2001:4860:4802:36::a
ns4.google.com. 283684  IN  A 216.239.38.10
ns4.google.com. 285368  IN   2001:4860:4802:38::a
Peut-être que Google a une option pour être moins bavard, comme le
minimal-responses de bind, mais pourquoi distinguerait-il mon dig de
la requête qui vient de mon résolveur ?

Il est probable que Google Public DNS ne fait *pas* cette distinction
(tcpdump pour vérifier). Mais votre résolveur X.X.X.X, lui, a décidé
d'envoyer en section additionnelle tout ce qu'il connaissait, aussi
bien la réponse reçue de Google que ce qu'il avait dans sa mémoire
(cache).

--




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

[FRnOG] [TECH] DNS Additional

[Thierry Chich]

Bonjour

J'ai cherché un peu de ci delà, mais j'avoue que j'ai quelques soucis à 
comprendre quelques petits détails sur les réponses à certaines requêtes 
DNS. Ca concerne particulièrement les champs additionals.


Par exemple, j'ai un resolveur interne (X.X.X.X) qui forwarde tout chez 
google. Quand je lui demande le SOA de google, il me répond:


tchich@ubuntu:~$ dig -t SOA @X.X.X.X google.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> -t SOA @X.X.X.X google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62685
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.    IN  SOA

;; ANSWER SECTION:
google.com. 59  IN  SOA ns1.google.com. 
dns-admin.google.com. 235147609 900 900 1800 60


;; AUTHORITY SECTION:
google.com. 9778    IN  NS ns3.google.com.
google.com. 9778    IN  NS ns4.google.com.
google.com. 9778    IN  NS ns1.google.com.
google.com. 9778    IN  NS ns2.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 283703  IN  A 216.239.32.10
ns1.google.com. 297774  IN   2001:4860:4802:32::a
ns2.google.com. 283137  IN  A 216.239.34.10
ns2.google.com. 285158  IN   2001:4860:4802:34::a
ns3.google.com. 283369  IN  A 216.239.36.10
ns3.google.com. 284065  IN   2001:4860:4802:36::a
ns4.google.com. 283684  IN  A 216.239.38.10
ns4.google.com. 285368  IN   2001:4860:4802:38::a

;; Query time: 27 msec
;; SERVER: X.X.X.X#53(X.X.X.X)
;; WHEN: Fri Feb 22 13:28:42 CET 2019
;; MSG SIZE  rcvd: 333

C'est gentil de sa part de me dire tout ça. Ce que je trouve curieux, 
c'est que le solveur de google.com est bien moins bavard:


tchich@ubuntu:~$ dig -t SOA @8.8.8.8 google.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> -t SOA @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.    IN  SOA

;; ANSWER SECTION:
google.com. 59  IN  SOA ns1.google.com. 
dns-admin.google.com. 235147609 900 900 1800 60


;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 22 13:27:34 CET 2019
;; MSG SIZE  rcvd: 89

Peut-être que Google a une option pour être moins bavard, comme le 
minimal-responses de bind, mais pourquoi distinguerait-il mon dig de la 
requête qui vient de mon résolveur ?


Thierry





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

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

[Thierry Chich]

Le 15/03/2019 à 09:58, Alexandre Bruyelles a écrit :

Quelle importance ?
La sécurisation du niveau applicatif en se basant sur la couche 4 (ou 3,
pour ce que ça vaut) est risible et déficiente


Tandis qu'au niveau applicatif, c'est tellement bien. Je me souviens 
encore avec émotion d'un appareil de visioconf dont je n'ai jamais pu 
changer le mot de passe d'admin. Alors s'il avait été directement 
accessible sur internet sans sécurisation sur la couche 4 ou 3, 
j'imagine bien ce qui se serait passé.



--





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

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

[thierry . chich]

Le 15 mars 2019 à 14:56 +0100, Toussaint OTTAVI , a écrit :
>
> Le 15/03/2019 à 14:35, David Ponzone a écrit :
> > Peut-être meilleur, mais parfait, j’en doute.
>
> Pour moi qui ne suis pas téléphoniste, mais juste firewalliste, un port
> unique et fixe, c'est déjà plus que parfait :-)
>
> Je ne pense pas que les gens qui ont conçu SIP et RTSP aient eu en tête
> les problématiques de NAT et de sécurisation que çà allait générer
> (certes, ailleurs que chez eux). On retombe sur la discussion d'un
> protocole conçu par une catégorie d'utilisateurs pour répondre à ses
> besoins propres, sans forcément tenir compte des difficultés que cela
> allait engendrer pour d'autres catégories d'utilisateurs.
>
> Et, en l'occurrence, c'est moi qui suis emm*rdé pour faire fonctionner
> des solutions de téléphonie que je ne vends pas et que je ne connais
> pas. Et alors que le discours du téléphoniste se limite généralement à
> "oulala, vous avez un firewall, çà ne va jamais marcher", c'est moi qui
> suis obligé de jouer du requin à fils pour comprendre ce que son bouzin
> essaye de faire, et ensuite, de trouver une astuce pour le feinter...
>
> Du coup, je me demande s'il existe un protocole qui m'exaspèrerait plus
> que SIP et IPv6 réunis :-D
>
>
H323 ?
> ---
> 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

[thierry . chich]

Le 15 mars 2019 à 16:42 +0100, Philippe ASTIER , 
a écrit :
> >
> > Tandis qu'au niveau applicatif, c'est tellement bien. Je me souviens encore 
> > avec émotion d'un appareil de visioconf dont je n'ai jamais pu changer le 
> > mot de passe d'admin. Alors s'il avait été directement accessible sur 
> > internet sans sécurisation sur la couche 4 ou 3, j'imagine bien ce qui se 
> > serait passé.
>
> Il faut faire le tri dans les vendeurs, et fusiller ceux qui sont stupides.

C’est un exemple. Il y a aussi des applications très anciennes qu’on n’a pas 
les moyens de refaire à neuf, des applications plus modernes mais qui ont 
souffert d’une absence d’intégration de la question sécuritaire. Il y a aussi 
les simples erreurs de conception.

Et au final, pour nombre d’entre elles, le firewall suffit à limiter le risque.

>  Je me répète… mais j’estime que 75% des devices de mes clients sont en 
> permanence en dehors de la forteresse supposée de leur entreprise…
>
> Au passage, les grosses failles qui ont paralysées des usines en France ou la 
> sécu en Angleterre, genre Wannacry… c’était installé sur des appareils 
> internes.
>
> La sécurité périmétrique est morte et enterrée depuis 10 ans. Utile, mais 
> très insuffisante.
> Les attaques frontales directes, c’est bon pour les étudiants en première 
> année de Hacking High School, et ça sert à remplir les logs des firewalls et 
> rassurer les CFO sur leur niveau de dépense en sécurité…

Ça fait aussi 10 ans que j’entends dire que la sécurité perimetrique c’est 
dépassé et ça fait 10 ans que quand j’investigue un peu sur les moyens de gérer 
une sécurité au plus proche, je tombe sur des solutions au mieux mal 
dimensionnées, au pire bouffones.

Moi aussi j’ai 75% dehors, mais il se trouve que les 75% dehors sont d’une part 
moins vulnérables et d’autre part moins critiques.


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

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

[Thierry Chich]

Le 07/03/2019 à 12:47, Hugues Voiturier a écrit :

Tout ça pour dire que de craindre un scan en v6 c’est comme de craindre une 
attaque de licornes… Ça peut arriver mais c’est relativement peu probable.



Si on suppose que les IP allouées sont allouées selon une loi de 
probabilité uniforme, c'est sûr. Dans le monde réel, je pense que ça 
risque plutôt d'être en mode très clusterisé. Du genre 
2019:blabla::monancienneIPv4.


En gros, il suffira de connaître une IP pour scanner tranquille.


Hugues
AS57199 - AS50628


On 7 Mar 2019, at 12:45, Toussaint OTTAVI  wrote:


Le 07/03/2019 à 12:16, Hugues Voiturier a écrit :

Ça marche, je te laisse commencer à scanner un /64 en IPv6, je te regarde faire 
;)

Considérant le fait que je ne prévois pas d'utiliser IPv6, tu risques 
effectivement d'attendre longtemps :-D

OK, je sors...


---
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] Adoption de nouveaux protocoles

[Thierry Chich]

Bonjour

Je n'ai pas d'expérience IPv6, mais rien que la gestion des ipam 
doublés, du dns, des firewalls, je ne vois pas comment ça peut être 
neutre en terme de coût en production.


Je pense que tout le monde ici est convaincu de certains intérêts de 
l'IPv6. La question est plutôt de savoir si vraiment on ne va pas aller 
vers une situation à deux étages de protocoles, en interne IPv4 et en 
externe IPv6, donc transparent pour une bonne partie des ingés, un peu 
comme  MPLS qui ne concerne pas grand monde en dehors du monde des 
opérateurs.


Cdt

Le 07/03/2019 à 10:47, Bruno Stevant a écrit :

Bonjour Michel,

Le mer. 6 mars 2019 à 21:16, Michel Py 
a écrit :


Tu ne vas pas me convaincre. Je suis un client final entreprise. Pourquoi
voudrais-tu que je m'emmerdes à faire du dual-stack ? c'est 2 fois le
travail et 3 fois les emmerdes.


Je serai intéressé par tes sources ? Je n'ai pas vu de retour d'expérience
négatif sur le déploiement d'IPv6 en entreprise.
Au contraire, j'ai un exemple dans le secteur bancaire où c'est plutôt
positif.
Ce qui est coûteux, c'est la mise à jour des équipements réseau et la
montée en compétence. Pas l'exploitation.

---
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

[Thierry Chich]

Le "mon 10.10.1.1 doit parler avec ton 10.10.1.1" peut certainement etre resolu 
avec du NAT, mais c'est soit sale, soit trop complique pour les apprentis 
sorciers^Wadmins.


On va pas se mentir: c'est le gros intérêt d'IPv6.  Et c'est cool, mais 
le souci, c'est  que les dernières choses de ce type que j'ai eu à 
faire, le fait d'avoir tout passé en IPv6 ne m'aurait rien apporté du 
tout. Pourquoi ? Parce que ceux d'en face ne l'ont pas.


Donc bon. Comme le disait Michel Py, c'est un problème de masse 
critique. Et c'est aussi un problème de manque de "super-feature" qui 
aurait motivé qu'on passe en masse.


Le manque d'enthousiasme des techs n'a rien à voir avec le retard du 
déploiement.


--





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

Re: [FRnOG] [MISC] Panne

[Thierry Chich]

Franchement, vous vous scandalisez de pas grand chose.

Je me rappelle avec émotion d'une série du début des années 90 dans 
laquelle le héros s'évadait d'un prison dans laquelle il était 
géolocalisé en mettant son collier à un chat qui passait par là. Les 
stupides gardiens arrivaient en courant car ils le croyaient en train de 
s'enfuir (les niais) , et deux balayettes plus loin, il prenait les clés 
sur les gardiens inanimés. N'écoutant ensuite que son courage et les 
bruits environnants, il comprenait que le vilain ultime était en train 
de partir en hélicoptère, reprenait donc le collier de géolocalisation 
au chat qui passait de nouveau par là, et courait l'attacher à l'hélico.


Puis, il arrachait le moniteur de géolocalisation du bureau des gardiens 
et l'emmenait dans sa voiture pour suivre l'hélicoptère.


Là, y avait du niveau.

Le 11/03/2019 à 17:31, Hervé BRY a écrit :

Cette scène est aussi la seule chose que j'ai gardé de la série ;)

L'extrait est en ligne pour ceux qui ne connaissent pas:
https://youtu.be/NIf1Y4qCUU4?t=51

Hervé BRY
Administrateur Système
Geneanet (http://www.geneanet.org)


Le lun. 11 mars 2019 à 17:09, Joel DEREFINKO  a
écrit :


Marrant, j'ai gardé le même souvenir de ce fameux premier épisode... et
j'ai jeté le reste de la saison :D

Joël

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de
Arnaud Launay
Envoyé : lundi 11 mars 2019 16:47
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Panne

Le Mon, Mar 11, 2019 at 07:48:41AM +0100, David Ponzone a écrit:

Hey non mais y a eu bien pire quand même dans d’autres séries/films.
En même temps, quand on regarde des séries pourries :)

Ca me rappelle le premier épisode S01E01 de Scorpion, où ils
réussissent à connecter un câble rj45 dans un avion en train de
décoller à partir d'une voiture de sport roulant sous l'avion...  :)

 Arnaud.


---
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] Adoption de nouveaux protocoles

[Thierry Chich]

Le 15/03/2019 à 09:12, Stéphane Rivière a écrit :
Sérieux, si on ne se faisait pas chier avec du v4, on aurais pas 
passé 1h (+ 3h de tests a la con
pour vérifier que les paramètres de NAT, changés un à un) pour qu'un 
truc qui mange 2 PC avec 16 cores
soit finement tunné  à cause de protocoles qui ont du mal a supporter 
du NAT?


On peut pas dire que ça soit faux... Qui ne hait pas le NAT dès qu'il 
s'agit de voix ou de vidéo  ?




Je ne suis pas fan du NAT, mais il restera de toute façon, ne serait-ce 
que pour les reverse-proxy.


Ce qui est vraiment haïssable, ce sont ces protocoles merdiques avec des 
ports dynamiques de partout et  dans tous les sens.


Et ça, IPv6 ou non, ça restera hyper-compliqué à sécuriser.

Thierry
--





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

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

[Thierry Chich]

Le 15/03/2019 à 09:38, David Ponzone a écrit :

Je ne suis pas fan du NAT, mais il restera de toute façon, ne serait-ce que 
pour les reverse-proxy.

Ce qui est vraiment haïssable, ce sont ces protocoles merdiques avec des ports 
dynamiques de partout et  dans tous les sens.


Tu verrais une autre solution ?

Une autre solution que des protocoles où le client négocie avec le 
serveur le numéro de port sur lequel le serveur va lui envoyer des 
données ? A la mode tftp ou rsh ? Ben, je pense qu'il y a d'autres 
solutions envisageables. Même si je reconnais humblement ne pas 
connaître toutes les problématiques spécifiques de la VoIP et de la 
ToIP, ça me parait effectivement inutilement compliqué. Et surtout, pas 
pensé dans le monde IP actuel, mais plutôtpour un monde IP idéal dans 
lequel tout le monde peut parler à tout le monde sans entrave. C'est 
beau, mais dans la réalité, on s'aperçoit que déléguer toute la question 
de la sécurité à l'application, c'est tout simplement pas jouable.


--





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

Re: [FRnOG] [MISC] Panne

[thierry . chich]

Mais non ! C’est ça le pire ! Je rêve qu’un jour quelqu’un me fournisse un lien 
en me disant : tiens, c’est cet épisode !
Pour moi, c’est au niveau de fabuleux du « petit chef » ou du clip de Modern 
Talking.
Le 11 mars 2019 à 18:26 +0100, David Ponzone , a écrit 
:
> T’as un nom ? :)
>
> Parce que niveau n’importe quoi, ça semble au niveau d’Alias.
>
> > Le 11 mars 2019 à 18:03, Thierry Chich  a 
> > écrit :
> >
> > Franchement, vous vous scandalisez de pas grand chose.
> >
> > Je me rappelle avec émotion d'une série du début des années 90 dans 
> > laquelle le héros s'évadait d'un prison dans laquelle il était géolocalisé 
> > en mettant son collier à un chat qui passait par là. Les stupides gardiens 
> > arrivaient en courant car ils le croyaient en train de s'enfuir (les niais) 
> > , et deux balayettes plus loin, il prenait les clés sur les gardiens 
> > inanimés. N'écoutant ensuite que son courage et les bruits environnants, il 
> > comprenait que le vilain ultime était en train de partir en hélicoptère, 
> > reprenait donc le collier de géolocalisation au chat qui passait de nouveau 
> > par là, et courait l'attacher à l'hélico.
> >
> > Puis, il arrachait le moniteur de géolocalisation du bureau des gardiens et 
> > l'emmenait dans sa voiture pour suivre l'hélicoptère.
> >
> > Là, y avait du niveau.
> >
> > Le 11/03/2019 à 17:31, Hervé BRY a écrit :
> > > Cette scène est aussi la seule chose que j'ai gardé de la série ;)
> > >
> > > L'extrait est en ligne pour ceux qui ne connaissent pas:
> > > https://youtu.be/NIf1Y4qCUU4?t=51
> > >
> > > Hervé BRY
> > > Administrateur Système
> > > Geneanet (http://www.geneanet.org)
> > >
> > >
> > > Le lun. 11 mars 2019 à 17:09, Joel DEREFINKO  a
> > > écrit :
> > >
> > > > Marrant, j'ai gardé le même souvenir de ce fameux premier épisode... et
> > > > j'ai jeté le reste de la saison :D
> > > >
> > > > Joël
> > > >
> > > > -Message d'origine-
> > > > De : frnog-requ...@frnog.org  De la part de
> > > > Arnaud Launay
> > > > Envoyé : lundi 11 mars 2019 16:47
> > > > À : frnog@frnog.org
> > > > Objet : Re: [FRnOG] [MISC] Panne
> > > >
> > > > Le Mon, Mar 11, 2019 at 07:48:41AM +0100, David Ponzone a écrit:
> > > > > Hey non mais y a eu bien pire quand même dans d’autres séries/films.
> > > > > En même temps, quand on regarde des séries pourries :)
> > > > Ca me rappelle le premier épisode S01E01 de Scorpion, où ils
> > > > réussissent à connecter un câble rj45 dans un avion en train de
> > > > décoller à partir d'une voiture de sport roulant sous l'avion... :)
> > > >
> > > > Arnaud.
> > > >
> > > >
> > > > ---
> > > > 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/
> > --
> > <http://www.ac-clermont.fr>
> >
> >
> >
> >
> > ---
> > 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] Perte de paquets sur WAN et parasitage électro-magnétique

[Thierry Chich]

Bonjour

Pour ma part, je n'aime pas quand un problème commence à ressembler à ce 
qui est décrit ici (une multitude de symptômes tous plus ou moins 
corrélés ). Donc je m'efforce de simplifier et d'objectiver. Dans le cas 
de problèmes de pertes de paquets, mon outil favori, c'est smokeping. Et 
ensuite, je pingue avec smokeping tout ce qui se trouve sur le chemin, 
du plus prêt au plus lointain, pour éliminer les différents facteurs.


Avec l'habitude, on arrive à identifier assez simplement tout un tas de 
cas différents (saturation du lien, problèmes de synchro, etc.)


Le 07/02/2019 à 19:22, Vincent Duvernet a écrit :

Glop, glop

Là je m'arrache les cheveux et avant d'aller chercher du côté du vaudou, je 
lance cette dernière bouteille à la mer pour le cas où éventuellement quelqu'un 
aurait l'idée du siècle.

On rencontre des soucis chez un client depuis quelques temps avec leur SDSL 
2Mbps.
Le basculement de Complétel vers Orange n'a rien changé.

Lorsqu'on ping le monde extérieur (8.8.8.8 mais aussi notre IP Orange chez 
nous), on perd des paquets de façon totalement aléatoire. On a déjà remplacé 
l'UTM Sophos par un routeur Netgear de dépannage sans changement. Sachant qu'en 
tête de réseau, on passe par une box business (internet / téléphonie) Cloud de 
Orange avec une IP publique en /28.

Mais le problème ne s'arrête pas là. Certains sites (de Orange à Randstad ou 
les sites de banque) moulinent tellement longtemps sur certains postes qu'on a 
un timeout avec une page pas toujours entièrement rendue.
Le hardware est quasiment identique (HP ProDesk, Win 7 x64 ou x86 Ethernet 
Realtek, clonés à partir d'une machine commune).
La messagerie c'est pas mieux mais je suspecte la mauvaise conf' et 
l'incompétence de l'équipe qui le gère mais on n'a pas la main dessus.

Lors du changement vers Orange, ils ont changé leur switch 100 Mbps Cisco par un 
Orange géré en Cloud => aucune amélioration.

1) je n'ai pas la main sur le switch et le support Orange me dit que la 
gestion SNMPv3 ne fonctionne pas avec PRTG (et que même eux en interne, ils ont 
dû changer de logiciel pour cette partie-là). Quelqu'un a des info sur le sujet 
?

2) la baie est ondulée (APC Online + rack ATS). Certains postes à 
problèmes sont ondulés ou pas avec du off-line. On a commencé à suspecter les 
câbles d'infra sur les postes à problèmes donc cet après-midi, j'ai pas un dongle 
Ethernet USB de chez Dell (chipset Realtek) sur le poste de la DRH avec le même 
câble Ethernet. Et là, même si on perd toujours des paquets mais les sites 
s'affichent très bien la plupart du temps. Lorsque je rebascule sur la carte 
intégrée, j'obtiens du mieux en rechargeant la page hors cache mais dès qu'on 
navigue dans le site, ça re-déconne. (On a mis à jour le driver de la carte LAN 
interne => pas d'amélioration).

Est-ce problème sur certaines adresses MAC ? Est-ce un problème électrique dans 
l'usine ? Est-ce un problème extérieur d'infrastructure ? Je donne ma langue au 
chat.

Merci à la liste pour les contributions à venir.

Vincent


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

--





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

Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine

[Thierry Chich]

La question n'est pas de savoir s'il peut, mais s'il doit. Et là, la 
question peut-être plus trickie qu'il n'y parait.


Donner deux noms avec des adresses différentes, ça ne pose que peu de 
problèmes (à l'exception de quelques systèmes SSO). Donc le corp.domaine 
pour le privé et le .domaine pour le public, ça passe sans souci.


En revanche, si publier en interne du privé pour .domaine et  en externe 
pour du public est très faisable, avec ou sans vues, ça peut avoir des 
conséquences parfois un peu ennuyeuses. Le cas que je vois et que je 
connais bien, c'est le cas où le concept d'"interne" est un peu lâche. 
Tant qu'on est dans un LAN, ça se passe bien, mais si on commence à 
avoir plein de sites distants dont le concept de "interne" repose sur du 
VPN (ipsec par exemple), c'est un peu moins bien.


Pourquoi ?

Parce que souvent, on fait des VPN pour protéger quelques applications. 
Mais on publie aussi des ressources vers  internet (par exemple la 
messagerie). Quand .domaine est du RFC1918 en interne, le site distant 
relié par VPN ne pourra accéder à imaps.domaine que lorsque le VPN est 
up. Ce qui est dommage, puisque la finalité du VPN, c'était seulement de 
protéger erp.domaine. Et donc, on a une infra qui se met à dépendre du 
VPN de manière beaucoup plus importante qu'elle ne le devrait.


Le 08/02/2019 à 17:36, David Ponzone a écrit :

- peut-on résoudre corp.example.com en adressage privé (donc en interne 
seulement) ? Ça voudrait dire qu'on ne dit pas tout en out, mais qui blâmer ? 
publier de l'adressage privé ça sert à rien (sans parler des pb de sécu).

Mais tu fais ce que tu veux.
Personne ne va venir te mettre une amende pour censure ou autre parce que tu ne 
publies pas sur ton DNS public certains services :)
C’est peut-être moi qui comprends mal ce qui t’inquiète à ce niveau, tu peux 
donner un exemple ?
Sinon y a pas des pointures en DNS chez Capgemini ? :)
Ok je sors.


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

--





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

Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine

[Thierry Chich]

Le 08/02/2019 à 20:27, Raphael Mazelier a écrit :

On 08/02/2019 20:17, Michel Py wrote:

Et bien justement je vois pas trop l'interet. Quel est l'avantage 
d'accéder en interne à mail.corp.com avec son ip privé plutot que d'y 
accéder via son ip publique si c'est déjà ouvert sur l'extérieur.




Tout à fait. Ca complique les règles de firewall, et c'est moins robuste 
car on dépend de VPN alors qu'on en a pas forcément besoin pour ça.



--




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

Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine

[Thierry Chich]

Le 10/02/2019 à 14:33, Raphael Mazelier a écrit :
Je pense que c'est un vrai décision d'entreprise. 
Coût/disponibilité/sécurité/temps. Il y a des contextes ou avoir tout 
ses mails/documents/im en Saas est complètement acceptable, comme 
l'inverse.


Le seul truc que je dis c'est que c'est n'a pas du tout trivial et peu 
coûteux d'héberger des services en interne.



Tout à fait.

Du point de vue de l'état, c'est aussi une question de souveraineté. 
L'arrivée de Trump a montré que cette question n'est pas subsidiaire. 
Après tout, on a eu des taxes sur l'acier, ne pourrait pas voir des 
taxes sur les services, en réaction aux taxes GAFA de l'Europe ?



--
Raphael Mazelier

--




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

Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine

[Thierry Chich]

Pour moi, il y a aussi de bonnes raisons d'utiliser des VPN. Au moins 
deux !


1° pour limiter l'exposition d'un service. Une appli un peu obsolète et 
pas forcément bien écrite sera souvent plus sûre si elle n'est 
accessible que de l'intérieur qu'une applis bien écrite exposée sur 
internet. Comme on n'a pas toujours le choix des applis 


2° pour mitiger la gravité d'une perte d'identifiant. Le login/mot de 
passe est un moyen d'authentification nul, et toutes les applis, loin de 
là, ne sont pas écrites avec un système d'authentification forte. Quand 
l'appli est accessible en interne, la gravité de la perte de 
l'identifiant est fortement mitigée.


Après, il y a la partie chiffrement sur laquelle on s’excite souvent - 
il n'y a qu'à voir les annexes du RGS - et qui, à mon avis, est le plus 
anecdotique en terme de sécurité.


Le 11/02/2019 à 22:26, Raphael Mazelier a écrit :
Tout le monde a l'air d'assumer que de maintenir des serveurs sur son 
réseau local d'entreprise semble aller de soi. Personnellement le 
moins d'IT locale j'ai à maintenir le mieux je me porte.


Je pense aussi que le moins d'adhérence il y a entre les sites locaux 
et les infras de prod, le mieux c'est. Je considère que les locaux de 
l'entreprise fournissent une connectivité internet lambda, la même que 
celle d'un accès personnel.




--
Raphael Mazelier


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

--



r 



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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Thierry Chich]

La réponse de la CNIL (qui ne concerne pas la RGPD, mais les principes 
n'ont pas tant changé que ça):


https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

J'adore, à la fin,  la question en suspens. La CNIL ne peut pas 
s'engager sur le fait qu'il y ait un risque juridique à le faire.


Cette page pointe aussi sur une doc de l'ANSSI qui indique un bon nombre 
de précaution à prendre si on s'y lance. En attendant qu'on ne puisse 
plus le faire du tout.


Thierry

Le 25/01/2019 à 08:55, Maxime Jouveaux a écrit :

Bonjour la liste,


Petite question RGPD, je gère actuellement un proxy squid et pour renforcer
la sécurité je regardais pour faire de l'interception SSL(HTTPS).

Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
mais sans collecter de données.


Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
des droits et liberté de chacun, car le proxy verra toutes les informations
HTTPS en clair, ce qui représente une attaque informatique appelée « Man on
the middle ».

Étant donné que l’accès de chaque utilisateur d’internet n’est pas limité,
il peut donc aller sur le site de sa banque ou sur un site médical et
consulter des informations personnelles durant sa pause (Autorisée par le
code du travail).

Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
(exemple : les codes personnels, code carte bancaire etc…).

Ce qui est *une violation du RGPD *de l’employé.



Est-ce que je me trompe?


Note: j'ai une charte informatique en place qui informe les employés que
j'ai un proxy.


Merci à vous.


Maxime JOUVEAUX

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

--




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

Re: [FRnOG] [MISC] Proxy + interception SSL = RGPD?

[Thierry Chich]

Le 25/01/2019 à 09:26, Maxime Jouveaux a écrit :

Avant de poser cette question déjà consulter les documents de la CNIL et de
l'ANSSI, et aucun ne parle de l'implication RGPD.

C'est pour cela que l'a RGPD rend la situation très ambigu.


Pour moi, la RGPD ne change pas fondamentalement les principes de 
protection de la vie privée, par rapport à la loi informatique et 
liberté. Elle change le montant des sanctions et elle supprime le 
dispositif de déclaration pour le remplacer par le maintien de listes.


Sur ce problème particulier, je serais surpris que la RGPD change 
radicalement les choses.


Thierry


Pour les droits du travail, en tant de pause, un utilisateur accédant a
internet peux l'utiliser a des fin personnelles du moment que c'est "bon
enfant".
L'entreprise se réserve le droit de bloquer en cas d’abus.
Mais je ne suis pas la pour interdire l’accès a l'information, je préfère
juste le contrôler.

MJX

Le ven. 25 janv. 2019 à 09:18, Thierry Chich 
a écrit :


La réponse de la CNIL (qui ne concerne pas la RGPD, mais les principes
n'ont pas tant changé que ça):

https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

J'adore, à la fin,  la question en suspens. La CNIL ne peut pas
s'engager sur le fait qu'il y ait un risque juridique à le faire.

Cette page pointe aussi sur une doc de l'ANSSI qui indique un bon nombre
de précaution à prendre si on s'y lance. En attendant qu'on ne puisse
plus le faire du tout.

Thierry

Le 25/01/2019 à 08:55, Maxime Jouveaux a écrit :

Bonjour la liste,


Petite question RGPD, je gère actuellement un proxy squid et pour

renforcer

la sécurité je regardais pour faire de l'interception SSL(HTTPS).

Actuellement, il logue tout le HTTP et que la première demande en HTTPS,
mais sans collecter de données.


Mais je sais que l’interception SSL (HTTPS) peut être illégale vis-à-vis
des droits et liberté de chacun, car le proxy verra toutes les

informations

HTTPS en clair, ce qui représente une attaque informatique appelée « Man

on

the middle ».

Étant donné que l’accès de chaque utilisateur d’internet n’est pas

limité,

il peut donc aller sur le site de sa banque ou sur un site médical et
consulter des informations personnelles durant sa pause (Autorisée par le
code du travail).

Le hic de l’interception SSL(HTTPS) est que le proxy trace tout en clair
(exemple : les codes personnels, code carte bancaire etc…).

Ce qui est *une violation du RGPD *de l’employé.



Est-ce que je me trompe?


Note: j'ai une charte informatique en place qui informe les employés que
j'ai un proxy.


Merci à vous.


Maxime JOUVEAUX

---
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: [TECH] RE: [FRnOG] [TECH] différences entre un réseau MPLS et LAN 2 LAN

[Thierry Chich]

Je pose la question par curiosité, ce n'est pas une provocation, mais 
c'est quoi l'intérêt dans un cas pareil d'éviter le L3 ?


Le 28/01/2019 à 17:45, Olivier Lange a écrit :

Aller,

On va parler de Solutions ;). Tu veux propager du VLAN sur tes sites? Tu
prends une VM, qui soit en haute dispo, ou tu considère que ton site
principal est suffisamment robuste. Tu mets un mikrotik sur chaque site
(aussi en vm, si si). Tu monte un tunnel EOIP vers ton site principal (ta
VM si elle est en haute dispo, ou ton site principal si il est assez
fiable). Soit en directe si tu as une ip public sur tes 2 mikrotiks, soit
via un L2TP (donc L2TP + EOIP). Tu bridge tout ca. A ce moment, tu as un
réseau L2 sur l'ensemble de tes sites.

Il te reste plus qu'a monter tes VLAN sur l'ensemble, a faire ta QOS
(simple queue, pas queue tree), et a monitorer le tout. Il faudra peut être
modifier ton MTU, en fonction de tes liens, mais ca aussi le mikrotik le
gère au niveau de l'EOIP. Tu va perdre un peu, normal, c'est du a
l'encapsulation (on a environ 8% de pertes de BP sur un EOIP + VLAN,
faudrait que je test avec un L2TP en plus). Mais tu es capable de regrouper
autant de sites que tu veux (je crois qu'on est sur 35 sites et 3 pays sur
l'installation de ce type la plus intéressante).

Olivier

Le lun. 28 janv. 2019 à 16:34, Raphael Mazelier  a
écrit :


On 28/01/2019 16:20, David Ponzone wrote:

Jean-Yves,

Je sors le popcorn!


Peut être qu'il faudrait commencer par ne pas confondre
protocole/technologie et son utilisation/services proposés ?

--
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] [MISC] IPV6 Name and Shame

[Thierry Chich]

Le 11/05/2019 à 01:45, Guillaume Barrot a écrit :

En tous cas, cet échange a été des plus intéressants : la seule alternative
à Ethernet qui est citée = Token Ring. (Je passe volontairement Modbus,
relégué de facto au monde industriel).

Frame Relay, ATM, SONET, FiberChannel ... Ouais tout ça, ça fait (mieux) du
niveau 2 qu'Ethernet.
Ils avaient tous par contre les mêmes défauts : plus complexes, plus chers
(et pas que à acheter, mais aussi à produire).


Tous ces beaux vainqueurs auraient été capable de faire ce qu'a fait 
Ethernet, c'est à dire de s'adapter de 10M à 100G sans trop de souci, 
tout en étant envisageables pour connecter le PC de monsieur 
Toutlemonde, tout en fonctionnant sur des supports physiques variés, ils 
seraient peut-être encore là. A un certain moment, c'est du darwinisme. 
La sélection naturelle, ça ne sélectionne pas forcément le plus beau, le 
plus fort ou le plus élégant. Ca sélectionne celui qui peut s'adapter 
dans un environnement changeant.


L'ATM avec sa trame de 53 octet dont 8 pour l'entête, ça ne scalait pas 
bien. C'était élégant (peut-être), ça gérait magnifiquement la 
congestion, mais ça ne pouvait pas grimper suffisamment haut et c'était 
trop complexe pour les petits réseaux. C’était juste pas adapté.



Analogie avec IPV6/IPV4 ?


Peut-être. Mais perso, je ne vois pas de profonde différence de nature 
entre IPv6 et IPv4.







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

Re: [FRnOG] [TECH] switch openspace

[Thierry Chich]

Le 17/05/2019 à 13:38, Jerome Lien a écrit :

du coté de nos besoins :
voice-vlan
donc switch layer 2
poe car il y aura un a deux téléphones par bureau en plus d'un thinclient
100m nous suffisent, de sport 1Giga c'est du surplu
faible encombrement en 16 ou 18ports

pour l'instant celui qui retient le plus notre attention serait un
dell X1018P
pour cisco ou hp, on passe vite sur des grand switch pour pour des 24ports
... c'est dommage

on réfléchi à tout passé en FTTD mais cela nous annonce d'autre contrainte.


Lesquelles, par curiosité ?





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

Re: [FRnOG] [TECH] Chiffrement sur liaison

[Thierry Chich]

> Le 3 juin 2019 à 18:45, Stéphane Rivière  a écrit :
> 
>> un systeme secure devrait le rester meme en cas de rétro-ingénierie.
>> dans l'absolu, il devrait rester secure meme si tu es en possession de
>> la totalité des docs...
> 
> C'est une tarte à la crème de la cryptographie. Tout internet dit que la 
> protection par l'obscurcissement est une mauvaise démarche. Ca semble logique 
> : la revue par les pairs est une démarche scientifique.
> 
> Sauf que…
> 


Sauf qu’un des principes de la sécurité, celui de la sécurité en profondeur, 
c’est que plus tu ajoutes de couches de sécurité pertinente, plus c’est 
compliqué de t’avoir. L’obfsucation est une de ces couches.

Mais dans le cas présent, il peut y avoir une autre raison. Il est possible 
d’imaginer que les militaires souhaitent que les liaisons qu’ils chiffrent 
soient très dures à déchiffrer pour les autres, mais qu’il soit aussi possible 
de le déchiffrer si besoin. Sait-on jamais, il est toujours possible d’imaginer 
qu’au plus haut niveau, on souhaite pouvoir savoir ce que pourrait se dire les 
hauts gradés. Ce n’est pas comme si, dans l’histoire, il n’y avait jamais eu de 
généraux félons…
Auquel cas, l’obfuscation viserait plus à masquer les backdoors que le 
protocole en lui-même...

Il ne s’agit bien sûr que de simples suppositions.

Thierry

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

Re: [MISC] Re: [FRnOG] [JOBS] Concours d'ingénieur des systèmes d'information et de communication

[Thierry Chich]

Le 28/05/2019 à 12:30, Radu-Adrian Feurdean a écrit :

On Tue, May 28, 2019, at 12:12, Raphael Jacquot wrote:

marrant, ca ressemble beaucoup a l'état d'esprit des énarques qui
pullulent a Bercy...

Il n'y a pas que des enarques dans les ministeres/administrations. Avec un 
minimum d'efforts tu dois pouvoir trouver aussi quelques X.


serais-ce un tropisme lié au concept de "grande école a la française" ?

C'est exactement ca.

J'ai connu les deux types: brillants et ouverts, ou prétentieux et 
fermés. On peut donc supposer que ce serait plutôt un tropisme du 
"préjugé sur les grandes écoles à la française. Cela dit, ceux qui 
restent modestes ont bien du mérite, parce que dans certaines écoles, on 
est pas trop économe sur le mot "excellence".


--




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

Re: [FRnOG] [TECH] Chiffrement sur liaison

[Thierry Chich]

Le 17/06/2019 à 23:48, Alexandre der Garabedian a écrit :

A mon avis les algorithmes et/ou le protocole lui meme ne sont pas trusté
par l’ANSSI, la premiere solution etant la plus probable ;)


Si c'est le cas (une critique sur l'algorithme), je trouve vraiment 
dommage que l'ANSSI ne fasse une publication. C'est bien plus 
intéressant pour nous d'avoir un avis sur un algo qu'une certification 
sur un matériel (à part pour ceux qui doivent vraiment être ANSII-proof, 
évidemment).


Thierry

--





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

Re: [FRnOG] [MISC] [JOBS] Concours d'ingénieur des systèmes d'information et de communication

[Thierry Chich]

Bonjour

Je ne dis pas que ce soit un monde idéal, mais ce qui est décrit 
ci-dessous est :


- soit complétement caricatural. Par exemple, dans l'Education Nationale 
et le Supérieur, les ingénieurs sont évalués par d'autres ingénieurs, et 
les concours ne portent pas sur des sujets n'ayant rien à voir avec leur 
métier.


- soit commun avec toutes les grosses structures.

Cdt

Le 22/05/2019 à 22:12, Olivier Vailleau a écrit :

Le mer. 22 mai 2019 à 07:57, Nicolas Sulek 
a écrit :


Donc si tu te débrouilles bien, à 50-55 ans, tu peux finir ingénieur
[...]



"Si tu te débrouille bien", ne signifie pas "Si tu es un super ingé, nickel
dans ton taf', hyper performant, irréprochable, etc"

Pour monter les échelons et passer les hors classe, bref, pour accélérer ta
carrière, il faudra bucher des concours débiles qui te permettront
d'obtenir un "niveau" d'ingé++ par exemple mais pour lequel ton employeur
n'a pas forcément le poste adéquat. Dans ce cas, tu attendra...
longtemps... que le poste en question (le tient) soit transformé et
corresponde au niveau que tu a obtenu en concours. D'ici là, tes fins de
mois n'ont pas bougé d'un yota.

Dans ces fameux concours, on n'évalue pas tes capacités professionnelles
(car tu n'es pas évalué par des pairs, mais par 2-3 gars, si possible plus
gradés que ton objectif, pris dans le tas et qui ne connaissent pas ton
métier, car ils gèrent la gestion de l'état civil ou la direction des soins)
En revanche, on te demandera d'être un parfait fonctionnaire : Tu devra
répondre aux merveilleuses questions
- Quelle est votre définition du service public, ?
- C'est quoi être fonctionnaire ?
- Détaillez l'organisation budgétaire d'une collectivité
local/hopital/conseil régional.
- Est-ce que la loi Notre / borlo / sarko / bidule participe de façon
efficiente à la décentralisation ?
- Le bilan des ARS ?
- Qu’ont fait les Urssaf pendant la crise économique ?
- Que pensez-vous de l’aéroport de Notre Dame des Landes ?
- Quel est votre avis sur la responsabilisation des assurés ?

La palme de la palme : il y a quelques années, j'ai du me présenter à un
concours qui m'était réservé : je ne pouvais être que le seul prétendant.
j'ai concouru tout seul pour un poste que je possédait déja.  Cela fut une
"réunion" où nous nous échangeâmes des amabilités avant que le jury ne
s'écharpe car le Dir Qualité n'appréciait pas le DSI.. au milieux, le DRH
courbait l'échine. Je n'y ai rien dit, excepté mon identité...  irréel

Je vous invite à lire "Absolument dé-bor-dée !" de Zoe Shepard. Même si le
trait est un peu exagéré et ne peut refléter toutes les fonctions
publiques, l'idée globale est là avec un joli passage sur les concours.
Je nuancerais en protégeant mes anciens collègues de la fonction publique
hospitalière : je n'y ai pas vu beaucoup de planqués, et il reste possible
d'avancer au mérite, si l'on est dans les petits papiers des DRH/DG.

Bien souvent, les salaires sont compensés par des primes diverses et
variées, qui peuvent atteindre facilement 40% de ton salaire. Ça peu donc
grossir significativement la note finale mais sur ces primes, tu ne cotise
pas pour la retraite évidement. Et la dite prime peut sauter au prochain
ministre ou pour toute raison jugée
impondérable/incontournable/on-y-peut-rien.  La prime n'ayant bien sûr
presque pas de rapport avec ton efficacité car pour ne pas faire de jaloux,
le glandeur d'à coté aura la même que toi. Après, on s'étonne que le
fonctionnaire manque de motivation.. Avec un tel fonctionnement, le service
publique est une usine à fabriquer des fainéants.

ça se sent que je suis blasé ?

:-)


Olivier.




Le 22/05/2019 à 07:33, Michel Py a écrit :

J'ai une question con (quelle surprise).


En province, les ingénieurs peuvent prétendre à un salaire d’environ

2100 € net.

A l'âge avancé de 50 à 55 ans, en moyenne, combien çà fait ?

Merci.
Michel.


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


--

Nicolas Sulek

SGAMI Sud-Ouest/DSIC/DSSD

05 57 19 42 57


---
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] Firewall with Group Policy

[Thierry Chich]

Bonjour

Le 07/05/2019 à 11:47, Mikael R. - Engine-Serv a écrit :

Bonjour,

Je cherche une solution software certifiée "Données Sensibles" pour
réaliser des redirections de sessions HTTP en fonction de l'appartenance à
un groupe Active Directory vers deux ip différentes.

Avez vous une piste ?
Un firewall logiciel peut-il requêter un AD pour avoir cette info de groupe
et appliquer une règle en fonction ?



J'ai testé sur Fortinet, on peut attraper le groupe AD  soit en allant 
chercher directement dans l'annuaire, soit en installant un client sur 
l'AD qui pousse les données. Ca fonctionne, mais il y a des limitations 
quand on est en situation de mobilité.


Pour ce qui est de la redirection en tant que telle, je n'ai jamais fait 
ça sur un firewall.  A mon avis, il y a ce qu'il faut sur les fortigate 
(il y a des fonctions de load-balancing). Cela dit, je ne mettrais pas 
ma main à couper que les deux fonctionnalités qu'il faut utiliser se 
marient bien, par contre.



Cdt

--
<http://www.ac-clermont.fr>
    

Thierry CHICH




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

Re: [FRnOG] [TECH] switch openspace

[Thierry Chich]

Bonjour


Ce qui m'étonne le plus, c'est une marque différente pour chaque nombre 
de ports. Je trouve ça étrange, parce que ça semble signifier que vous 
n'attendez pas grand chose de la config.


Sinon, sur le HP, on en a quelques uns en full-giga-poe, qui sont 
corrects, même s'ils chauffent un peu. Mais ils ne sont pas ventilés, ce 
qui est quand même vraiment le bonheur sur un bureau. Mon regret,  c'est 
juste que la CLI soit différente des modèles plus haut de gamme (et plus 
ancien). HP n'en finit plus de converger vers une cli unifiée avec ses 
différents rachats (H3C, arruba). C'est pas les seuls, mais c'est 
ennuyeux. Rien de grave toutefois. Le voice-vlan (avec LLDP-med inclus) 
fonctionne, ce qui est quand même assez cool.


Thierry

Le 16/05/2019 à 08:45, Jerome Lien a écrit :

bonjour,

nous avons un openspace à cabler dans quelques temps et nous aurons une
30ene de bureau de 4 à 16 personnes. Au lieu de tirer 30 câbles réseaux par
bureau, nous pensions placer des switch par bureau avec 1 à 2 uplink.
avez vous des retour d'expérience sur les switch
8ports > HP 2530-8-poe
18 ports > x1018p
26 ports > dell x1026p / mikrotik CRS328-24P-4S+RM

ou ubiquiti ou cisco ?

merci d'avance pour vos retours,

jerome

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

--



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

Re: [FRnOG] Re: [TECH] Latence Transatlantique

[Thierry Chich]

L'or pour les rayons X, ai-je cru lire.

Le 18/04/2019 à 15:28, Michel Hostettler a écrit :

Pour certains matériaux  dont je ne me souviens plus du nom, l'indice de 
réfraction est inférieur à l'unité.
La vitesse de phase est donc supérieure à celle de la lumière.
Michel

- Mail original -
De: "stef" 
À: "frnog" 
Envoyé: Jeudi 18 Avril 2019 15:14:21
Objet: Re: [FRnOG] Re: [TECH] Latence Transatlantique


Nous savons découper le temps, l’échantillonner, sans perdre d’information. Il 
ne me reste plus qu’à trouver un ou deux paramètres dans mon équation afin de 
réussir à l’immobiliser… assurément,

Le jour où quelqu'un arrive à figer le temps ou à dépasser la vitesse de
la lumière, nous aurons trouvé notre nouvel Einstein... (il serait temps
d'ailleurs pour garder le moral dans notre coin de galaxie).


dites-vous. Pourtant… le silence après Mozart n’est-il pas encore du Mozart ?

Certainement, plus sûrement avec du Wagner :>


Il suffit de ne pas transporter d'information. C'est déjà le cas de
90 % des courriers, 95 % des pages Web et 99 % des communiqués de
presse.

99% des communiqué de presse me semblent encore optimiste...


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


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

--
<http://www.ac-clermont.fr>   

Thierry CHICH

Adjoint RSSI

SSI : Sécurité des Systèmes d'Information
PRH : Pôle réseaux et hébergement

DSI : Direction des Systèmes d'Information

04 73 99 30 54
thierry.chich@ac‑clermont.fr <mailto:thierry.ch...@ac-clermont.fr> ‑ 
dsi‑rese...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>


RECTORAT ‑ 3 avenue Vercingétorix - 63033 Clermont-Ferrand Cedex ‑ Site 
internet <http://www.ac-clermont.fr>



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

[FRnOG] [TECH] DHCP relay sur des nexus 9000

[Thierry Chich]

Bonjour

Je suis assez dubitatif sur la conf dhcp relay des nexus. En fait, j'y 
arrive, mais j'ai des soucis d'adresse source envoyé au serveur.


J'ai un vlan 1140 dans lequel j'ai mon nexus et un serveur dhcp 
(respectivement 10.0.0.254 et 10.0.0.11). Et j'ai un vlan  302 dans 
lequel je veux distribuer du dhcp en 192.168.0.0/24. Mon nexus a une ip 
dans ce vlan.


TOR-20(config)# do show  running-config  ip
version 7.0(3)I7(1)
ip route 0.0.0.0/0 Vlan1140 10.0.0.254
vrf context management
  ip route 0.0.0.0/0 192.168.2.254
interface Vlan302
  no ip redirects
  ip address 192.168.0.100/23
interface Vlan1140
  ip address 10.0.0.11/23

interface mgmt0
  ip address 192.168.2.100/24

Je ne pense pas que la vrf management intervienne, mais bon. J'ai 
configuré un dhcp relay:


TOR-20(config)# do show running-config dhcp
version 7.0(3)I7(1)
feature dhcp

service dhcp
ip dhcp relay
ipv6 dhcp relay

interface Vlan302
  ip dhcp relay address 10.0.0.254

A ce point, pas de souci, quand je fais des captures, j'envoie bien au 
serveur DHCP


14:25:16.725836 IP 192.168.0.100.67 > 10.0.0.254.67: BOOTP/DHCP, Request 
from 28:ac:9e:a7:d7:55, length 310


Mais ici, rien ne va plus. Mon serveur DHCp est un firewall, et il 
refuse de faire le serveur DHCP pour le réseau 192.168.0.0/23 si 
l'interface qui le supporte ne supporte pas ce réseau justement. Et du 
coup, ça marche vachement pas beaucoup. Parce que forcément, quand il 
reçoit une requête de ce type, il cherche à répondre à  192.168.0.100, 
qui pour lui est un voisin. Et donc résolution arp qui marce pas.


Bref, ça m'arrangerait que le nexus change l'IP source et me mette celle 
portée par l'interface vlan 1140. Ca tombe bien me direz vous, il existe 
une commande qui a l'air de faire ça:


ip dhcp relay source-interface Vlan1140

On peut la mettre où on veut (global, interface, etc.).

Mais ça marche pas. Le nexus ne renvoie plus rien dans ce cas. Et 
j'avoue que ça commence à m'agacer parce que j'ai des docs qui indiquent 
précisément des choses de ce type (en utilisant plutôt la loopback, mais 
bon, c'est la même idée). Est-ce que quelqu'un sait, ou à une idée de 
comment debugguer une problème de ce type ?


Merci

--




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

Re: [FRnOG] [TECH] DHCP relay sur des nexus 9000

[Thierry Chich]

Désolé d'avoir été trop vite.

debug dhcp all m'a permis de comprendre qu'il lui fallait autoriser les 
options avec:


|ip dhcp relay information option ip dhcp relay information option vpn|

Voila voila.

Le 12/07/2019 à 14:46, Thierry Chich a écrit :

Bonjour

Je suis assez dubitatif sur la conf dhcp relay des nexus. En fait, j'y 
arrive, mais j'ai des soucis d'adresse source envoyé au serveur.


J'ai un vlan 1140 dans lequel j'ai mon nexus et un serveur dhcp 
(respectivement 10.0.0.254 et 10.0.0.11). Et j'ai un vlan  302 dans 
lequel je veux distribuer du dhcp en 192.168.0.0/24. Mon nexus a une 
ip dans ce vlan.


TOR-20(config)# do show  running-config  ip
version 7.0(3)I7(1)
ip route 0.0.0.0/0 Vlan1140 10.0.0.254
vrf context management
  ip route 0.0.0.0/0 192.168.2.254
interface Vlan302
  no ip redirects
  ip address 192.168.0.100/23
interface Vlan1140
  ip address 10.0.0.11/23

interface mgmt0
  ip address 192.168.2.100/24

Je ne pense pas que la vrf management intervienne, mais bon. J'ai 
configuré un dhcp relay:


TOR-20(config)# do show running-config dhcp
version 7.0(3)I7(1)
feature dhcp

service dhcp
ip dhcp relay
ipv6 dhcp relay

interface Vlan302
  ip dhcp relay address 10.0.0.254

A ce point, pas de souci, quand je fais des captures, j'envoie bien au 
serveur DHCP


14:25:16.725836 IP 192.168.0.100.67 > 10.0.0.254.67: BOOTP/DHCP, 
Request from 28:ac:9e:a7:d7:55, length 310


Mais ici, rien ne va plus. Mon serveur DHCp est un firewall, et il 
refuse de faire le serveur DHCP pour le réseau 192.168.0.0/23 si 
l'interface qui le supporte ne supporte pas ce réseau justement. Et du 
coup, ça marche vachement pas beaucoup. Parce que forcément, quand il 
reçoit une requête de ce type, il cherche à répondre à 192.168.0.100, 
qui pour lui est un voisin. Et donc résolution arp qui marce pas.


Bref, ça m'arrangerait que le nexus change l'IP source et me mette 
celle portée par l'interface vlan 1140. Ca tombe bien me direz vous, 
il existe une commande qui a l'air de faire ça:


ip dhcp relay source-interface Vlan1140

On peut la mettre où on veut (global, interface, etc.).

Mais ça marche pas. Le nexus ne renvoie plus rien dans ce cas. Et 
j'avoue que ça commence à m'agacer parce que j'ai des docs qui 
indiquent précisément des choses de ce type (en utilisant plutôt la 
loopback, mais bon, c'est la même idée). Est-ce que quelqu'un sait, ou 
à une idée de comment debugguer une problème de ce type ?


Merci






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

Re: [FRnOG] [TECH] Poste d'administration multi-niveaux

[Thierry CHICH]

Pour notre part, nous voudrions tenter de fonctionner à base de machines 
virtuelles au dessus d’un système durci. 
D’un côté on lancerait des machines « utilisateurs » et de l’autre des machines 
« admin ».
Pour avoir utilisé un prototype sommaire, le gros souci, c’est de rendre 
possible les échanges entre les catégories de machines de manière fluide. Il 
n’est pas concevable de ne plus pouvoir copier des bouts de code. Il faut donc 
que le  copier coller et la circulation de fichiers puisse se faire sans trop 
d’entrave.

Cordialement 
Thierry 

> Le 29 juin 2019 à 08:44, professor geek  a écrit :
> 
> Hello,
> 
> Oui je suis confronté aussi a ce pb et comme tu le dis encore plus dans
> notre environnement DevSecOps..
> l’ANSSI developpe un OS sécurisé qui permetrait d’avoir une machine admin
> et une LAN sur le meme hardware.
> la solution se base sur un GENTOO securisé, la solution et sa roadmap sont
> sur GitHub : CLipOS.
> aujourd’hui la solution est en Alpha. j’attends la release … mais comme
> d’hab avec les services d’etats c’est long ! les devs repondent rapidement
> aux questions, c’est deja ca !
> 
> Le poste admin c’est qu’une partie. Ne pas oublié la zone réseau dédié, etc…
> 
> 
> On 28 June 2019 at 18:39:29, Thierry Del-Monte (tdelmo...@integra.fr) wrote:
> 
> Bonjour à tous,
> 
> L'ANSSI dans son guide sur l'administration sécurisée de SI
> (
> https://www.ssi.gouv.fr/uploads/2015/02/guide_admin_securisee_si_anssi_pa_022_v2.pdf),
> 
> préconise dans sa recommandation R9 l'utilisation d'un poste
> d'administration dédié ou à multi-niveaux.
> 
> Est-ce que l'un de vous a déjà mis en place ou rencontré ce
> fonctionnement dans son entreprise ?
> Je suis à la recherche d'un retour d'expérience aussi bien sur la
> solution choisie que sur son exploitabilité au quotidien (la contrainte
> me semble très forte pour les sysops et netops).
> 
> Merci par avance pour votre partage
> 
> Thierry
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] Téléphonie fixe SFR

[Thierry Chich]

Bonjour

On a eu des gros problèmes dans le 15 il y a 2 jours.

Le 11/09/2019 à 12:40, Ludovic RAMOSFILIPE a écrit :

apparement IG dans le département 11 & 22


Le mer. 11 sept. 2019 à 12:34, François Raynaud <
francois.raynaud...@gmail.com> a écrit :


Bonjour à tous,

Nous rencontrons de gros problèmes de téléphonie fixe chez SFR sur nos
sites et la hotline semble submergée.

Avez-vous des retours à ce sujet?

Cordialement,
François Raynaud

---
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/

[FRnOG] [TECH] SFR et twitter

[Thierry Chich]

Bonjour


Depuis le réseau 4G de SFR (pro), j'ai un temps de connexion à Twitter 
long, mais long  alors que j'ai un nperf à 50Mbs et que les autres 
réseaux sociaux fonctionnent plutôt bien. Quelqu'un a-t-il observé ça ? 
Y a des problèmes de peering ? Un filtrage maladroit ?


Thierry

--





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

Re: [FRnOG] Re: [TECH] SFR et twitter

[Thierry Chich]

Le 09/09/2019 à 10:33, Stephane Bortzmeyer a écrit :

Depuis le réseau 4G de SFR (pro), j'ai un temps de connexion à Twitter long,
mais long  alors que j'ai un nperf à 50Mbs

Mais vous savez certainement que capacité et latence sont deux choses
différentes, et que, pour beaucoup de sites Web, c'est la latence qui
compte le plus.


Oui. En l'occurence,  la latence est correcte (pas extraordinaire non 
plus), y compris avec twitter.com. 100ms. Surtout, il n'y a pas de 
pertes. Après, je n'ai testé la fragmentation. Je ne suis pas sûr de 
pouvoir changer la taille des paquets ICMP et forcer le DF sur un iphone.



Sinon, on est sur FRnog, donc pas besoin de rappeler qu'il faudrait
faire un traceroute ?


Je n'ose imaginer que cela soit nécessaire de le rappeler :

traceroute to twitter.com (193.42.244.104)...
0 -  *  *  *
1 10.4.2.8  100,53ms
1 10.4.0.8  29,88ms  34,32ms
2 10.187.162.252  44,98ms  31,23ms  35,17ms
3 13.134.136.77.rev.sfr.net (77.136.134.13)  32,4ms  33,46ms  31,76ms
4 38.10.136.77.rev.sfr.net (77.136.10.38)  57,22ms  37,4ms  41,14ms
5 245.10.136.77.rev.sfr.net (77.136.10.245)  56,65ms  42,27ms  41,87ms
6 245.10.136.77.rev.sfr.net (77.136.10.245)  54,18ms  38,28ms  39,81ms
7 80.249.208.130  73,95ms  68,27ms  57,74ms
8 -  *  *  *
9 104.244.42.193  118,01ms  110,96ms  83,83ms

Mais je précise qu'initialement, je demandais juste pour savoir si 
quelqu'un savait quelque chose sur cette curiosité, d'où l'absence de 
velléité de  debug dans mon mail initial.


Thierry




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

Re: [FRnOG] [MISC] Configuration network, service publicité

[Thierry Chich]

Le 04/11/2019 à 14:06, x.r...@sipleo.com a écrit :

L'utilisation locale me semble être plus adapté à ce type de cas.
DD local MVNe en raid 0 ou 10 (pour ceux qui peuvent).

Mais, je suis d'accord avec Frank,
Compter sur l'humain pour faire une procédure bien simple mais sans valeur 
ajouter si cela fonctionne cela ne durera pas dans le temps.

Utilisation de DFS pourrait être une solution mais dans ce cas les machines des 
graphistes doivent être en Win server.
Ce n'est pas le même budget :)



Ca parait compliqué. Pourquoi ne pas simplement mettre le partage en 
mode hors connexion avec une synchro périodique ?




-Message d'origine-
De : Kavé Salamatian 
Envoyé : lundi 4 novembre 2019 10:27
À : Frank ALEXIS 
Cc : Baptiste Franchina ; Jerome Lien 
; frnog-m...@frnog.org
Objet : Re: [FRnOG] [MISC] Configuration network, service publicité

Il connaissent pas git ou SVN chez les graphistes :-).

Kv


Le 4 nov. 2019 à 09:04, Frank ALEXIS  a écrit :

Bonjour,

Nos 2 cts d’expertise adobe / macOS / win dans des agences depuis 20
ans


NAS (Synology pour pas faire de pub !) FULL SSD 2x1Gb (on sait jamais
le switch aïe)

Pas trop de polices ouvertes !!!
FontAgent pro pour gérer.

Des noms de fichiers PROPRES !

En règle générale les vm qui hébergent des fichiers : pas performant
pour cet univers.

L’idée de rapatrier sur le poste local et de remettre : bullshit !
Aucun graphiste ne fera ça 

@+
Frank

Le lun. 4 nov. 2019 à 08:54, Baptiste Franchina
 a écrit :


Bonjour Jérôme
De suivre les préconisations d'Adobe :

https://helpx.adobe.com/photoshop/kb/networks-removable-media-photosh
op.html Inciter les utilisateurs à travailleurs sur leur disque et
renvoyer les fichiers une fois achevé Le SSD et un bon réseau pour
leur permettre de rapatrier rapidement les fichiers

A+

--
Baptiste Franchina
BoucheCousue
01 83 62 52 34

-- Message d'origine --
De: "Jerome Lien" 
À: frnog-m...@frnog.org
Envoyé : 04/11/2019 08:49:52
Objet : [FRnOG] [MISC] Configuration network, service publicité


Bonjour à tous,

nous possédons un service publicité (7 personnes) (qui à grandit

récemment)

qui travaille sous Windows 10 et la suite adobe, indesign,
photoshop, illustrator et parfois première pro. Hors première pro,
ils travaillent couramment avec des fichier entre 80Mo jusqu'à 500Mo.
Le serveur de fichier un un VM sous windows 2016 avec disque SSD et
un

lien

1Gbps.
Les machines des utilisateurs sont des i9 ou des xeon, 32Go de ram,
ssh ou nvme et carte 1Gbps cuivre.

sauf qu'il se plaignent souvent de lenteur, plantage..

Après analyse, les soft adobe font énormément d’accès réseau car les
fichiers qu'ils utilisent sont lié à plein d'autres fichiers (ce qui
est normal en soit)

Avez vous des conseils sur l'infra que vous mettez en place pour ce
genre de service ?

merci, jérôme

---
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/

--
<http://www.ac-clermont.fr>   

Thierry CHICH

Adjoint RSSI

SSI : Sécurité des Systèmes d'Information
PRH : Pôle réseaux et hébergement

DSI : Direction des Systèmes d'Information

04 73 99 30 54
thierry.chich@ac‑clermont.fr <mailto:thierry.ch...@ac-clermont.fr> ‑ 
dsi‑rese...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>


RECTORAT ‑ 3 avenue Vercingétorix - 63033 Clermont-Ferrand Cedex ‑ Site 
internet <http://www.ac-clermont.fr>



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

RE: [FRnOG] [TECH] Mikrotik et Multicast

[Thierry Chich]

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone
> Envoyé : jeudi 12 décembre 2019 09:48
> À : Hugues Voiturier 
> Cc : FRnOG 
> Objet : Re: [FRnOG] [TECH] Mikrotik et Multicast
> 
> Yep, le mettre à no sur le/les ports egress, ça aide, merci!
> 
> Je vais activer l’IGMP snooping aussi, ça va aider aussi.


J'y connais pas grand-chose, mais activer l'IGMP snooping , a priori, c'est 
vital ,sinon, le multicast c'est du broadcast.
> 
> > Le 11 déc. 2019 à 23:33, Hugues Voiturier  a
> écrit :
> >
> > Tu as essayé de décocher “Unknown Multicast Flood” dans ton interface
> dans l’onglet Bridge / Port ?
> > Ça coupe tout le multicast chez moi…
> > Hugues
> > AS57199 - AS50628
> >
> >> On 11 Dec 2019, at 23:09, David Ponzone  > wrote:
> >>
> >> Le challenge de la nuit: filtrer un flux multicast qui entre sur le port
> ethernet (membre d’un bridge) d’un ROUTEUR Mikrotik.
> >>
> >> Moi je dis: impossible.
> >> J’ai essayé au niveau du firewall ip (mais c’est normal que ça marche pas,
> j’avais pas activé use-ip-firewall) et au niveau du bridge filter:
> >>
> >> /interface bridge filter
> >> add action=drop chain=input in-interface=ether8 packet-type=multicast
> >>
> >> Ca donne:
> >>
> >> /interface bridge filter print stats
> >> Flags: X - disabled, I - invalid, D - dynamic
> >> #   CHAINACTION BYTES 
> >> PACKETS
> >> 0   inputdrop  8155389475 
> >> 7791558
> >>
> >> Ca semble dropper mais le flux est toujours là en out sur l’autre port du
> bridgeU
> >>
> >> J’ai essayé:
> >>
> >> /interface bridge filter
> >> add action=drop chain=input in-bridge=bridge packet-type=multicast
> >>
> >> Pas mieux.
> >>
> >> Globalement, Google semble confirmer que c’est pas possible, mais je
> trouve ça incroyable.
> >>
> >> Quand j’aurais réussi à bloquer, je chercherai d’où ce vient ce flux alors
> qu’il va vers un switch qui le réplique vers des téléphones Yealink, donc à
> priori pas des clients Multicast….
> >>
> >> Note du troll: il y a de plus en plus de « prestataires » qui font mumuse
> avec des trucs multicast sans rien y comprendre et c’est inquiétant. Moi j’y
> comprends rien, et j’essaie pas de jouer avec.
> >>
> >>
> >>
> >> ---
> >> 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] IPv4 privée sur internet ?!

[Thierry Chich]

Bonjour

Effectivement, le plus probable, c'est qu'après le routeur 10.4.191.254, 
l'IP 10.10.1.251 soit nattée.


Sinon, l'inconvénient que je vois au fait de faire un tunnel IPSEC entre 
deux routeur qui sont connectés directement en niveau 2 sur , c'est que 
pour les VPN IPSEC, il faut configurer le left next hop et le right next 
hop, et que là, ils vont être confondus avec l'adresse de destination. 
Du point de vue pédagogique, c'est pas top.


Le 05/12/2019 à 15:43, Cécile MORANGE a écrit :

Hello la liste,
Petite question (bête, probablement) sur l’infra de mon école.
En essayant de monter un VPN entre deux routeur, je me rends compte que non 
seulement mon VPN ne fonctionne pas, mais qu’il m’envoie mes IP locales sur 
internet (!).

L’objectif du VPN est de faire ceci :
10.10.1.254 -> 192.168.4.250 -> 192.168.4.249 -> 10.10.2.251
(oui on doit faire un VPN avec deux IP dans le même plage, on passera ce point)
Soit :
R1 LAN -> R1 « Wan » -> R2 « Wan » -> R2 LAN

Mais à ma grande surprise, ça me donne :
- Depuis mon PC, en 10.10.1.150 :

C:\Users\Admin>tracert 10.10.2.251
Détermination de l’itinéraire vers 10.10.2.251 avec un maximum de 30 sauts.
   1 1 ms 3 ms 3 ms  10.10.1.254 -> la patte LAN de R1
   2 2 ms 1 ms 1 ms  192.168.4.1 -> le routeur de l’école, qui fait 
gateway
   3 *** Délai d’attente de la demande dépassé.
   4 **   16 ms  10.4.191.254
   5 *   14 ms14 ms  185.43.68.29
   613 ms13 ms16 ms  185.43.68.22
   7 *** Délai d’attente de la demande dépassé.
   8 *   20 ms14 ms  te2-2-71.bbn-sde-1.nerim.net [194.79.133.1]
   9   109 ms   110 ms   118 ms  194.79.131.86
  10 *  112 ms   114 ms  194.79.131.109
  1189 ms92 ms29 ms  te2-3-173.bbn-cbe-1.nerim.net [194.79.128.126]
  12 *  111 ms * 194.79.128.210
  13 *** Délai d’attente de la demande dépassé.
  14 **  110 ms  ge1-0-1-182.edg-cbe-3.nerim.net 
[194.79.131.109]
  1523 ms14 ms14 ms  te2-3-173.bbn-cbe-1.nerim.net [194.79.128.126]
Et ca boucle après.

- Depuis le Cisco 881 (R1) :

R1#traceroute 10.10.2.251 source 192.168.4.250
Type escape sequence to abort.
Tracing the route to 10.10.2.251
VRF info: (vrf in name/id, vrf out name/id)
   1 192.168.4.1 4 msec 0 msec 0 msec -> le routeur de l’école, qui fait 
gateways
   2 10.4.191.89 12 msec 12 msec 12 msec
   3 10.4.191.254 12 msec 12 msec 16 msec
   4 185.43.68.29 12 msec 12 msec 16 msec
   5 185.43.68.22 12 msec 16 msec 12 msec
   6 185.43.68.9 12 msec 12 msec 12 msec
   7 194.79.129.2 [MPLS: Labels 434/17 Exp 0] 12 msec 12 msec 12 msec
   8 194.79.131.86 [MPLS: Labels 984/16 Exp 0] 12 msec *  *
   9  *  *  *
  10  *  *  *
  11  *  *  *
  12 194.79.131.242 76 msec 112 msec 108 msec
  13  *  * 194.79.131.142 [MPLS: Labels 852/16 Exp 0] 108 msec
  14 194.79.131.141 [MPLS: Labels 13456/16 Exp 0] 112 msec *  *
  15  *  *  *
Et ca boucle après.

Ma question est pourquoi mon IP privée arrive à atterrir chez Nerim ?! (Désolé 
d’ailleurs si il y a des personnes de Nerim dans la liste, en espérant que ça 
vous impacte pas)
Il n’y a pas des protections pour drop le traffic des IPs RFC 1918 vers 
l’extérieur ?
Je trouve ça plutôt étonnant, et j’imagine que ça peut perturber le réseau de 
l’opérateur…
  
Si vous pouvez m’éclairer…

Merci d’avance !

Cordialement,

Cécile MORANGE
cont...@cecilemorange.fr
@AtaxyaNetwork


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

--





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

Re: [FRnOG] [TECH] Checkpoint R77.20 - drop de paquets etrangers au LAN en mode bridge

[Thierry Chich]

Le 04/12/2019 à 15:15, Frederic Dumas a écrit :


Bonjour à tous,

Après quelques vérifications, il apparait que:


 - les requêtes vers les machines distantes sont bien acheminées par la
   passerelle; elles traversent donc le bridge;

 - les réponses parviennent à la passerelle, qui les émet sur son
   interface, de son coté du bridge;

 - malheureusement, tcpdump est formel: de l'autre coté du bridge, sur
   le reste du LAN, le CheckPoint ne transmet aucun des paquets sortant
   de la passerelle, dès lors que ceux-ci ont des machines
   distantes pour adresse d'origine;

 - pour fermer la porte à une fausse piste, le phénomène se produit
   aussi bien lorsque le filtrage sur MAC address est activé ou
   désactivé sur le CheckPoint;

 - cependant, comme dit plus haut, le CheckPoint transmet bien sur le
   bridge tous les paquets émis par la passerelle, dès lors que ceux-
   ci ont pour adresse d'origine celle de la passerelle elle-même.

Si on essaye de "tirer dans le noir" comme disent les anglo-saxons, ça 
fait penser à une règle d'anti-spoofing qui droperait les paquets de 
retour, car ils ont une adresse d'origine extérieure au LAN. Mais rien 
ne le confirme dans les logs du CheckPoint. Les paquets ont disparus, 
et c'est tout.


Bug ou feature ? Y-a-t-il un moyen de configurer le CheckPoint pour 
contourner ce problème ? Une route à déclarer pour contourner le 
filtre anti-spoofing, pour autant que ce soit lui la cause ?



Merci pour vos conseils ou hypothèses.



Bonjour

 Ca ressemble effectivement à  quelque chose comme un spoofguard. Je 
n'ai plus de checkpoint depuis longtemps, mais je me souviens qu'il y 
avait une super commande qui permettait de savoir exactement à quel 
niveau de l'examen le paquet était droppé.  Il y avait bien sûr 'fw 
monitor' qui permettait d'en savoir plus quer tcpdump, mais je me 
demande s'il n'y avait pas une commande qui allait encore plus dans le 
détail ? Je me demande si ce n'est pas 'fw ctl zdebug' ?


Cdt

Thierry

--






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

Re: [FRnOG] [TECH] Gros flux de TCP ACK octets vers un port 80

[Thierry Chich]

On pourrait imaginer aussi qu'il s'agisse de la réponse à une tentative 
de ddos sur le routeur en question. Mais ça devrait se voir. Il devrait 
y avoir un flux de SYN sur ce routeur. A moins bien sûr qu'il fasse du 
NAT pour quelque chose ouvert en port 80, auquel ca ça serait la chose 
en question qui serait attaquée.


Le 26/10/2019 à 08:28, David Ponzone a écrit :

Un gros (33Mbps) flux de paquet TCP ACK (20 octets de taille, pas de payload) 
vers une IP unique sur Internet, ça ressemble à quoi pour vous ?
Le routeur est un Zyxel (beurk).
Un petit malin qui a trouvé un moyen de lancer une attaque par amplification 
vers l’IP en question ?
Ce qui m’ennuie c’est que je vois pas de paquets entrants qui pourraient être 
la cause.

J’ai pas encore si Zyxel avait des gros trous mais je suppose que oui.

merci


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





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

Re: [FRnOG] [MISC] Incident Free depuis 1h du matin

[Thierry Chich]

Le 28/11/2019 à 19:40, Raphaël Jacquot a écrit :

ce qui ne sert strictement a rien dans la plupart des cas, les attaques
se faisant par trojan envoyé sous forme de javascript dans les pubs, ou
des saloperies dans les mails


Non. Vraiment non.

Si je prends l'exemple de chez moi, j'ai 2 appareils sur 16 qui sont des 
PC, le reste n'est pas concerné par les mails en javascript. C'est pour 
beaucoup de l'Iot dont la sécurité ne me préoccupe pas trop dans la 
mesure où ils ne sont pas accessibles directement. Je n'apprécierais pas 
du tout de savoir que tous est accessible directement sans avoir été mis 
au courant. Et je ne comprendrais pas que mon fournisseur d'accès n'ait 
pas mis par défaut un firewall centralisé. Et si le dit opérateur me dit 
" mais t'inquietes pas, on peut pas les trouver tes bidules", je pense 
que j'y trouverais à redire.


Le NAT, on en a plus besoin avec IPv6, ok, le firewall, c'est une autre 
histoire.


Thierry

--





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

Re: [FRnOG] [MISC] Incident Free depuis 1h du matin

[Thierry Chich]

Le 29/11/2019 à 10:54, Radu-Adrian Feurdean a écrit :

On Fri, Nov 29, 2019, at 10:17, Thierry Chich wrote:

au courant. Et je ne comprendrais pas que mon fournisseur d'accès n'ait
pas mis par défaut un firewall centralisé. Et si le dit opérateur me dit

Un firewall *centralise* par default, c'est le moment de paniquer.
Un sur la box/CPE j'en veux bien, mais pas *centralise*. L'horreur sur le 
mobile ca suffit pas ?

Centralisé au niveau de mon LAN, naturellement.

Le NAT, on en a plus besoin avec IPv6, ok, le firewall, c'est une autre 
histoire.

Ce n'est pas le firewall dont on a besoin, mais de la securite. Et avec plein 
de gens qui ne l'ont toujours pas decouvert encore, le firewall estune des 
solution, mais definitivement pas la meilleure (meme loin de la).


 En matière de sécurité, il faut prendre en compte ce qui est 
concrètement faisable et il faut ajouter le plus de couches possibles 
(tant que ça reste pertinent). C'est comme pour la sécurité de la 
maison, c'est pas parce que j'ai une alarme et  un chien  que c'est 
idiot d'avoir une porte.


--





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

RE: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq

[Thierry Chich]

Hello

D'un point de vue conceptuel, qu'est-ce qui justifie qu'on mêle QoS et MTU ? Je 
trouve ça bizarre.  

Thierry

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jérôme BERTHIER
> Envoyé : vendredi 20 décembre 2019 10:24
> À : Michel Py ; Jeremy
> ; frnog-tech 
> Objet : Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
> 
> Salut,
> 
> Le 19/12/2019 à 22:48, Michel Py a écrit :
> > Le MTU renvoyé par l'interface, il est applicable dans quel cas ?
> 
> 
> Visiblement, en l'état par défaut, si tu n'appliques pas de Network QOS...
> 
> En fait, je pense que ça dépend des modèles et ça se complique sur ceux qui
> supportent la convergence SAN.
> 
> 
> Tu peux utiliser un MTU différent par classe de service donc au final le
> MTU de l'interface n'a pas vraiment d'application (sauf par défaut ?).
> 
> "MTU is specified per system class. The system class allows a different
> MTU for each class of traffic but they must be consistent on all ports
> across the entire switch. You cannot configure MTU on the interfaces."
> 
> "The show interface command always displays 1500 as the MTU. Because the
> Cisco Nexus device supports different MTUs for different QoS groups, it
> is not possible to represent the MTU as one value on a per interface level."
> 
> 
> Exemple Nexus 5600 :
> https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/s
> w/qos/7x/b_5600_QoS_Config_7x/b_6k_QoS_Config_7x_chapter_0110.htm
> l
> 
> 
> > Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la 
> > confusion
> ?
> 
> 
> On est bien d'accord que ça crée une situation illisible. ça a l'air
> complètement dépendant du modèle.
> 
> Bref, au moins pour les 3000, il semble que la valeur soit adaptée
> correctement sur l'interface pour les versions NX-OS récentes :
> 
> "Note: When the Nexus 3000 is on code earlier than 7.0(3)I2(2a), check
> the MTU value with the show queueing interface ethernet x/x command.
> Nexus 3000 switches that run 7.0(3)I2(2a) and later show the MTU size on
> a per-port basis."
> 
> 
> A+
> 
> --
> Jérôme BERTHIER
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] OVNI reseau : blocage UDP < 12 bytes

[Thierry Chich]

Bonjour

C'est vrai sur pour tous les ports de destination ? Si c'est sur n'importe quel 
port, on peut dire que ça fait pas dans le détail.
Moi, j'ai eu des fragments de paquets IKE  qui était droppé par des 
box/routeurs. Des cisco et des livebox.

Thierry 

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jean-Yves Bernier
> Envoyé : vendredi 17 janvier 2020 11:49
> À : frnog@frnog.org
> Objet : [FRnOG] [TECH] OVNI reseau : blocage UDP < 12 bytes
> 
> Bonjour à tous.
> 
> Il n'était pas prévu que je m'inscrive car je ne suis pas administrateur 
> réseau.
> Je ne suis que simple client d'un fournisseur de services de divertissement
> par IP. Cependant, j'aimerais exceptionnellement solliciter votre avis sur un
> comportement réseau plus que bizarre. Vous voudrez bien m'excuser par
> avance si ma démarche est inappropriée.
> 
> Enoncé très simplement : les datagrammes de moins de 12 octets n'arrivent
> pas.
> 
> J'ai prévenu que c'était bizarre.
> 
> On imagine facilement que ça a toutes sortes de conséquences désopilantes
> qu'il n'est pas utile de détailler, même un Vendredi.
> 
> Je précise que ce comportement folklorique est apparu après une migration
> v4 -> v4 over v6 (dont je n'ai hélas pas le détail).
> 
> Ceci évoque-t-il pour vous l'intervention de quelque appliance machin-
> bidule qui déciderait, pour une raison qu'on peine à imaginer, de trounoiriser
> UDP en-dessous d'une certaine taille? Ou bien tout simplement une box
> programmée avec les pieds? Avez-vous déjà vu un tel OVNI réseau?
> 
> Si vous m'avez fait la faveur de me lire jusqu'ici, voici la signature du 
> crime.
> 
> 
> sender $ tcpdump port 1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on venet0, link-type LINUX_SLL (Linux
> cooked), capture size 262144 bytes
> 11:24:11.949241 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 30
> 11:24:12.049572 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 29
> 11:24:12.150040 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 28
> 11:24:12.250352 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 27
> 11:24:12.350644 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 26
> 11:24:12.450980 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 25
> 11:24:12.551282 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 24
> 11:24:12.651630 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 23
> 11:24:12.751996 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 22
> 11:24:12.852269 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 21
> 11:24:12.953079 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 20
> 11:24:13.053419 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 19
> 11:24:13.153727 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 18
> 11:24:13.254138 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 17
> 11:24:13.354433 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 16
> 11:24:13.454792 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 15
> 11:24:13.555280 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 14
> 11:24:13.655683 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 13
> 11:24:13.756006 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 12
> 11:24:13.870130 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 11
> 11:24:13.970534 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length
> 10
> 11:24:14.070936 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 9
> 11:24:14.171207 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 8
> 11:24:14.271474 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 7
> 11:24:14.371896 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 6
> 11:24:14.472283 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 5
> 11:24:14.572587 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 4
> 11:24:14.672875 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 3
> 11:24:14.773201 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 2
> 11:24:14.873548 IP bidule.43037 >
> 82-64-218-115.subs.proxad.net.1: UDP, length 1
> 
> receiver $ tcpdump -ni any port 1
> tcpdump: data link type PKTAP
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on any, link-type PKTAP (Packet Tap), capture size 65535 bytes
> 11:24:11.970078 IP 151.80.154.119.43037 > 82.64.218.115.1: UDP, length
> 30
> 11:24:12.070842 IP 151.80.154.119.43037 > 82.64.218.115.1: UDP, length
> 29
> 11:24:12.170810 IP 

RE: [FRnOG] [TECH] appel d'urgence

[Thierry Chich]

Oui, j'ai vu ça aussi. 

En tout cas, merci beaucoup pour votre aide. Ça m'éclaire beaucoup sur la 
démarche à suivre. 
Cela dit, à l'heure de la toip, je suis surpris que tout ça ne soit pas mieux 
intégré. 

Thierry 

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone
> Envoyé : vendredi 24 janvier 2020 09:26
> À : Adrien Gilbert 
> Cc : Julien Escario ; Liste FRnoG
> 
> Objet : Re: [FRnOG] [TECH] appel d'urgence
> 
> Tiens je tombe par hasard sur un effort gouvernemental pour simplifier la
> gestion des PDAAU et supprimer la gestion manuelle par les préfectures:
> 
> https://www.economie.gouv.fr/files/files/directions_services/bulletin-
> officiel/2018_pdf/boe_20180012__0003.pdf
>  officiel/2018_pdf/boe_20180012__0003.pdf>
> 
> > Le 24 janv. 2020 à 09:21, Adrien Gilbert  a écrit :
> >
> > Bonjour Julien,
> >
> > Pour le PFLAU, ce n'est pas une base de donnée, c'est un webservice
> > mis à la disposition des services d'urgence (en général intégré dans
> > leur logiciel de gestion d'appels) par l'APNF.
> > Lorsqu'un service d'urgence veut localiser un numéro, ils font appel à
> > ce webservice qui va dynamiquement rerouter la requête (toujours en
> > webservice) vers l'opérateur exploitant le numéro qui répond avec
> > l'adresse associée logiquement stockée dans son SI. L'APNF ne stocke
> > pas l'information dans une base.
> >
> > Cordialement / Regards,
> > 
> >  *Adrien GILBERT * *Directeur
> > Technique | CTO*
> >
> > +33177726610
> > adr...@unyc.io
> > unyc.io
> > 
> >
> >
> >
> >
> > Le ven. 24 janv. 2020 à 09:14, Julien Escario
> >  a écrit :
> >
> >> Le 23/01/2020 à 17:52, Eric Le Dortz a écrit :
> >>> Bonsoir,
> >>>
> >>> Les gros opérateurs et en particulier SFR ne font pas de
> >>> customisation
> >> sur les T2, seule l'adresse du site d'installation est prise en compte.
> >>> Si tu veux gérer les sorties urgence de sda de différentes zones
> >> géographiques, il faut passer par un trunk sip où tu declares à
> >> l'opérateur l'adresse géographique de chaque sda transportée. Tu peux
> >> aussi faire une transformation de numéro sur ton autocom, mais ça
> >> implique de connaître les sda des pompiers/police de chaque zone et
> >> de maintenir ça à jour (bref, je déconseille vivement).
> >>
> >> Ca se fait. Il faut contacter les préfs de chaque département et
> >> demander à être intégré dans la liste de diffusion des PDAAU. C'est
> >> un peu de boulot mais on observe (au doigt mouillé) moyenne deux
> >> modifications par an et par préf.
> >>
> >> En gros, c'est du boulot mais pas insurmontable non plus, ça dépend
> >> beaucoup des moyens que l'on veut se donner.
> >>
> >> Pas non plus la peine de s'occuper des départements dans lesquels on
> >> a pas d'install. Bien expliquer au client que sur de la VoIP, les
> >> téléphones sont rattachés à une zone géographique pour les numéros
> >> d'urgence et qu'en cas de déménagement, il faut qu'il prévienne.
> >>
> >> Par contre, le PFLAU, je découvre. Quelqu'un a un pointeur pour
> >> commencer à exporter des localisations client dans une interface
> >> quelconque ?
> >> Je vais demander à mon correspondant SDIS si ils l'utilisent pour
> >> essayer d'avoir des infos techniques.
> >>
> >> Julien
> >>
> >>
> >> ---
> >> 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/

[FRnOG] [TECH] appel d'urgence

[Thierry Chich]

Bonjour

 

Je suis désolé, je sais que c’est un peu une question récurrente, mais quand on 
fait transiter de la ToIP vers un T2 distant, comment fait-on pour transmettre 
aux services d’urgence l’adresse réelle ? Est-ce qu’il y a un organisme central 
auprès duquel on signale le mapping numéro/adresse  ? Est-ce que c’est 
l’opérateur de notre T2 auquel on peut l’indiquer ?

 

 

Cordialement

Thierry 


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

RE: [FRnOG] [TECH] appel d'urgence

[Thierry Chich]

En fait, je fais ressortir par un T2 qui est à 80 km du site appelant. De ce 
que tu me dis, il y aurait peut-être un moyen pour l'opérateur de faire une 
traduction par numéro SDA plus précise ? 


Thierry 
> -Message d'origine-
> De : David Ponzone 
> Envoyé : jeudi 23 janvier 2020 15:03
> À : Thierry Chich 
> Cc : Liste FRnoG 
> Objet : Re: [FRnOG] [TECH] appel d'urgence
> 
> Tu as fait un essai ?
> Quand tu sors l’appel d’urgence par le T2 avec un numéro appelant non local
> (non local au site du T2), l’opérateur t’envoie vers quel centre d’urgence ?
> Ca doit dépendre de l’opérateur du T2 mais dans le cas d’Orange, j’ai
> tendance (mais pas plus) à penser qu’is traduisent en dur par rapport au site
> géographique de livraison du T2, donc pas moyen de tricher.
> Sauf si tu es opérateur, auquel cas tu as la fameuse Liste, et tu traduis toi-
> même avant d’émettre l’appel vers le bon numéro (celui du lieu
> géographique de l’appelant SIP).
> 
> > Le 23 janv. 2020 à 14:50, Thierry Chich  a
> écrit :
> >
> > Bonjour
> >
> >
> >
> > Je suis désolé, je sais que c’est un peu une question récurrente, mais
> quand on fait transiter de la ToIP vers un T2 distant, comment fait-on pour
> transmettre aux services d’urgence l’adresse réelle ? Est-ce qu’il y a un
> organisme central auprès duquel on signale le mapping numéro/adresse  ?
> Est-ce que c’est l’opérateur de notre T2 auquel on peut l’indiquer ?
> >
> >
> >
> >
> >
> > Cordialement
> >
> > Thierry
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/



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

RE: [FRnOG] [TECH] vmware, firewall dmz

[Thierry Chich]

Bonjour

Ce n'est vraiment pas une bonne pratique d'avoir le firewall frontal en 
virtualisé. Pour 257 raisons, sécurité, découplage des fonctions, etc. Vraiment.

Si c'est gênant, il vaut encore mieux garder un bon firewall physique en 
frontal chargé des nat, du filtrage depuis internet et des accès de management 
(c'est mieux de le séparer, cela dit), et se contenter d'un interco avec 
derrière un firewall virtuel pour s'occuper de l'est-ouest. Ou de le faire 
faire par des fonction NSX (mais qui ont un coût).




> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jerome Lien
> Envoyé : lundi 11 mai 2020 15:21
> À : frnog-tech 
> Objet : [FRnOG] [TECH] vmware, firewall dmz
> 
> Bonjour à tous,
> 
> nous recherchons une méthode, solution pour isoler les vm's accessible
> depuis l'extérieurs. Etant une industrie nous avons plusieurs type de vm
> devant écouter du https, ftp, et d'autres protocoles plus ou moins fiable avec
> des languages/os plus ou moins à jours.
> Actuellement nous avons plusieurs dmz, avec des vlan's, le tout passant par
> un fortigate physique ... mais il faut avouer que remonter les vlan à chaque
> fois, fortigate..., switch, vswitch ... c'est plutôt fatiguant.
> Du coups, on réfléchi à monter un firewall en VM, par exemple un pfsense,
> opnsense  pour gérer ces mini dmz et n'avoir qu'un lien propre vers
> l’extérieur.
> 
> avez vous des retours sur ce type d'archi ? ou est ce complètement *** ? :-)
> 
> ä l'écoute de toutes proposition,
> jerome et merci d'avance
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] vmware, firewall dmz

[Thierry Chich]

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jean-Yves LENHOF
> Envoyé : jeudi 14 mai 2020 16:17
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] vmware, firewall dmz
> 
> Hello,
> 
> Intéressant tout cela et dans le cloud public, on fait comment pour le
> physique ?
> 
> Je pense que ce type de raisonnement devient de moins en moins vrai...
> 

Je ne pense pas, non

> Et admettons que tu soit un hébergeur, tu achètes un firewall pour chacun
> de tes clients ? Je pense qu'à un moment tu passes sur un modèle plus
> virtuel que physique, non ?
> 


Pas besoin. Tu mets ton propre firewall, et après, tu donnes accès à des 
firewalls éventuellement virtualisés à tes clients. 

> Cordialement,
> 
> 
> Le 14/05/2020 à 14:22, Adrien Rivas a écrit :
> > L'ANSSI a publié deux guides traitant du sujet de cette liste :
> >
> > L'exposition de ressources sur internet :
> > https://www.ssi.gouv.fr/uploads/2018/01/guide_preconisations-pare-feux
> > -zone-exposee-internet_anssi_pa_044_v1.pdf
> > La problématique des ressources réseau virtualisées :
> >
> https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Virtualisation_NoteTech_v1-
> > 1.pdf
> > (les risques sont traités P8)
> >
> > Concernant ce point *"Actuellement nous avons plusieurs dmz, avec des
> > vlan's, le tout passant par  un fortigate physique ... mais il faut
> > avouer que remonter les vlan à chaque fois, fortigate..., switch, 
> > vswitch
> ...
> > c'est plutôt fatiguant" *perso nous déployons de plus en plus des
> > Fortiswitch, managés par le Fortigate ils ont l'avantage de pouvoir
> > affecter visuellement les vlans directement sur le port de
> > destination, c'est assez bien fait et pratique à utiliser je trouve.
> > Autre avantage, quand tu sauvegardes la config du Fortigate, tu
> > sauvegardes par mégarde la config des switchs avec
> >
> > Le jeu. 14 mai 2020 à 14:01, Michael Hallgren  a écrit :
> >
> >> Moi également, je suis du même avis prudent (là où possible) pour la
> >> protection périmétrique.
> >>
> >> mh
> >>
> >> 14 mai 2020 12:52 "Benoît SERRA"  a écrit:
> >>
> >>> À mon avis, les failles récentes contredisent cela : une
> >>> compromission
> >> de l'hôte permet
> >>> potentiellement d'exposer toutes les Vm.
> >>>
> >>> Meme si ces failles sont remédiées, on reste exposé à la découverte
> >>> de
> >> nouvelles failles
> >>> équivalentes...
> >>>
> >>> C'est pour ça que le firewall est peut être le seul service que je
> >>> ne
> >> virtualiserai jamais en
> >>> production.
> >>>
> >>> 14 mai 2020 12:39:11 Olivier Tirat BYON
> >>>  >>> :
> >>>
>  A priori ce défaut est facilement contournable  avec un saine
>  gestion de
> 
>  l'isolation des réseaux.
> 
>  Le problème qui se pose ici est celui de la migration des
> 
>  infrastructures réseaux dans des environnements virtualisés.
> 
>  Je connais qu'une solution technologique qui fonctionne et qui
>  préserve
> 
>  l'existant mais je ne lui ferai pas de pub sur la liste.
> 
>  Si ca vous interesse contactez moi directement.
> 
>  Olivier
> 
>  Le 14/05/2020 à 12:18, Benoît SERRA a écrit :
> 
>  Le défaut majeur d'un firewall virtuel c'est la compromission de
>  l'hôte
> >> qui l'héberge.
>  ---
> 
>  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] vmware, firewall dmz

[Thierry Chich]

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Benoît SERRA
> Envoyé : jeudi 14 mai 2020 12:52
> À : Olivier Tirat BYON 
> Cc : frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] vmware, firewall dmz
> 
> À mon avis, les failles récentes contredisent cela : une compromission de
> l'hôte permet potentiellement d'exposer toutes les Vm.
> 

Une compromission de l'hôte, l'ESX ? Ben y a pas besoin de failles récente. 
C'est évident que si on a pris la main sur l'hôte, on a la main sur l'ensemble. 
Ce qui est plus discuté, c'est la possibilité de passer de VM à hote. Certaines 
choses indiquent que c'est possible, mais ça reste très compliqué. Cela dit, on 
est pas à l'abri d'une accélération hardware mal gaulée qui puisse un jour être 
exploitée pour remonter sur l'hôte.


> Meme si ces failles sont remédiées, on reste exposé à la découverte de
> nouvelles failles équivalentes...
> 
> C'est pour ça que le firewall est peut être le seul service que je ne
> virtualiserai jamais en production.

Tout en fait. En tout cas, le frontal.

Cordialement

> 
> 14 mai 2020 12:39:11 Olivier Tirat BYON :
> 
> >   A priori ce défaut est facilement contournable  avec un saine gestion 
> > de
> >
> > l'isolation des réseaux.
> >
> >
> >  Le problème qui se pose ici est celui de la migration des
> >
> > infrastructures réseaux dans des environnements virtualisés.
> >
> >
> >  Je connais qu'une solution technologique qui fonctionne et qui préserve
> >
> > l'existant mais je ne lui ferai pas de pub sur la liste.
> >
> >
> >  Si ca vous interesse contactez moi directement.
> >
> >
> >
> >  Olivier
> >
> >
> >
> >
> >
> >  Le 14/05/2020 à 12:18, Benoît SERRA a écrit :
> >
> >
> >
> >
> > >Le défaut majeur d'un firewall virtuel c'est la compromission de 
> > > l'hôte
> qui l'héberge.
> > >
> > >
> > >
> > >   ---
> > >
> > > 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] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Thierry Chich]

Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN ne 
se voient pas entre elles, ou partiellement ? On vient d’avoir le coup avec du 
jitsi. Le p2p, c’est bien joli, mais bon.

Thierry Chich

> Le 17 mars 2020 à 18:19, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
> De: "frnog" 
> 
>> Donc session timeout: Essaye en mettant session-timers=refuse dans la  
>> config d'un client qui génère cette erreur
> 
> J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça 
> ne fonctionne pas, ça coupe toujours après 32 secs.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Profitons bien de l'épidémie pour violer un peu la neutralité

[Thierry Chich]

Le CNED ? Pourquoi voudriez-vous qu’ils aient des éléments ?

Thierry 

> Le 16 mars 2020 à 14:35, Wallace  a écrit :
> 
> Pour ma part ce qui me révolte c'est que j'avais refusé Pronote et
> consors depuis toujours car ce sont des entreprises privées et qu'on
> nous a inscrit de force, du coup requête RGPD pour suppression des accès
> / données et lettre saignante aux chefs d'établissement qui se donnent
> le droit de divulguer nos coordonnées sans notre accord.
> ?
> Et là avec ce confinement des enfants, on nous laisse pas du tout le
> choix que de laisser nos données à ces entreprises...
> 
> Effectivement le CNED a déjà des éléments, c'est vraiment dommage de ne
> pas les utiliser.
> 
>> Le 16/03/2020 à 14:16, David Ponzone a écrit :
>> Dans le cas particulier de l'enseignement, je suis sidéré que l’Etat n’ait 
>> pas été capable de proposer une offre complète et cohérente pour tous les 
>> établissements scolaires (en utilisant bien sûr l’expérience du CNED entre 
>> autres). A cause de ce manquement, chaque école a choisi son acteur privé 
>> pour combler ce vide (Pronote, Ecole Directe, etc…), et la réalité c’est 
>> qu’aucun ne tient la route dans une telle situation.
>> Espérons que cela pousse l’Etat à revoir son implication dans ce domaine, ou 
>> plutôt sa non-implication. On ne peut pas tout sous-traiter.
>> 
 Le 16 mars 2020 à 14:07, Sebastien CHATEAU-DUTIER  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Le soucis viens toujours du "sous dimensionnement" des serveurs Web/BDD (ou 
>>> des grappes de serveurs...) bref rien de nouveau sur la planète.
>>> 
>>> Bonne journée.
>>> 
>>> Seb
>>> 
>>> Le 16/03/2020 à 13:28, Alarig Le Lay a écrit :
 Le souci ne vient toujours pas de la taille des tuyaux. Ils ont résisté
 à la coupe du monde des 11 glandus derrière un ballon, ils résisterons à
 ça.
 
 On lun. 16 mars 12:50:06 2020, Nico G wrote:
> Le core ça doit tenir sans problème. Certains lien edge peut être pas.
> Le peering vers Netflix ou Google c’est du privé et c’est largement 
> dimensionné. Le transit généraliste vers tel ou tel hébergeur c’est moins 
> sur. D’autant plus qu’Orange n’a pas le peering dans le sang.
> 
> Nicolas
> 
>> Le 16 mars 2020 à 12:30, Richard Klein  a écrit :
>> 
>> @David
>> La question est de savoir si la saturation est sur le cœur et si les
>> opérateurs et acteurs des télécoms seront tirer la leçon pour investir
>> Et si payer une fibre un bras et se retrouver avec des ralentissements
>> c'est les prochaines questions qui seront abordés par les clients...
>> 
>>> Le lun. 16 mars 2020 à 12:25, David Ponzone  a
>>> écrit :
>>> 
>>> J’ai pas bien compris le rapport entre ma fibre et les sites web de
>>> support scolaire des écoles….
>>> 
> Le 16 mars 2020 à 12:06, Richard Klein  a 
> écrit :
 Bonjour a tous depuis la maison pendant ma pause déjeuné.
 Je me fais l'avocat du diable...
 Question lorsque vous payez une fibre 500euros et lorsque vous payez 30
 euros en GP vos debits sont garantis pour la ligne GP ou Pro?
 :-)
 
 Richard
 
 Le lun. 16 mars 2020 à 11:44, GROS Jérôme  a écrit
>>> :
> Pour l'école primaire chez moi :
> https://beneylu.com/fr/beneylu-school-met-les-bouchees-doubles/
> Bon là, même le message d'alerte ne fonctionne plus.
> 
> On Mon, Mar 16, 2020 at 10:10:53AM +0100, David Ponzone wrote:
>> Des sources de quoi ?
>> Ben EcoleDirecte de mon fils: inutilisable à l’heure actuelle.
>> VieScolaire de ma fille: inutilisable
>> Kwyk dont se sert la prof de maths de mon fils: inutilisable toute à
> l’heure, ça a l’air d’aller un peu mieux là.
>> Paris Classe Numérique marchait pas ce matin (accès prof), mais ça
>>> semble
> s’améliorer.
>> Y a donc pas grand chose qui support les accès massifs et comme rien
>>> n’a
> été fait pour les étaler dans le temps...
>>> Le 16 mars 2020 à 10:03, Michel Guillou  a écrit 
>>> :
>>> 
>>> Le Mon, 16 Mar 2020 09:52:07 +0100, vous écrivîtes :
>>> 
 S’ils font ça, ils sont morts.
 Même certains profs comptent sur Youtube pour fournir le contenu 
 que
> le Ministère n’a pas.
 Je parle même pas des serveurs type EcoleDirect et autres, qui ont
> gentiment explosé ce matin.
>>> Tu as des sources là-dessus ? Ça m'intéresse...
>>> 
>>> Merci.
>>> 
>>> --
>>> Michel Guillou
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>> ---
>> Liste de diffusion du FRnOG
>> 

Re: [FRnOG] [TECH] Vérifier que le trafic IPsec est bien autorisé

[Thierry Chich]

J’ai eu beaucoup de soucis avec des problèmes de fragmentation sur les paquets 
isakmp trop grand. Comme c’est de l’UDP, toutes les astuces à base de 
bidouilles sur la MSS ne fonctionnent pas, et il faut espérer que le PMTUD 
fonctionne bien. Ça relève plus de la foi qu’autre chose. Et certaines livebox 
ou routeurs ont eu par moment des bugs et droppaient les fragments. 

Si les paquets isakmp sont petits, ça passe bien, mais dès  qu’on fait du 
certificat, ça peut être compliqué.

Thierry 

> Le 16 mars 2020 à 18:49, Guillaume Genty (Waycom)  a écrit 
> :
> 
> C'est marrant comme coïncidence ! J'ai le même problème de mon côté...
> 
> 
> Je viens de passer une bonne heure à débugger le client VPN IPSec d'un 
> administratif de chez nous, pour avoir fini par trouver que certains paquets 
> n'arrivent pas !
> 
> C'est justement du FTTH Orange grand public avec Livebox
> (J'ai testé avec un partage de connexion 4G, c'est monté tout de suite)
> 
> La phase 1 monte bien en NAT-T (UDP ports 500 puis 4500) mais impossible de 
> monter la phase 2.
> Une fois descendu dans le débug, les trames de setup SA de la phase 2 
> n'arrivent jamais en face, alors que les keepalive de la phase 1 passent sans 
> problème au même moment.
> Sauf que comme la première phase passe bien, aucun indicateur d'erreur sur 
> l'UI du client VPN qui indique juste que la connexion a réussi...
> 
> Franchement c'est tellement tordu comme problème, j'ai des doutes que ça soit 
> volontaire de la part d'Orange !
> 
> Quelqu'un d'autre a déjà eu ces symptômes ?
> 
> -- 
> Guillaume Genty | WAYCOM
> Directeur Innovation et Expertise
> 1 quai Marcel Dassault | 92150 Suresnes, FRANCE
> T. : +33 (0)1 41 44 83 00 | F. : +33 (0)1 41 44 00 22
> gge...@waycom.net | www.waycom.net
> 
>> Le 16/03/2020 à 18:09, Jonathan Leroy - Inikup via frnog a écrit :
>>> Le lun. 16 mars 2020 à 18:00, David Ponzone  a 
>>> écrit :
>>> Ben tu prends une trace sur tes ports egress.
>> Ah oui au fait, le routeur est une Livebox. :D
>> Je cherchais une solution plus simple que de monter un tunnel IPsec
>> moi-même juste pour vérifier que le trafic passe bien.
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Profitons bien de l'épidémie pour violer un peu la neutralité

[Thierry Chich]

Il y’a juste des questions d’échelle. Je ne connais pas le nombre exact des 
élèves inscrits au CNED en temps ordinaire, mais les élèves en primaire et 
secondaire, ça doit bien faire 10 millions. C’est pas du tout du tout les mêmes 
échelles. Il y’a pas loin de 100 d’enseignants. 
On ne se rend pas bien compte, mais l’éducation nationale, c’est vraiment très 
gros. 

Thierry

> Le 18 mars 2020 à 08:41, Wallace  a écrit :
> 
> Ils ont déjà tout ce qu'il faut (organisation, infra) pour le travail
> des élèves à distance, pourquoi réinventer la roue ailleurs.
> 
> Il aurait juste suffit de basculer des professeurs du IRL vers le CNED
> pour soutenir la partie pédagogique de suivi et de correction.
> 
> 
> Email Signature
>> Le 17/03/2020 à 18:59, Thierry Chich a écrit :
>> Le CNED ? Pourquoi voudriez-vous qu’ils aient des éléments ?
>> 
>> Thierry 
>> 
>>>> Le 16 mars 2020 à 14:35, Wallace  a écrit :
>>> 
>>> Pour ma part ce qui me révolte c'est que j'avais refusé Pronote et
>>> consors depuis toujours car ce sont des entreprises privées et qu'on
>>> nous a inscrit de force, du coup requête RGPD pour suppression des accès
>>> / données et lettre saignante aux chefs d'établissement qui se donnent
>>> le droit de divulguer nos coordonnées sans notre accord.
>>> ?
>>> Et là avec ce confinement des enfants, on nous laisse pas du tout le
>>> choix que de laisser nos données à ces entreprises...
>>> 
>>> Effectivement le CNED a déjà des éléments, c'est vraiment dommage de ne
>>> pas les utiliser.
>>> 
>>>> Le 16/03/2020 à 14:16, David Ponzone a écrit :
>>>> Dans le cas particulier de l'enseignement, je suis sidéré que l’Etat n’ait 
>>>> pas été capable de proposer une offre complète et cohérente pour tous les 
>>>> établissements scolaires (en utilisant bien sûr l’expérience du CNED entre 
>>>> autres). A cause de ce manquement, chaque école a choisi son acteur privé 
>>>> pour combler ce vide (Pronote, Ecole Directe, etc…), et la réalité c’est 
>>>> qu’aucun ne tient la route dans une telle situation.
>>>> Espérons que cela pousse l’Etat à revoir son implication dans ce domaine, 
>>>> ou plutôt sa non-implication. On ne peut pas tout sous-traiter.
>>>> 
>>>>>> Le 16 mars 2020 à 14:07, Sebastien CHATEAU-DUTIER  a écrit :
>>>>> Bonjour,
>>>>> 
>>>>> Le soucis viens toujours du "sous dimensionnement" des serveurs Web/BDD 
>>>>> (ou des grappes de serveurs...) bref rien de nouveau sur la planète.
>>>>> 
>>>>> Bonne journée.
>>>>> 
>>>>> Seb
>>>>> 
>>>>> Le 16/03/2020 à 13:28, Alarig Le Lay a écrit :
>>>>>> Le souci ne vient toujours pas de la taille des tuyaux. Ils ont résisté
>>>>>> à la coupe du monde des 11 glandus derrière un ballon, ils résisterons à
>>>>>> ça.
>>>>>> 
>>>>>> On lun. 16 mars 12:50:06 2020, Nico G wrote:
>>>>>>> Le core ça doit tenir sans problème. Certains lien edge peut être pas.
>>>>>>> Le peering vers Netflix ou Google c’est du privé et c’est largement 
>>>>>>> dimensionné. Le transit généraliste vers tel ou tel hébergeur c’est 
>>>>>>> moins sur. D’autant plus qu’Orange n’a pas le peering dans le sang.
>>>>>>> 
>>>>>>> Nicolas
>>>>>>> 
>>>>>>>> Le 16 mars 2020 à 12:30, Richard Klein  a écrit 
>>>>>>>> :
>>>>>>>> 
>>>>>>>> @David
>>>>>>>> La question est de savoir si la saturation est sur le cœur et si les
>>>>>>>> opérateurs et acteurs des télécoms seront tirer la leçon pour investir
>>>>>>>> Et si payer une fibre un bras et se retrouver avec des ralentissements
>>>>>>>> c'est les prochaines questions qui seront abordés par les clients...
>>>>>>>> 
>>>>>>>>> Le lun. 16 mars 2020 à 12:25, David Ponzone  
>>>>>>>>> a
>>>>>>>>> écrit :
>>>>>>>>> 
>>>>>>>>> J’ai pas bien compris le rapport entre ma fibre et les sites web de
>>>>>>>>> support scolaire des écoles….
>>>>>>>>> 
>>>>>>>>>>> Le 16 mars 2020 à 12:06, Richard Klein  a 
>>>>

RE: [FRnOG] Re: [TECH] NAT et IP hors RFC-1918

[Thierry Chich]

Bonjour

Il y a quelque chose qui m'échappe peut-être, mais normalement, on devrait 
avoir besoin des 2 procédés en même temps. Admettons que j'ai un réseau A qui 
veut joindre un réseau B partageant exactement le même subnet. Sans double NAT, 
ça ne peut pas fonctionner. Et sans NAT-DNS non plus.
Pour rendre cela plus maintenable, il y a des fonctionnalités sympathiques 
disponibles soient dans les routeurs cisco, soit dans iptables qui permettent 
de nater en une seul ligne de commande tout un réseau entier en faisant un 
décalage d'octet. 192.168.0.0/16 est natté sur 172.16.0.0/16 par exemple.  La 
machine 192.168.210.12 deviendra 172.16.210.12. En le faisant deux fois de 
suite, on peut tout à fait faire mapper des plans d'adressage recouvrant.
Et comme dnsmasq a une fonction assez similaire pour transformer en vol les 
résolutions DNS, ça peut constituer une solution pour une situation qui n'est 
évidemment pas idéale et ralalalalal pourquoi on ne passe pas à IPv6, je vous 
le demande.
Je précise que si j'ai bien testé la solution à base de iptables et que j'ai vu 
fonctionner le système avec des ASR cisco, en revanche, je n'ai pas implanté le 
système avec DNSmasq, donc je ne peux pas vraiment garantir que c'est 
opérationnel.

Cordialement
Thierry

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de A Gaillard
Envoyé : mercredi 23 septembre 2020 17:41
À : Stephane Bortzmeyer 
Cc : frnog-tech 
Objet : [FRnOG] Re: [TECH] NAT et IP hors RFC-1918

Exact pour vos 2 remarques :

   1. En effet on ne pourra jamais régler le problème d'overlap pour ces
   machines, mais j'aimerais bien trouver une solution pour que les machines
   du réseau adressées normalement ne voient pas cet overlap : Ce n'est pas
   l'objectif du DNS-NAT in fine ?
   2. Tu as raison Stéphane, je retire la solution de double NAT de la
   liste pour éviter de devoir longer les murs dans les prochains jours !


Adrien.

Le mer. 23 sept. 2020 à 17:20, Stephane Bortzmeyer  a écrit :

> On Wed, Sep 23, 2020 at 04:59:35PM +0200,  A Gaillard 
>  wrote  a message of 49 lines which said:
>
> >- Trouver une solution à base de double NAT
>
> Attention, la personne qui viendra maintenir celà dans N années va 
> vous maudire, et inventer le voyage dans le temps pour revenir dans le 
> passé vous agresser.
>

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


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

[FRnOG] [TECH] Augmentation des latences

[Thierry Chich]

Bonjour

 

Je ne sais pas si c’est représentatif, mais je pingue des box ADSL/Fibre de 
quelques opérateurs, et j’ai observé un truc un peu curieux qui a commencé avec 
le confinement. Chez Bouygues et Free. J’ai observé un changement de latence 
très sensible (de 18 à 25 ms pour bouygues, de 15 à 30 ms, en deux phases pour 
Free). Je ne vois pas ça pour de l’Orange pro, ni sur aucun autre opérateur. La 
concomitance avec le confinement est troublante.

 

Ça peut évidemment être local. Est-ce que certains d’entre vous ont observé des 
choses pareilles, et le cas échéant, est-ce que vous en connaissez la raison ? 
Est-ce une opération qui vise à diminuer les débits TCP ? Des mesures 
préventives contre les DoS ?

 

Thierry


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

Re: [MISC] Re: [FRnOG] Accès compte HS

[Thierry Chich]

> Le 7 août 2020 à 14:06, Jérôme Nicolle  a écrit :
> 
> Louis,
> 
>> Le 07/08/2020 à 13:56, Louis a écrit :
>> pas sûr qu'une application sache détecter ça
> 
> Si si, ils peuvent. Et ils le font.
> 
> Du coup, impossible d'utiliser une néobanque sans être soumis à Google
> ou Apple.
> 
> Toutes les applis que j'ai pu tester refusent de tourner sur mon
> LineageOS dégooglisé, même avec MicroG. C'est totalement débile et
> toxique pour la sécurité de leurs clients, mais c'est comme ça.
> 

Bonjour 

Je comprends assez mal cette opinion. Il me semble pourtant assez logique de 
refuser des os qui sont notoirement fragilisés pour effectuer des opérations 
critiques. Si l’argument repose sur les quelques personnes suffisamment 
aguerries pour avoir des téléphones rootés/jailbreakés sans compromettre la 
sécurité, je trouve ça assez faible. On ne compte plus les « geeks » qui ont un 
ssh ouvert avec le mot de passe par défaut. Et qui installent des applis dont 
le seul but réel est de prendre  la main sur leur mobile, sous couvert de « 
Adblock généralisé ».

Thierry Chich

> -- 
> Jérôme Nicolle
> +33 6 19 31 27 14


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

Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Thierry Chich]

Je confirme que c’est dangereux. Je l’ai eu fait, et ça a très bien marché. Et 
je l’ai eu refait, et ça a bien foiré. Pourtant, du strict point de vue 802.1q, 
c’est dans les clous. Mais on est jamais à l’abri d’un STP qui fonctionne pas 
comme on le pense (et dieu sait que c’est quasiment une caractéristique du STP 
- ne pas fonctionner comme on pense), ou d’un reparametrage innocent qui va 
tout exploser. Le fait est que jamais je ne tenterais cette opération à 
distance, sans avoir le switch sous la main. 
C’est un signe que c’est pas hyper sécurisé comme opération.


Thierry 

> Le 9 août 2020 à 22:17, Michel Py  a 
> écrit :
> 
> 
>>> Michel Py a écrit :
>>> C'est super dangereux. Avec un 3750X çà peut marcher, mais il y a plein de 
>>> modèles
>> de switch qui vont péter les plombs avec cette config.
> 
>> Sébastien 65 a écrit :
>> Avant de me lancer j'ai quand même pris le temps de fouiller sur Google et
>> il s'avère que cette technique est "couramment" utilisée. Pour le même 
>> besoin,
>> j'ai vu ça sur du Cisco 3750,3550, HPE 5800
> 
> Ce qui ne veut pas dire que c'est robuste ou sain. STP, c'est facile à 
> planter; tu fragilises la situation. Au moindre problème ou bug, le cable 
> entre 2 ports du même switch, comme c'est pas une config courante, çà va 
> devenir un paratonnerre à emmerdes, surtout en cas d'autres problèmes ou de 
> reboot.
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Re: DNS slave veut devenir master

[Thierry Chich]

Vous remercierez bien de ma part cet auteur pour sa grande contribution à 
l’antiracisme. Je ne doute pas que ce soit une grande avancée pour l’humanité 
en général.
Je vais d’ailleurs y contribuer en passant mes serveurs PowerDNS en mode NATIVE 
immédiatement.
Thierry


> Le 17 juin 2020 à 08:00, Remi Desgrange  a 
> écrit :
> 
> Je vous sens d'humeur joyeuse (et trolleuse) sur ce thread, mais je sais 
> qu'il y a aussi ici des gens qui aime bien comprendre. Je pense que ce thread 
> de J.Pettazzoni donne des clés intéréssantes : 
> https://twitter.com/jpetazzo/status/1272785145804861441 (d'ailleurs si on 
> pouvait arrêter les thread twitter et refaire des _putains_ de blog commen 
> 2008 ce serait cool).
> 
> Cordialement/Best Regards, Rémi Desgrange
> 
>> On Jun 16 2020, at 3:46 pm, Pierre DOLIDON  wrote:
>>> Le 16/06/2020 à 10:47, Dominique Rousseau a écrit :
>>> Le Mon, Jun 15, 2020 at 06:56:09PM +0200, Kavé Salamatian 
>>> [kave.salamat...@univ-savoie.fr] a écrit:
> Le 15 juin 2020 à 18:37, Kitetoa @ Kitetoa.com  a 
> écrit :
> 
> Et que dire du génocidaire killall -9 ?
 Ca c???est un meurtre.
>>> Un meutre en série, doublé d'un suicide, écrit comme ça.
>>> 
 Un génocide c???est « sudo rm -rf /*" :-).
>>> Pas d'accord, ça ne tue pas les processus, ça.
>>> 
>>> 
>> Et personne ne s'offusque du terme horriblement grossophobe "Big Data" ?
>> 
>> 
>> ---
>> 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] remplacement stack réseau StoneSoft

[Thierry Chich]

Bonjour

Il y a eu des progrès  significatifs chez stonesoft/forcepoint, et 
notamment, enfin, une console web, qui au regard de la complexité, 
fonctionne très bien. Autre point de nouveauté, la possibilité de 
virtualiser des firewalls sur une  appliance. Et il s'agit d'une vraie 
virtualisation, pas des vdom de chez fortigate.


Ils ont aussi intégré une dimension sd-wan, qu'on peut évidemment 
critiquer, mais qui peut rendre des services.


J'avoue qu'ils m'ont beaucoup inquiété avec la série de rachat, mais là, 
on a l’impression que c'est actif chez eux.


Pour ce qui est de la fiabilité, un intégrateur a surement une meilleure 
vue qu’un client.



A+

Le 23/06/2020 à 09:59, x.r...@sipleo.com a écrit :

Bonjour à tous,

  


J’aurais besoin d’avis pour le remplacement d’une stack réseau a ce jour
elle est en StoneSoft.

De l’époque où c’était une société autonome (avant rachat successif ...)

  


Et on est très content du produit mais maintenant très vieillissant.

N’ayant pas fait de veille depuis leur rachat par Forcepoint, le passage par
McAfee-Intel nous avait dégouté.

  


Quelqu’un serait client/utilisateur de Forcepoint pour nous faire un REX ?

S’ils ont pu rattraper les Grosses Co…. Faite juste avant eux ce serait
peut-être pas mal.

  


Notre besoin, c’est d’avoir quelques choses qui puisse gère le routage assez
simplement mais de manières complète.

Le point fort de StoneSoft c’est justement cela une console centrale (mais
Java :( )

L’utilisation de variables dans la programmation c’est vraiment pratique.

Le cluster actif/actif (jusqu’à 7 nœuds)

Du routage IP avec vraiment des configurations de NAT un peu folle par
exemples.

La partie sécurité n’est pas notre priorité mais bienvenue et complémentaire
car on utilise d’autres UTM en périphérie (deux marques moteurs différents
c’est mieux :)

Pour les débits on n’est pas sur des trucs déments (quelques Gigabit/s) mais
on cherche une latence au plus bas.

  


On ne veut pas de Cisco ou Juniper

Donc on cherche quelques choses qui serait aussi innovant que lorsqu’on a
trouvé StoneSoft une vraie pépite pour l’époque.

  


On pensait à :

6Wind (Français, StoneSoft avait leur dev en Sophia Antipolis) déjà cité ici
quelques fois

Mellanox

Arista

Sans se limiter

  


On a vraiment besoin d’une console de supervision et de débug real-time.

Et aussi un changement de configuration sans coupure des sessions évidement
avec un rollback facile.

  


Merci et bon business à tous

  

  

  



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



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

[FRnOG] RE: [TECH] DNS slave veut devenir master

[Thierry Chich]

> -Message d'origine-
> De : 'Stephane Bortzmeyer' 
> Envoyé : vendredi 12 juin 2020 17:15
> À : Thierry Chich 
> Cc : 'Nico CARTRON' ; 'Stephane Bortzmeyer'
> ; 'Guillaume Tournat' ; frnog-
> t...@frnog.org
> Objet : Re: [TECH] DNS slave veut devenir master
> 
> On Thu, Jun 11, 2020 at 02:00:45PM +0200,  Thierry Chich  clermont.fr> wrote  a message of 72 lines which said:
> 
> > Au passage, j'ai une question sur laquelle je n'arrive pas à avoir une
> > réponse très claire. Le MNAME dans le SOA, ça a un rôle vraiment ?
> 
> Il y a des versions de Windows qui essaient de mettre à jour le DNS et qui
> écrivent au nom cité dans le SOA. Il est donc souvent intéressant d'y mettre
> une machine évier (sinkhole).

Ok

> > Parce qu'on a clairement pas vraiment l'impression. Un serveur
> > peut-être master, faire des notify et recevoir des demandes d'update
> > sans être le MNAME du SOA, pour ce que j'en vois.
> 
> Oui, de même qu'on peut appeler www une machine qui n'est pas serveur
> Web, et faire une "lame delegation" en mettant dans les enregistrements NS
> une machine qui n'est pas au courant.
> 
> Le DNS est juste une base de données, il ne connait pas la vérité, il sert les
> données qu'on lui demande de servir.

Oui, ça, je vois bien. Mais parfois, les données sont utilisées pour les 
processus du DNS lui-même, comme pour le notify par exemple. Ca rend la 
situation un peu confuse de mon point de vue.

En tout cas, merci pour l'éclaircissement. J'avais un doute.

Thierry


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

[FRnOG] [TECH] DNS slave veut devenir master

[Thierry Chich]

Bonjour

 

Pour des raisons un peu obscures de gestion des enregistrements DNS, j’aurais 
besoin qu’un slave devienne master. Pour être clair, qu’il reçoive sa base d’un 
master quelque part avec les mécanismes natifs (notify et axfr), mais qu’il 
devienne master pour d’autres slaves. J’ai bien une technique, mais 
quoiqu’assez simple, je ne la trouve pas très élégante (je fais deux instances 
pdns l’une slave et l’autre master qui partagent un même fichier bind) . 

 

Est-ce que vous voyez une technique plus élégante pour se faire, de préférence 
en utilisant powerdns ?

 

Cordialement

 

Thierry 


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

RE: [FRnOG] Re: [TECH] DNS slave veut devenir master

[Thierry Chich]

Hello

Je viens de comprendre que l'essentiel de mon problème tenait à un disable-axfr 
qui avait été décommenté.
Bref.
Merci de m'avoir empêché de partir dans une solution malpropre qui n'avait pas 
de raison d'être. 

Au passage, j'ai une question sur laquelle je n'arrive pas à avoir une réponse 
très claire. Le MNAME dans le SOA, ça a un rôle vraiment ? Parce qu'on a 
clairement pas vraiment l'impression. Un serveur peut-être master, faire des 
notify et recevoir des demandes d'update sans être le MNAME du SOA, pour ce que 
j'en vois.

Thierry 

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Nico
> CARTRON
> Envoyé : mercredi 10 juin 2020 10:33
> À : Stephane Bortzmeyer 
> Cc : Guillaume Tournat ; Thierry Chich
> ; frnog-t...@frnog.org
> Objet : Re: [FRnOG] Re: [TECH] DNS slave veut devenir master
> 
> On 10-Jun-2020 09:50 CEST,  wrote:
> 
> > On Tue, Jun 09, 2020 at 06:21:16PM +0200,  Guillaume Tournat via frnog
> >  wrote  a message of 45 lines which said:
> >
> > > Ensuite, sur les slaves de niveau 2, tu indiques qu'ils répliquent
> > > du slave intermédiaire.
> > >
> > > Ils s'en foutent de savoir ta config réelle. Ils s'adressent à un
> > > serveur faisant autorité.
> >
> > Tout à fait. Avec BIND ou NSD, c'est certainement la bonne solution.
> > Mais je ne sais pas si ça marche avec PowerDNS, peut-être qu'un
> > serveur faisant autorité ne peut être que complètement maître ou
> > complètement esclave ?
> 
> Bonne question - je n'ai pas testé, mais je ne vois pas de raison pour 
> laquelle
> PowerDNS Authoritative ne pourrait pas être en même temps maître et
> esclave.
> 
> Je viens de tester sur ma conf à la maison, en mettant:
> 
> ```
> master
> slave
> ```
> 
> et en relançant, ça fonctionne - pas testé l'ajout d'une zone esclave, mais ça
> devrait fonctionner.
> 
> --
> Nico
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

[Thierry Chich]

Le problème vient d'être réglé chez moi. 
Ouf.

Thierry CHICH
Adjoint RSSI académique
V12 - Sécurité des Systèmes d'Information
Pôle réseaux et hébergement
Direction des Systèmes d'Information
RECTORAT - 3 avenue Vercingétorix - 63033 Clermont-Ferrand Cedex
04 73 99 30 54

thierry.chich@acclermont.fr  dsirese...@ac-clermont.fr
www.ac-clermont.fr



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : jeudi 3 décembre 2020 14:23
À : fbsdoui...@free.fr
Cc : Thierry Chich ; frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

J’ai eu confirmation de Bouygues: incident général chez eux, mais je ne connais 
pas le périmètre exact.
J’ai plusieurs FTTH qui perdent des paquets (10% au moins).

> Le 3 déc. 2020 à 14:18, fbsdoui...@free.fr a écrit :
> 
> 
> bonjour,
> 
> Je n'ai pas de soucis pour toucher des sites des RENATER depuis 
> BOUYGUES par contre c'est presque impossible de toucher OVH-RBX depuis 
> BOUYGUES avec 70% de pertes !!
> Je pense que le soucis est plutôt chez BOUYGUES .
> 


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


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

RE: [FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

[Thierry Chich]

Oui, c'est que les utilisateurs Bouygues à première vue. En ces temps de 
télétravail intensif, c'est quand même très ennuyeux tous ces routeurs qui ne 
répondent pas au ping. C'est nettement plus compliqué d'avoir une idée précise 
de l'endroit où se situe précisément le problème. 

Encore que là, ça se precise, c'est bien chez Bouygues. Je perds 20% en pingant 
62.34.2.86 (qui est le seul routeur pingable sur la chaine).

Thierry 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Alarig Le 
Lay
Envoyé : jeudi 3 décembre 2020 12:11
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

En tous cas ça ne semble pas être lié à renater, je les touche aussi via 
equinix-ix mais je n’ai aucun loss.

On Thu 03 Dec 2020 12:04:25 GMT, Thierry Chich wrote:
> Clermont-Ferrand. Mais j'ai l'impression que ca remonte assez haut chez eux. 
> 
> Thierry
> 
> -Message d'origine-
> De : David Ponzone  Envoyé : jeudi 3 décembre 
> 2020 11:51 À : Thierry Chich  Cc : 
> frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Pertes de paquets 
> Bouygues-RENATER
> 
> Rigolo et peut-être sans rapport mais peut-être pas: j’ai des pertes massives 
> sur un FTTH Bouygues en collecte (mais pas tous).
> C’est localisé géographiquement de ton côté (la source) ?
> 
> > Le 3 déc. 2020 à 11:19, Thierry Chich  a 
> > écrit :
> > 
> > Bonjour
> > 
> > 
> > 
> > Des utilisateurs – dont moi - qui sont chez Bouygues éprouvent les 
> > plus grands peines à se connecter sur divers sites RENATER.  Pertes 
> > d’environ 15%.
> > 
> > A première vue, ça semble être au niveau d’equinix.
> > 
> > Est-ce que ça parle à quelqu’un ?
> > 
> > 
> > 
> > 
> > Thierry
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ---
> > 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] Pertes de paquets Bouygues-RENATER

[Thierry Chich]

Clermont-Ferrand. Mais j'ai l'impression que ca remonte assez haut chez eux. 

Thierry 

-Message d'origine-
De : David Ponzone  
Envoyé : jeudi 3 décembre 2020 11:51
À : Thierry Chich 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

Rigolo et peut-être sans rapport mais peut-être pas: j’ai des pertes massives 
sur un FTTH Bouygues en collecte (mais pas tous).
C’est localisé géographiquement de ton côté (la source) ?

> Le 3 déc. 2020 à 11:19, Thierry Chich  a écrit :
> 
> Bonjour
> 
> 
> 
> Des utilisateurs – dont moi - qui sont chez Bouygues éprouvent les 
> plus grands peines à se connecter sur divers sites RENATER.  Pertes 
> d’environ 15%.
> 
> A première vue, ça semble être au niveau d’equinix.
> 
> Est-ce que ça parle à quelqu’un ?
> 
> 
> 
> 
> Thierry
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



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

[FRnOG] [TECH] Pertes de paquets Bouygues-RENATER

[Thierry Chich]

Bonjour

 

Des utilisateurs – dont moi - qui sont chez Bouygues éprouvent les plus
grands peines à se connecter sur divers sites RENATER.  Pertes d’environ
15%.

A première vue, ça semble être au niveau d’equinix.

Est-ce que ça parle à quelqu’un ?

 


Thierry


 

 

 


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

RE: [FRnOG] [TECH] lien de transit SFR

[Thierry Chich]

Bonjour

C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y 
avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le 
débit atteignable en tcp. 
J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre 
politique de firewalling et offloading des cartes réseaux. Le débit passait de  
70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur 
certaines version de redhat.

Tout ça pour dire que ce genre de constat dépend parfois de paramètres très 
complexes à identifier

Thierry CHICH

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Olivier 
Tirat BYON
Envoyé : vendredi 18 décembre 2020 12:25
À : Nicolas Parpandet ; frnog-tech 
Objet : Re: [FRnOG] [TECH] lien de transit SFR

Bonjour

Bon différence majeur entre udp et tcp... l'aquittement des paquets
(TCP ACK).

On peut tester un upload indépendament du download ent UDP mais pas du tout en 
TCP.

Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le 
tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP 
RETRANSMIT

Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut 
atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas 
venir du lien. Après tester des performances réelles d'un transit c'est pas 
facile car ca dépend aussi de l'autre extrémité;)

Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>
> Bonjour,
>
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
> que cela soit lié au hasard me semble faible...)
>
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
>
> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, 
> et cela n'avance pas !
>
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
> de notre côté, il me semble que c'est bien en face le soucis ..., il peut 
> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet !
>
> Merci, A+
>
> Nicolas
>
>
>
> ---
> 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/