Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Thierry Chich]

Bonjour


Moi je ferais quand même une capture sur un qui qui marche et un qui 
marche pas. Le coup de l'isakmp fragmenté, je l'ai eu aussi. Pas avec du 
forti en revanche. Le certif était gros, le paquet isakmp passait pas en 
1500 octets, et une maj d'un ios cisco avait décidé qu'il fallait 
droppé. Alors oui, la phase 1 est sensé fonctionner, mais bon.



Le 02/05/2024 à 20:53, Philippe ASTIER via frnog a écrit :

Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé ce 
qui se passe en wifi vs 4G/5G Orange.

Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
négociation a l’air vraiment identique.
Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un truc 
qui m’échappe.

Mais bon sang, qu’est-ce que ça cause ces logs !….

Le 2 mai 2024 à 19:30, David Ponzone  a écrit :

Vincent,

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!

Philippe,

Tu vas devoir entrer dans le monde du debug Forti :)

David

Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a écrit :

On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
...

- sur la partie « split-tuneling », je ne vois pas trop le rapport.

Aucun, c'est la description du bug de David en SSL qui y ressemble

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.

C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
(uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
C'est en tout cas ce que je constate.
Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.

Vincent.


Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit :
On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
n’est pas dispo en IPv6.
Je ne connais pas fortinet, mais la description ressemble a un problème de 
split tunneling.
Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
« A good IPv6 is a disabled one ».
Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
IPv6, lui, fonctionne correctement.
Vincent.
...
---
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/

--

Thierry CHICH

x...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>

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

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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

[Thierry Chich]

Bonjour

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :

Bonjour à tous,

Membre de FDN j'ai déjà posé cette question sur une liste sympa 
interne et il m'a été conseillé de venir poser ma question ici (merci 
tout de même !).


Voici le problème que je n'arrive pas à résoudre :
J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à 
la carte mère) qui ont été installées dans un chassis avec d'autres 
que j'avais déjà.
Le panneau de contrôle du châssis me permet de faire des power on/off 
et récupérer les adresses MAC des cartes Ethernet et IPMI.
J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient 
pas d'adresse au serveur DHCP sur le réseau : ces cartes ont été 
configurées avec une adresse IP fixe dans un VLAN au pif (== que je ne 
connais pas)

Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).

Je m'en suis sorti, à distance et avec de la chance, car les lames 
tentent de booter en PXE avant d'essayer leur disque. J'ai donc 
configurer le serveur PXE pour leur envoyer une image de dépannage sur 
laquelle elles ont booté et j'ai pu faire un "ipmitool lan set 1 vlan 
id off". Dans la seconde les cartes IPMI obtiennent leur adresse IP.


Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient 
pas à démarrer (soit elle boot sur son disque interne automatiquement 
et se retrouve donc avec une adresse IP fixe que je ne connais pas, 
soit elle joue aux dames, soit elle est coincée au boot dans le Bios 
ou autre, soit la carte mère est tout simplement morte ).
Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par 
la carte IPMI (pas de port pour brancher un écran et encore moins un 
clavier).


La lame est connectée (via le switch du chassis qui ne fait que 
transmettre les paquets sans toucher aux ID vlan) au port Gi1/0/11 
d'un Cisco, et le serveur DHCP sur le port Gi1/0/6.
Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux 
switchs) sont dans le vlan 1, les 4 derniers du premier switch 
(Gi1/0/[21-24]) sont dans le vlan 2. Les deux vlans ne communiquent 
pas, il y a juste une machine qui a une patte sur ce vlan 1 privé et 
l'autre sur un réseau auquel j'ai accès à distance.


Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI 
et serveur DHCP se causent pour que la première ait une adresse IP et 
que du deuxième je parvienne à lancer un ipmitool (je connais user et 
mot de passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau)


Comme cela a été dit, le plus simple, c'est d'écouter sur le port avec 
le bon vieux tcpdump -e. Soit directement - mais là tu ne peux pas 
visiblement, soit en utilisant du port monitorirng pour renvoyer tout ce 
qui est émis sur le port sur lequel le ipmi est branché vers un autre 
port (là où tu as un serveur pour écouter).


- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1
Ben soit je comprends pas, soit c'est access vlan 1, mais c'est à coté 
du sujet.

- tout paquet à destination de la MAC se voit attribuer le vlan XXX
Ca peut se faire sur le switch grace aux systèmes mac-vlan , mais ça me 
semble être un contresens. Ton problème, c'est qu'un paquet est émis 
depuis ton ipmi avec un id de vlan 802.1Q, et tu ne peux rien y faire, 
par définition. Ce qu'il faudrait, c'est un système qui détaggue 
automatiquement ton paquet, mais ça, je ne vois pas comment le faire 
simplement.



p://www.frnog.org/

--

Thierry





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

Re: [FRnOG] [MISC] Meta HS quelqu'un a de l'info ?

[Thierry Chich]

Ils diront: t'as vu les gamins de nos jours, c'est vraiment du n'importe 
quoi, nous on était pas comme ça.


Le 06/03/2024 à 10:44, Toussaint OTTAVI a écrit :



Le 06/03/2024 à 09:40, David Ponzone a écrit :

En tout cas, c’est toujours assez inquiétant de voir ces millions de
gens qui ont à peu près le même rapport avec FB qu’un zombie avec son
Fentanyl.


Et c'est encore plus inquiétant pour le futur ! Je suis dans un petit 
village de montagne. L'an dernier, suite à un coup de vent, 
l'alimentation EDF est tombée, pendant une journée. Donc, plus de WiFi 
ni de 4G. C'était pendant les vacances scolaires. Les gamins erraient 
dans les rues, avec les smartphones à la main, en cherchant du réseau 
tels des sourciers avec leurs baguettes : "Mon dieu, ya plus Insta, 
mais comment on va faiire ?"


Et ce sont ces mêmes gamins qui seront aux manettes dans 10 ou 20 ans. 
Comment tu as dit ? "Inquiétant" ?

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

--


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

Re: [FRnOG] [MISC] La belle boite de Pandore....

[Thierry Chich]

Le 02/02/2024 à 09:19, David Ponzone a écrit :

Plus sérieusement, je suis étonné qu’en 2024, il n’y ait pas une techno qui 
permette d’héberger des données sensibles « agnostiquement » dans plusieurs 
clouds, de manière redondante (type N+4 au moins), cryptée localement , cryptée 
au niveau des échanges, que seul l’utilisateur final puisse décrypter.

David

En fait, c'est très compliqué. Car qui a accès à ta mémoire (le host) a 
forcément accès à tes espaces chiffrés. D'une part parce qu'ils sont 
déchiffrés en mémoire, et d'autre part parce que la clé privée se balade 
dedans le plus souvent.  Et si elle ne le fait pas, elle est dans une 
puce qui est accessible aussi par le host qui héberge.


Il existe bien une technologie, le chiffrement homomorphe, qui consiste 
à faire les opérations élémentaires sur les données chiffrées. La 
dernière fois que j'ai regardé, on savait faire seulement quelques 
opérations, mais ça a progressé, si j'en crois wikipedia Chiffrement 
homomorphe — Wikipédia (wikipedia.org) 
.


--

Thierry




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

RE: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Thierry Chich]

C'est peut-être pour exploiter ça ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31124


Thierry 




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stéphane 
Rivière
Envoyé : mercredi 24 janvier 2024 16:04
À : frnog-tech 
Objet : [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

Bonjour à toutes et tous,

2024 Jan 24 15:09:56 hostname *fatal: userauth_pubkey: parse request
failed: incomplete message [preauth]*

Mes logs sont (vaguement, c'est pas l'invasion non plus) pollués par ce message 
cryptique qui n'inspire guère Google.

J'ai (vaguement) cru comprendre que c'est généré par SSH via une "chatouille" 
pas finie dans une tentative de connexion illégitime par clé mais c'est pas 
clair (pour moi).

L'instance contient peu de chose : un openvpn, un ssh et un nginx en proxy. 
Ports ouverts 1194, 22, 80 443.

Avez vous un avis ? ;)

Merci d'avance...

--
Stéphane Rivière
Ile d'Oléron - France

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


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

RE: [FRnOG] [MISC] SFR Business Team candidat au poste de la plus mauvaise hotline entreprise ?

[Thierry Chich]

Elon Musk a racheté frnog ?

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stéphane 
Rivière
Envoyé : vendredi 27 octobre 2023 10:15
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] SFR Business Team candidat au poste de la plus 
mauvaise hotline entreprise ?

> Un article sur "20 Minutes" paru un peu après celui que tu cites 
> semble dire le contraire :
> https://www.20minutes.fr/sante/4050840-20230831-covid-19-non-agence-am
> ericaine-medicaments-donne-approbation-ivermectine

C'est normal. 20 minutes, tu attendais quoi d'autre ? :) Tu trouveras en 
primeur du gougle que des sites ressassant la même chose.

Pour le covid et l'ivermectine, faut juste l'avoir vécu.

Je chope volontairement (un client malade ne m'a jamais inquiété) cette merde 
(après coup, c'est une merde) par un client (toute sa famille était covidée et 
lui en sale état, il m'avait prévenu). J'ai expérimenté le vrai covid (tout le 
reste sont des crèves et grippes prises en faux positifs par des tests PCR qui 
ne testaient rien vu le protocole conçu pour être positif même 3 semaines après 
une infection), celui qui ne donne /pas du tout de température/ et qui te 
montes la pompe /au repos total/ entre 90 à 110 suivant l'âge et la condition 
physique. Et là, en yoyo à s'écrouler en pleine journée puis aller mieux une 
heure après, au bout de 4 jours de ce régime, t'es vraiment, mais vraiment 
crevé. Jamais vécu ça. Pourtant j'ai chopé des trucs zarbis dans divers pays, 
mais ça jamais. Alors tu finis un vendredi à 16h par envoyer un sms à ton 
médecin avec les symptômes, qui t'envoies par retour une prescription par photo 
et tu passes à 17h à la pharmacie récupérer pour deux sous une boite 
d'antiparasitaire qu'est l'ivermectine et le lendemain matin, t'es juste 
nickel, tout est parti, et... c'est juste choquant.

Alors tu te renseignes, tu trouves des publications scientifiques anglaises 
d'il y a 10/15 ans qui ont déterminé que l'ivermectine défonce les virus du 
zika, chikungunya  et autres dengues à la même vitesse, via une réduction de la 
charge virale de 5000 en une seule prise. C'est encore choquant.

Enfin, tu fais le tour du truc autour de toi : le client et sa famille, qui a 
le même toubib que toi, et même prescription et même résultat. Ce médecin en a 
soigné plus d'un millier sur l'île. En mettant sur son ordonnance : Hors AMM 
(c'est à dire qu'il prend la responsabilité pleine et entière des conséquences 
de sa prescription puisque ce médicament n'est qu'un antiparasitaire). 
D'autres, pour te faire rembourser, mettent que t'as la gale. Évidemment, s'il 
y a contrôle par la SS, on ne peut rien prouver d'autre que... la gale est déjà 
partie. Mais mon toubib, il est pas comme ça. Il ne triche pas.

Ensuite, pour le covid long, artémisia (une plante malgache importée en sie 
pour le paludisme en remplacement de l'hydroxychloroquine sous embargo 
américain à l'époque), interdite en fRance au début de la coviderie, les niçois 
qui la vendaient se sont expat en Thaïlande où on peut l'importer sans souci... 
Rappelons qu'avant la coviderie, l'hydroxychloroquine était en vente libre 
depuis toujours (aucun risque cardiaque, contrairement à la chloroquine). Les 
potes qui ont taffé en Afrique en prennent à vie suite au palu sans aucune 
conséquence.

Je dis ça, c'est juste un témoignage et, pour une fois, dredi n'est qu'une 
coïncidence. Pour le reste, Darwin reconnaîtra les siens.

--
Stéphane Rivière
Ile d'Oléron - France

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


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

Re: [FRnOG] [TECH] Domaines mails anonymes

[Thierry Chich]

C'est pas vraiment le sujet. Ici, il s'agit de boites temporaires pour 
éviter le spam. Ça ne veut pas forcément dire que le fournisseur de 
service ne répondra pas à une réquisition judiciaire. Il n'y a pas de 
promesse d'anonymisation de l'émetteur.


 Dans le cas présent, il s'agit d'une structure américaine, donc, 
disons-le, on est directement dans les bases de données de l'oncle SAM 
quand on l'utilise.


Non, ce que je cherche, c'est s'il y a des listes de domaines mail 
rogue. Des domaines qui sont fait uniquement pour pouvoir envoyer 
n'importe quoi à n'importe qui sans trace. Mais bon, vu les réponses, 
soit ça n'existe pas, soit je ne suis pas sur la bonne liste.


Le 21/10/2023 à 09:33, Arnaud Feix a écrit :

En OSINT c’est parfois utile :

https://www.emailnator.com/
Disposable Gmail | Temp Mail
emailnator.com



Le 20 oct. 2023 à 18:34, Laurent Barme<5...@barme.fr>  a écrit :


Le 20/10/2023 à 16:28, Arnaud Launay a écrit :

Le Fri, Oct 20, 2023 at 04:15:55PM +0200, Thierry Chich a écrit:

Ouais, c'est une provoc pour les libertariens.

Tant que tu passes par franceconnect pour t'identifier avant la création du 
mail,
tout va bien. Promis: les données ne sortiront pas des bases du gouvernement.



:-))


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


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

--

Thierry

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

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

Re: [FRnOG] [TECH] Domaines mails anonymes

[Thierry Chich]

Ouais, c'est une provoc pour les libertariens.

Le 20/10/2023 à 16:13, David Ponzone a écrit :

Ok c’est vendredi, tu te lâches :)


Le 20 oct. 2023 à 16:06, Thierry Chich  a écrit :

Bonjour

Avez vous connaissance de listes de domaines dédiés à faire des mails anonymes 
? Je pense à trucs du genre anonymousemail.me par exemple.

Cordialement

--
Thierry

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

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


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

--

Thierry


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

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

[FRnOG] [TECH] Domaines mails anonymes

[Thierry Chich]

Bonjour

Avez vous connaissance de listes de domaines dédiés à faire des mails 
anonymes ? Je pense à trucs du genre anonymousemail.me par exemple.


Cordialement

--
Thierry



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

Re: [FRnOG] [TECH] Annonces BGP filtrées par défaut

[Thierry CHICH]

Tu me fais douter. Je vérifie lundi.

Thierry

> Le 13 oct. 2023 à 19:45, Thierry CHICH  a écrit 
> :
> 
> Ben pour le coup, c’est bizarre, parce qu’on avait bien une annonce 0.0.0.0 
> 0.0.0.0 diffusés sur tous les peers à moins d’un filtre en sortie.
> 
> Alors bien sûr, elle a des bonnes chances de pas être prioritaire, mais c’est 
> pas le genre de chose que je trouve plaisant.
> 
> Cordialement
> Thierry
> 
>> Le 13 oct. 2023 à 10:27, David Ponzone  a écrit :
>> 
>> Hmm si je comprends bien ce que tu dis, je pense que tu comprends mal ce 
>> que default-originate signifie :)
>> 
>> C’est juste qu’en temps normal, même si tu as la route pour 0.0.0.0/0 dans 
>> ta RIB, que tu l’aies apprise en static/BGP/OSPF/bidule truc, elle sera 
>> JAMAIS annoncée à un peer.
>> Faut mettre cette ligne de conf pour qu’elle soit annoncée à un peer 
>> spécifique. Mais juste elle, pas toutes les routes plus spécifiques. C’est 
>> pas une conf wildcard.
>> Donc y a pas de risque énorme, sauf dans certains contextes (genre quand on 
>> oublie que la distance admin de eBGP est inférieure à presque tout), raison 
>> pour laquelle je pense c’est disabled par défaut.
>> 
>>>> Le 13 oct. 2023 à 10:15, Thierry Chich  a 
>>>> écrit :
>>> 
>>> Et c'était bien ça, y avait un truc à cocher default-originate sur le 
>>> Forcepoint qui m'a permis d'éliminer le "j'annonce le 0.0.0.0/0 pour tous 
>>> ceux qui souhaite me parler", dont je ne cache pas qu'il me mettait des 
>>> petits boutons. Certes, on peut restreindre avec des outbound-filter, mais 
>>> c'est un peu comme les firewalls avec any any allow à la fin, j'aime pas. 
>>> Ca me stresse.
>>> 
>>> Merci
>>> 
>>> Thierry
>>> 
>>> -Message d'origine-
>>> De : frnog-requ...@frnog.org  De la part de 
>>> Thierry Chich
>>> Envoyé : vendredi 6 octobre 2023 15:48
>>> À : 'Alexis Lameire' ; 'Paul Rolland (ポール・ロラン)' 
>>> 
>>> Cc : frnog@frnog.org
>>> Objet : RE: [FRnOG] [TECH] Annonces BGP filtrées par défaut
>>> 
>>> En fait, on fait pas ce qu'on veut avec notre quagga, y a une interface 
>>> graphique dessus. J'enquête sur la question, mais c'est vrai que votre 
>>> neigh 0.0.0.0 default-originate correspondrait bien à ce qu'on souhaite, 
>>> dans l'esprit.
>>> 
>>> Merci  
>>> 
>>> Thierry
>>> 
>>> 
>>> 
>>> -Message d'origine-
>>> De : frnog-requ...@frnog.org  De la part de Alexis 
>>> Lameire Envoyé : vendredi 6 octobre 2023 10:58 À : Paul Rolland (ポール・ロラン) 
>>>  Cc : frnog@frnog.org Objet : Re: [FRnOG] [TECH] 
>>> Annonces BGP filtrées par défaut
>>> 
>>> Hum,
>>> c'est pas très clair, mais je pense que ce qu'il veut c'est router bgp XXX
>>> neigh x.x.x.x default-originate
>>> 
>>> vue le besoin, ça me semble la conf la plus simple :
>>> https://community.cisco.com/t5/routing/difference-between-default-originate-and-network-0-0-0-0-in-bgp/td-p/1780201
>>> 
>>> Alexis
>>> 
>>> 
>>>> Le ven. 6 oct. 2023 à 10:06, Paul Rolland (ポール・ロラン)  
>>>> a écrit :
>>>> 
>>>> Hello,
>>>> 
>>>> On Fri, 6 Oct 2023 09:02:31 +0200
>>>> "Thierry Chich"  wrote:
>>>> 
>>>>> J'aurais pensé que les routes annoncées par le serveur BGP quagga au
>>>>> peer
>>>>> 10.242.49.154 aurait compris les deux routes vers 100.64/10 et vers
>>>>> 172.29.46.240/28, l'une parce que c'est le bon peer, l'autre parce
>>>>> que c'est la bonne AS, mais j'ai fait preuve de naiveté. Rien ne
>>>>> marche, dès que fait un match, ça ne marche pas.
>>>> 
>>>> Euh, c'est pas les routes par defaut ca... mais bon, passons.
>>>> Tes routes sont bien presentes sur ton BGP quagga ? Parce que les
>>>> avoir en clause network, c'est pas suffisant.
>>>> 
>>>> Paul
>>>> 
>>>> 
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/
>>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 


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

Re: [FRnOG] [TECH] Annonces BGP filtrées par défaut

[Thierry CHICH]

Ben pour le coup, c’est bizarre, parce qu’on avait bien une annonce 0.0.0.0 
0.0.0.0 diffusés sur tous les peers à moins d’un filtre en sortie.

Alors bien sûr, elle a des bonnes chances de pas être prioritaire, mais c’est 
pas le genre de chose que je trouve plaisant.

Cordialement 
Thierry 

> Le 13 oct. 2023 à 10:27, David Ponzone  a écrit :
> 
> Hmm si je comprends bien ce que tu dis, je pense que tu comprends mal ce que 
> default-originate signifie :)
> 
> C’est juste qu’en temps normal, même si tu as la route pour 0.0.0.0/0 dans ta 
> RIB, que tu l’aies apprise en static/BGP/OSPF/bidule truc, elle sera JAMAIS 
> annoncée à un peer.
> Faut mettre cette ligne de conf pour qu’elle soit annoncée à un peer 
> spécifique. Mais juste elle, pas toutes les routes plus spécifiques. C’est 
> pas une conf wildcard.
> Donc y a pas de risque énorme, sauf dans certains contextes (genre quand on 
> oublie que la distance admin de eBGP est inférieure à presque tout), raison 
> pour laquelle je pense c’est disabled par défaut.
> 
>> Le 13 oct. 2023 à 10:15, Thierry Chich  a 
>> écrit :
>> 
>> Et c'était bien ça, y avait un truc à cocher default-originate sur le 
>> Forcepoint qui m'a permis d'éliminer le "j'annonce le 0.0.0.0/0 pour tous 
>> ceux qui souhaite me parler", dont je ne cache pas qu'il me mettait des 
>> petits boutons. Certes, on peut restreindre avec des outbound-filter, mais 
>> c'est un peu comme les firewalls avec any any allow à la fin, j'aime pas. Ca 
>> me stresse.
>> 
>> Merci
>> 
>> Thierry
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de Thierry 
>> Chich
>> Envoyé : vendredi 6 octobre 2023 15:48
>> À : 'Alexis Lameire' ; 'Paul Rolland (ポール・ロラン)' 
>> 
>> Cc : frnog@frnog.org
>> Objet : RE: [FRnOG] [TECH] Annonces BGP filtrées par défaut
>> 
>> En fait, on fait pas ce qu'on veut avec notre quagga, y a une interface 
>> graphique dessus. J'enquête sur la question, mais c'est vrai que votre neigh 
>> 0.0.0.0 default-originate correspondrait bien à ce qu'on souhaite, dans 
>> l'esprit.
>> 
>> Merci  
>> 
>> Thierry
>> 
>> 
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de Alexis 
>> Lameire Envoyé : vendredi 6 octobre 2023 10:58 À : Paul Rolland (ポール・ロラン) 
>>  Cc : frnog@frnog.org Objet : Re: [FRnOG] [TECH] 
>> Annonces BGP filtrées par défaut
>> 
>> Hum,
>> c'est pas très clair, mais je pense que ce qu'il veut c'est router bgp XXX
>> neigh x.x.x.x default-originate
>> 
>> vue le besoin, ça me semble la conf la plus simple :
>> https://community.cisco.com/t5/routing/difference-between-default-originate-and-network-0-0-0-0-in-bgp/td-p/1780201
>> 
>> Alexis
>> 
>> 
>>> Le ven. 6 oct. 2023 à 10:06, Paul Rolland (ポール・ロラン)  a 
>>> écrit :
>>> 
>>> Hello,
>>> 
>>> On Fri, 6 Oct 2023 09:02:31 +0200
>>> "Thierry Chich"  wrote:
>>> 
>>>> J'aurais pensé que les routes annoncées par le serveur BGP quagga au
>>>> peer
>>>> 10.242.49.154 aurait compris les deux routes vers 100.64/10 et vers
>>>> 172.29.46.240/28, l'une parce que c'est le bon peer, l'autre parce
>>>> que c'est la bonne AS, mais j'ai fait preuve de naiveté. Rien ne
>>>> marche, dès que fait un match, ça ne marche pas.
>>> 
>>> Euh, c'est pas les routes par defaut ca... mais bon, passons.
>>> Tes routes sont bien presentes sur ton BGP quagga ? Parce que les
>>> avoir en clause network, c'est pas suffisant.
>>> 
>>> Paul
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

RE: [FRnOG] [TECH] Annonces BGP filtrées par défaut

[Thierry Chich]

Et c'était bien ça, y avait un truc à cocher default-originate sur le 
Forcepoint qui m'a permis d'éliminer le "j'annonce le 0.0.0.0/0 pour tous ceux 
qui souhaite me parler", dont je ne cache pas qu'il me mettait des petits 
boutons. Certes, on peut restreindre avec des outbound-filter, mais c'est un 
peu comme les firewalls avec any any allow à la fin, j'aime pas. Ca me stresse.

Merci 

Thierry 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Thierry 
Chich
Envoyé : vendredi 6 octobre 2023 15:48
À : 'Alexis Lameire' ; 'Paul Rolland (ポール・ロラン)' 

Cc : frnog@frnog.org
Objet : RE: [FRnOG] [TECH] Annonces BGP filtrées par défaut

En fait, on fait pas ce qu'on veut avec notre quagga, y a une interface 
graphique dessus. J'enquête sur la question, mais c'est vrai que votre neigh 
0.0.0.0 default-originate correspondrait bien à ce qu'on souhaite, dans 
l'esprit.

Merci  

Thierry 



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Alexis 
Lameire Envoyé : vendredi 6 octobre 2023 10:58 À : Paul Rolland (ポール・ロラン) 
 Cc : frnog@frnog.org Objet : Re: [FRnOG] [TECH] Annonces 
BGP filtrées par défaut

Hum,
c'est pas très clair, mais je pense que ce qu'il veut c'est router bgp XXX
  neigh x.x.x.x default-originate

vue le besoin, ça me semble la conf la plus simple :
https://community.cisco.com/t5/routing/difference-between-default-originate-and-network-0-0-0-0-in-bgp/td-p/1780201

Alexis


Le ven. 6 oct. 2023 à 10:06, Paul Rolland (ポール・ロラン)  a 
écrit :

> Hello,
>
> On Fri, 6 Oct 2023 09:02:31 +0200
> "Thierry Chich"  wrote:
>
> > J'aurais pensé que les routes annoncées par le serveur BGP quagga au 
> > peer
> > 10.242.49.154 aurait compris les deux routes vers 100.64/10 et vers 
> > 172.29.46.240/28, l'une parce que c'est le bon peer, l'autre parce 
> > que c'est la bonne AS, mais j'ai fait preuve de naiveté. Rien ne 
> > marche, dès que fait un match, ça ne marche pas.
>
> Euh, c'est pas les routes par defaut ca... mais bon, passons.
> Tes routes sont bien presentes sur ton BGP quagga ? Parce que les 
> avoir en clause network, c'est pas suffisant.
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


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


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

[FRnOG] [TECH] Nécessité d'une ligne téléphonique ?

[Thierry Chich]

Bonjour

 

Dites, c’est encore nécessaire d’avoir une ligne support pour les nouvelles
constructions, ou bien on peut se présenter chez un opérateur quelconque en
donnant simplement une adresse pour avoir fibre et tout le toutim ?

 


Thierry 



 

 


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

RE: [FRnOG] [TECH] Orange Business et l'enfer du suivi de projet

[Thierry Chich]

Je suis pas trop du genre à défendre Orange par principe, mais vous êtes
vraiment sûr que personne n'a reçu une petite feuille de papier où c'est
marqué, le réseau et la gateway ?

Thierry 




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Vincent
Duvernet
Envoyé : lundi 9 octobre 2023 14:43
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Orange Business et l'enfer du suivi de projet

Bonjour,

J'ai une école qui est au bord de la crise de nerfs à cause d'Orange suite
au déploiement de la fibre.
Ils ont ajouté la box fibre. L'installation est terminée depuis des semaines
donc facturée malgré le fait qu'elle ne soit pas utilisable.
Par contre, il n'y a pas de NAT ni de DHCP donc impossible de savoir quelle
IP publique et quel masque utiliser.

Le 3901 n'a pas la main dessus, le 1017 (de mémoire) ne semble pas faire
mieux et le chargé de suivi du projet est aux abonnés absents.

Est-ce que quelqu'un ici pourrait nous sortir de là ?

Merci la team,

Vincent


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


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

RE: [FRnOG] [TECH] Annonces BGP filtrées par défaut

[Thierry Chich]

En fait, on fait pas ce qu'on veut avec notre quagga, y a une interface 
graphique dessus. J'enquête sur la question, mais c'est vrai que votre neigh 
0.0.0.0 default-originate correspondrait bien à ce qu'on souhaite, dans 
l'esprit.

Merci  

Thierry 



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Alexis 
Lameire
Envoyé : vendredi 6 octobre 2023 10:58
À : Paul Rolland (ポール・ロラン) 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Annonces BGP filtrées par défaut

Hum,
c'est pas très clair, mais je pense que ce qu'il veut c'est router bgp XXX
  neigh x.x.x.x default-originate

vue le besoin, ça me semble la conf la plus simple :
https://community.cisco.com/t5/routing/difference-between-default-originate-and-network-0-0-0-0-in-bgp/td-p/1780201

Alexis


Le ven. 6 oct. 2023 à 10:06, Paul Rolland (ポール・ロラン)  a 
écrit :

> Hello,
>
> On Fri, 6 Oct 2023 09:02:31 +0200
> "Thierry Chich"  wrote:
>
> > J'aurais pensé que les routes annoncées par le serveur BGP quagga au 
> > peer
> > 10.242.49.154 aurait compris les deux routes vers 100.64/10 et vers 
> > 172.29.46.240/28, l'une parce que c'est le bon peer, l'autre parce 
> > que c'est la bonne AS, mais j'ai fait preuve de naiveté. Rien ne 
> > marche, dès que fait un match, ça ne marche pas.
>
> Euh, c'est pas les routes par defaut ca... mais bon, passons.
> Tes routes sont bien presentes sur ton BGP quagga ? Parce que les 
> avoir en clause network, c'est pas suffisant.
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


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

[FRnOG] [TECH] Annonces BGP filtrées par défaut

[Thierry Chich]

Bonjour

Je souhaite pouvoir annoncer la route par défaut pour des routeurs, mais
j'aimerais bien que ce soit limité à une liste restreinte d'éléments. J'ai
essayé de faire un truc de ce genre avec les route-map:

router bgp 65001

 bgp router-id 172.29.44.203
 bgp graceful-restart
 network 100.64.0.0/10 route-map element3
 network 172.29.46.240/28 route-map element4
 network 172.29.77.16/28
 
 neighbor 10.242.49.154 remote-as 65003
 neighbor 10.242.49.154 fall-over bfd
 …
 neighbor 10.242.49.154 next-hop-self
 no neighbor 10.242.49.154 send-community both
 neighbor 10.242.49.154 soft-reconfiguration inbound
 neighbor 10.242.49.154 distribute-list element3 in
 exit
!
access-list element3 permit 10.242.224.0/19
access-list element3 permit 10.242.192.0/19
access-list element3 permit 172.25.16.0/20
!
ip as-path access-list element7 permit 65003
!
route-map element3 permit 1
 match peer 10.242.49.154
!
route-map element4 permit 1
 match as-path element7

J’aurais pensé que les routes annoncées par le serveur BGP quagga au peer
10.242.49.154 aurait compris les deux routes vers 100.64/10 et vers
172.29.46.240/28, l’une parce que c’est le bon peer, l’autre parce que c’est
la bonne AS, mais j’ai fait preuve de naiveté. Rien ne marche, dès que fait
un match, ça ne marche pas.

Vous avez une idée ? J’ai cherché, mais j’ai rien vu d’évident. Je précise
que je sais bien que je peux faire des filtrages au niveau des negihbors
avec les distribute-list, mais ce n’est pas ce que cherche. 

 

 


Thierry 



 

 


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

Re: [FRnOG] [TECH] Stratégie redondance/branchement switchs coeur de réseau

[Thierry Chich]

Bonjour

Je suis assez en phase avec ce que tu dis dans les datacentres, ou les 
MAN,  et tout le toutim, mais sur un site, je ne vois pas trop comment 
tu rends le service au client. Le type arrive avec son pc, il recoit son 
ip en dhcp, et il se passe quoi après ?


C'est une question, pas une agression, c'est juste que je n'ai pas vu 
d'archi de ce type en place, et je ne vois pas comment ça fonctionne.


Le 02/10/2023 à 10:01, Nicolas Vuillermet a écrit :

Hello,

En 2023 parler encore de stack est une aberration.

à la limite du virtual chassis à la VSS et encore... ces technos 
sombres te finissent par péter entre les mains, il y a un moment dans 
le cycle de vie où tu te retrouves à redémarrer toute la stack...
"Récemment", y'a 1 an quand j'étais sur un réseau legacy, j'ai une 
stack de C6840 qui m'a pété en pleine tronche ; debug ospf a mem-leak 
sur un des noeuds du chassis, reboot de celui-ci, au retour le L2 
passait plus entre les deux par contre le L3 nickel :>


Dukou en 2023 ce qu'on fait ; *EVPN*.

EVPN VxLAN ou MPLS en fonction de comment tu es riche, plan contrôle 
BGP, tout le monde est décideur dans ton réseau, tu peux rajouter des 
noeuds un peu où tu veux, tu peux faire un réseau de clos comme mettre 
tes switchs un peu n'importe où, entre Nexus 9k, Arista, Juniper 
QFX/MX, c'est pas le matériel qui manque.


ça se debug bien mieux qu'une stack, ça sait interagir avec des 
Hyperviseurs vmware avec NSX ou proxmox avec l'intégration SDN... bref


Je parle même pas du fait que t'as plus besoin de te poser de question 
de si tes membres vont se reconnaître après une mise à jour qui est un 
réel problème en cas de stack.


P'tite overview Arista que j'aime bien : 
https://www.arista.com/en/um-eos/eos-evpn-overview


D'ici 10 ans, ceux qui seront en pure L2 dans leur campus alors que le 
broke sera floodé de switch campus L2VPN capable seront bien en retard.


De plus, des solutions SDN réelles apparaissent telle que Arista 
CloudVision ou Juniper Myst pour orchestrer un tel réseau quand faire 
une vingtaine de ligne de cli devient trop ardu.


Nicolas

Le 02/10/2023 à 09:14, Fabien H a écrit :

Bonjour,

Avec le recul, que préconisez vous pour avoir une archi plus résiliente
possible au niveau des SW coeur de réseau ?

Stack de switch avec LAG ?
switchs de type virtual chassis avec LAG virtuel ?

La question porte aussi sur la fiabilité de l'architecture retenue en 
cas

de défaillance d'un des switchs, est-ce que globalement, hors bugs, avec
des OS à jour, ça continue à fonctionner comme prévu (le stack 
continue à
fonctionner sur 1 noeud ou le virtual chassis continue à fonctionner 
sur 1

noeud)

Merci pour vos retours,
Fabien

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

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

--

Thierry CHICH

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@ac‑clermont.fr <mailto:thierry.ch...@ac-clermont.fr> ‑ 
dsi‑rese...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>


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

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

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

Re: [FRnOG] [MISC] LACP / MTU et restauration entre deux NAS

[Thierry Chich]

Bonjour

Oui, le LACP fait un partage de la bande "statistique". Souvent c'est  
simplement un algorithme de parité avec les adresses Mac, du genre si la 
somme des adresse mac est paire, tu passes sur le premier lien, sinon 
sur le second. Y a d'autres algos implantés, mais c'est souvent comme ça 
de base. Il ne faut pas oublier que balancer du trafic d'une même 
session TCP sur deux liens s'avèrent souvent contre-productif.


Thierry

Le 09/07/2023 à 23:06, Jérôme Quintard a écrit :

Hello,

J'ai deux NAS identiques dont la performance "théorique" totale est estimée à 1 
Go/s en lecture et 432 Mo/s en écriture.

Les NAS sont connectés à un switch en 2 x1 Gb/s via du LACP.

Lors d'une restauration de l'un sur l'autre nous sommes limités par la plus 
petite bande passante... c'est le port du switch avec ses 128 Mo/s (sauf erreur 
la session utilise un seul canal LACP).

Un iperf entre les deux NAS me donne raison : 117 Mo/s.

Sauf que les 10 To que l'on a restauré ont pris 68h (de la première à la 
dernière écriture donc sans le délai nécessaire pour générer la liste des 
fichiers).

Avec 117 Mo/s on arrivera logiquement à restaurer 28To en 68h.
A l'inverse 10 To en 68h nous donne 40 Mo/s.

D'où 3 questions :

   *   Est-ce que le LACP est bien limité à un seul canal par session ?

   *   Le MTU par défaut de 1500 n'est pas top. Est-ce la raison et surtout 
comment calculer la différence avec du jumbo frames ?

   *   Vu que le site était off pendant la restauration (qui s'est déroulé un 
weekend) qu'est-ce qui pourrait expliquer cette limite à 40 Mo/s en dehors du 
MTU ?

Merci pour vos avis.

Jerome

--


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

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

[Thierry Chich]

Personnellement, je préfère infiniment ramener tout le trafic chez moi. 
On a ainsi un contrôle effectif de ce qui sort du poste. J'ai une sainte 
horreur du split-tunneling qui me parait être un bon moyen de se 
constituer un joli pont entre son SI (ou celui du client) et l'internet. 
C'est encore plus vrai quand les postes ne sont pas bien maîtrisés. 
D'une manière général, j'ai du mal à comprendre que les choses soient 
différentes quand on est en télétravail et en présentiel: que son flux 
de sortie soit contrôlé par le firewall en présentiel, et pas en 
distanciel par exemple.


Sinon, oui on peut faire ce genre de choses avec des socks, ou même avec 
du ssh tunneling. Ou du guacamol, si on ne veut faire que du RDP et du 
SSH, ou encore avec un portail sur un forti.  Ou router le réseau client 
dans le tunnel (c'est hyper sale et errorogène).


Mais faut vraiment aimer se faire mal, surtout pour les socks et autre 
ssh tunneling.



Le 29/03/2023 à 16:43, DUVERGIER Claude a écrit :
Au vu des réponses, je comprends que j'ai mélangé différents points 
sans être totalement clair alors je reprends avec plus de contexte.


Dans le cadre de nos prestations des collègues sont amenés à 
travailler (pendant quelques jours, semaines ou mois) sur les sites 
des clients (production ou préproduction) et notamment se connecter au 
backoffice web, ou serveur de stockage FTP.


A. Parfois c'est un accès direct sans filtrage d'adresse IP.
B. Parfois c'est un accès direct mais uniquement autorisé depuis des 
adresses IP préalablement déclarées.
C. Parfois c'est via un serveur bastion du client (j'ai eu les cas 
d'un accès SSH et d'autres via RDP) dont l'accès et uniquement 
autorisé depuis des adresses IP préalablement déclarées.


Pour le cas A : aucun problème (sauf à la limite quand notre staff 
télétravaille depuis des pays "exotiques" que le client aurait par 
défaut bloqué de son côté : mais c'est rare).


Pour les cas B et C : on communique au client les adresses IP 
publiques qu'utilisent nos agences pour accéder à Internet, le client 
les autorise et tout fonctionne (généralement pas du premier coup il 
est vrai :P).


Mais quand le collègue est en télétravail il surfe via sa connexion 
Internet personnelle et donc via une IP que le client ne connaît pas.


Il pourrait communiquer son IP personnelle au client qui n'aurait qu'à 
la rajouter : mais ça prends généralement du temps (le client doit 
contacter son prestataire, etc.) et parfois le collègue n'a carrément 
pas d'adresse IP fixe (certains FAI, ou les clients nomades en 
connexion cellulaire).


Alors, ce qu'on a fait dans un premier temps c'est mettre en place un 
serveur proxy HTTP (Squid) dont l'accès à Internet passe par une des 
adresses IP communiquées au client (le serveur est hébergé en local 
dans nos locaux). Ça fonctionne pour l'HTTP, pas pour le FTP, SSH, RDP 
qui sont des protocoles d'accès que certains clients nous demandent 
d'utiliser.


Pour éviter d'ouvrir à tout vent ce serveur proxy, il n'est pas 
accessible sur Internet : pour le contacter alors qu'on est en 
télétravail/nomade on doit passer par notre service de VPN.


Ce service VPN existait déjà avant ces problématique d'accès aux BO 
des clients et réponds à un tout autre besoin : permettre aux 
télétravailleurs/nomades d'accéder à certaines ressources locales 
(auto hébergées) du SI de notre société. Et il est configuré pour que 
seul le trafic destiné au LAN y arrive (avec l'exemple d'une vidéo 
YouTube consultée pendant le télétravail qui ne passerait donc pas via 
le VPN).


Mes solutions envisagées :

 * Trouver un outil qui "sache" proxyfier de l'HTTP, FTP, SSH, RDP, etc.
   Un proxy en SOCKS5 peut faire tout ça ?
 * Mettre en place, en interne, un bastion sous la forme d'un bureau
   virtuel où l'utilisateur aurait navigateur web, client FTP/SSH/RDP
 * Capter tout le trafic réseau via le tunnel VPN : ainsi les
   collaborateurs apparaissent comme étant tout le temps "au bureau".

Vu le nombre de prestation et la durée de celle-ci, je préfère avoir 
une solution qui ne me demande pas de configuration dédiée à chaque 
besoin.


Il existe évidemment plein de solutions techniques que le client 
auraient pu mettre en place pour simplifier le tout (dans le style de 
Boundary de HashiCorp, Envoy Proxy de Lyft, etc.) mais je dois 
généralement composer avec ce qu'ils ont.


Je me dis que je ne dois pas être le seul à avoir ces problématiques 
d'accès filtrés aux ressources des clients ? Si ?



--


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

Re: [FRnOG] [MISC] Sipartech Opérateur Souverain ?

[Thierry Chich]

Hello Rod


Some of the things you are saying about the french "psychology" are 
true, but you should see that the laws voted in the USA since 9/11 are 
not letting too much place to the trust.  Patriot Act and Cloud Act 
cannot not be ignored, even if the point is much more to know where is 
the head of the society operating the fibers than the nationality of the 
investissors.



About the difference between Germany and France, I will just say that 
suggesting that  the difference of GDP between the two countries could 
be explain by the insecurity of French people is simplistic at least.



Thierry


Le 15/02/2023 à 10:12, Rod Beck a écrit :
Talk about sovereignty has been a smokescreen for protectionism for a 
very long time. It is a defensive Castle mentality that no place in 
Europe which is evolving towards a Federal State. A confident society 
like Germany does not talk about sovereignty. My time in France 
suggests the French feel insecure. It is not a secret that France has 
gone from one of the great world powers to second place in Europe well 
behind Germany in both prosperity and influence. Three trillion Euro 
versus a 4.5 trillion Euro economy.


A more enlightened approach is to welcome foreign investment instead 
of indulging in national insecurity. Railing about foreign money will 
not offset the fact the French standard of living as measured by real 
income is now well below German or American levels. Germany welcomed 
Tesla.


-R.


*From:* frnog-requ...@frnog.org  on behalf of 
Thierry Chich 

*Sent:* Wednesday, February 15, 2023 8:22 AM
*To:* frnog@frnog.org 
*Subject:* Re: [FRnOG] [MISC] Sipartech Opérateur Souverain ?
C'est le genre de définition qui, ne proposant aucun horizon réalisable,
n'insipire aucune stratégie cohérente. Comme à l'ordinaire, il convient
de définir des graduation dans les choses. Pour la souveraineté, il est
probablement plus souverain d'être hébergé chez OVH que chez Amazon,
plus souverain d'utiliser une fibre noire que d'être sur un sdwan dont
les flux sont déportés dans le cloud, etc.

Et c'est pareil pour l'écologie, pour la sécurité informatique, et pour
à peu près tout en fait.

Le 14/02/2023 à 18:15, Stéphane Rivière a écrit :
> Coté IT, un pays sera souverain le jour où il produira ses propres
> équipements, doté de ses propres composants et logiciels.
>
> Tout un programme (sic).
>
-
Thierry
<http://www.ac-clermont.fr>

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

--


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

Re: [FRnOG] [MISC] Sipartech Opérateur Souverain ?

[Thierry Chich]

C'est le genre de définition qui, ne proposant aucun horizon réalisable, 
n'insipire aucune stratégie cohérente. Comme à l'ordinaire, il convient 
de définir des graduation dans les choses. Pour la souveraineté, il est 
probablement plus souverain d'être hébergé chez OVH que chez Amazon, 
plus souverain d'utiliser une fibre noire que d'être sur un sdwan dont 
les flux sont déportés dans le cloud, etc.


Et c'est pareil pour l'écologie, pour la sécurité informatique, et pour 
à peu près tout en fait.


Le 14/02/2023 à 18:15, Stéphane Rivière a écrit :

Coté IT, un pays sera souverain le jour où il produira ses propres
équipements, doté de ses propres composants et logiciels.

Tout un programme (sic).


-
Thierry


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

Re: [FRnOG] [TECH] Bug Mikrotik intéressant

[Thierry Chich]

A une époque, sur linux, avec freeswan, quand on sniffait une interface 
sur laquelle on avait de l'IPSEC, on ne voyait que les paquets entrants 
(ou sortant, je ne me rappelle plus).  Je dis à l'époque, parce que je 
ne fais plus de choses de ce type. C'est dommage, parce que dans la 
version précédente, on avait une jolie interface virtuelle ipsec0 bien 
proprette, sniffable et tout ça.


Le 12/01/2023 à 20:03, David Ponzone a écrit :

Tous, et surtout les MK-fans,

J’expose ce problème car c’est intéressant techniquement (=j’ai « perdu »  3h 
dessus), mais je n’espère pas avoir de réponse claire :)

Contexte:
CPE Mikrotik avec un FTTH en PPPoE, qui fait le NAT
Un firewall Sophos sur le LAN

Problème: le Sophos n’arrive à monter un tunnel IPSec (initialisation en UDP 
500)

Observations:
-si je regarde la table conntrack du MK, je vois bien l’UDP 500 venant du 
Sophos vers l’endpoint du Tunnel, mais pas de réponse au paquet
-si je prends une trace sur le PPP, je ne vois pas l’UDP 500 envoyé par le 
Sophos!
-donc je me dis: ok le MK filtre, je prends la trace sur le port LAN, et là non 
plus, je ne vois pas l’UDP 500 envoyé par le Sophos….

Après beaucoup de temps et une coïncidence heureuse (pour une fois), j’en viens 
à me demander si j’ai pas un problème de MTU sur le PPPoE.
MTU négocié à 1480 alors 1460 est le max, j’ai donc une plage possible de 
quelques paquets qui seront droppés sans être frag.
Je modifie le MTU à 1460 et là:
-le tunnel monte
-je vois les paquets entrants sur le LAN sur mon tcpdump

Donc il semble y avoir une situation qui fait que le sniffer intégré d’un MK ne 
va pas montrer des paquets ingress parce qu’ils sont droppés en egress.
De la pure folie :)
Après, je ne sais pas exactement où le sniffer Mikrotik fait son tapping, mais 
c’est clairement pas tout à fait au niveau du port ethernet ou du bridge….

Si quelqu’un a un début d’explication, soit du problème, soit de ma sénilité, 
je suis preneur!

David


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

--

Thierry




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

Re: [FRnOG] [MISC] Je vois rouge avec Orange !

[Thierry Chich]

C'est le genre de truc que je ne fais plus. Quand on me demande quelque 
chose, je fais exactement ce qu'on me demande même si c'est idiot. Je 
vais poser la nouvelle livebox sur l'étagère, et je renvoie la vieille, 
comme le monsieur il a dit.


Le procès de Kafka, faut éviter de le vivre trop souvent, sinon on finit 
par faire de la tension.


Le 30/09/2022 à 14:32, Toussaint OTTAVI a écrit :


Le 30/09/2022 à 14:02, David Ponzone a écrit :
-au bout d’un mois à attendre, ben en fait non, c’est pas possible, 
on vous envoie un autre ONT


Pas mal. Mais si on commence à sortir les dossiers, on en a pour la 
journée :-)


- Toujours chez Orange Pro, une IP, fixe depuis plusieurs mois, un 
beau jour, décide de changer.
- Habituellement, c'est une case à cocher dans les applis. La 
commerciale dédiée est absente, j'appelle la plateforme Entreprise :
  - Eux : "Oui, on vous active l'IP fixe, mais il faut aussi remplacer 
le Livebox"
  - Moi : "Mais je n'utilise pas la Livebox, elle est posée sur une 
étagère; je n'utilise que l'ONT externe"

  - Eux : "Oui, mais il faut changer la Livebox"
  - Moi, dépité : "OK, envoyez une Livebox neuve"
- Je préviens la responsable qu'une Livebox va arriver par la Poste. 
Je lui demande d'utiliser le bon de retour fourni, et de la renvoyer 
illico.

- Entre temps, l'IP fixe devient fixe ! Yes !!!
- Un mois plus tard, courrier de mise en demeure : "On va vous envoyer 
l'huissier pour saisir vos biens, vous n'avez pas renvoyé l'ancienne 
Livebox; çà fait 156 €"


--

Thierry

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

Re: [FRnOG] [TECH] Bizarreries sur les paquets sortants, suis-je le seul ?

[Thierry Chich]

Bonjour

C'est pas tous les jours qu'on voit une analyse aussi précise. Je 
mettrais un bien un like, mais c'est pas le lieu.


J'imagine qu'il s'agissait d'un IPS fou furieux ?

En tout cas, c'est une bonne chose que ce soit résolu. J'ai eu en mon 
temps toutes les peines du monde à faire admettre que  des livebox 
droppaient les fragments des paquets isakmp trop gros pour tenir dans 
des paquets de 1500. Je bénis encore le technicien d'Orange qui m'avait 
d'une part écouté et finalement identifié qu'il s'agissait d'une maj 
défectueuse.



Le 19/07/2022 à 00:36, Caeies a écrit :

Bonjour / Bonsoir à tous.

J'espère ne pas m'être trompé de tag / liste, si c'est le cas merci de
me le signaler.

J'ai regardé dans les archives, mais je n'ai rien vu de semblable (j'ai
probablement mal cherché).

Le symptôme principal, ce sont des connexions qui gèlent et sont
non-fonctionnelles, toutes les retransmissions suivante pour le TCP par
exemple étant systématiquement perdues [en bref, un enfer sans nom pour
un télétravailleur comme moi].


Les faits:
 * Fibre orange GP depuis + de 5 ans, pas eu de soucis majeurs 
jusqu'alors.

 * Dans le nord du 92, via une livebox (v4) + ONT (les deux ont été
changés, ainsi que les câbles entre les deux).
 * Les paquets ayant une taille (hors tag VLAN 832) de 16 * N + 9 (avec
N >= 3 et N <= 93 (pour cause de MTU)) et remplissant la condition :
x0xx1xxxXX (XX == 1 octet, et x == 1 bit) sur le dernier mot (int32)
du paquet sont «perdus» entre l'ONT et la sortie de la machine
80.10.236.81 (*). Quelque soit le protocole au dessus (IP{TCP,UDP,ICMP}.
IPV6{TCP,UDP,ICMP}).
 * En testant depuis l'extérieur de mon réseau, le problème est bien
présent uniquement sur les paquets qui sortent et pas sur les paquets
arrivant de l'extérieur, probablement parce que la machine 80.10.236.81
ne s'occupe que de la sortie des livebox, et pas l'entrée.
 * J'ai vérifié que les paquets sortant de la livebox étaient tous
corrects (au moins en terme de checksum).


Suis-je le seul (a priori c'est uniquement pour des personnes du nord du
92 passant par 80.10.236.81) ?

Auriez-vous des idées de ce qui peut se passer ?

Pour reproduire le problème, un simple ping -n -q -w1 -c 1 -p 0f -s 29
ping.online.net depuis une livebox permet de détecter le problème (alors
que le -p ff passe par exemple).

Merci d'avance pour vos lumières.

Caeies.


(*) Info dernière minute, en rédigeant le mail, le problème a semble
t'il été résolu aujourd'hui vers 18:08, merci aux gens de cette liste
qui ont agit avant que le mail ne parte ! (en espérant que ça dure).
Je l'envoie malgré tout pour les archives, ou si ça peut aider quelqu'un
d'autre !



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

--


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

Re: [FRnOG] [TECH] Etiqueteuse parfaite ?

[Thierry Chich]

Et on trouve des recharges facilement ?

Le 13/04/2022 à 17:04, Mickael MONSIEUR a écrit :

Je viens de vérifier, on les a depuis Novembre et on a commandé à les
installer en Décembre sur un premier rack, et je suis allé Lundi voir
le rack et les labels n'avaient pas bougé, difficile d'avoir plus de
recul...

Le mer. 13 avr. 2022 à 16:13, David Touitou  a écrit :

Re-


Nous n’utilisons que ça depuis des mois, c’est parfait. Je peux vous envoyer des
photos en privé.

C'est de l'impression thermique, ça tient aux UV ?
Les stickers supporte la sécheresse des datacentres ?

David


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

--

Thierry CHICH

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@ac‑clermont.fr <mailto:thierry.ch...@ac-clermont.fr> ‑ 
dsi‑rese...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>


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

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

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

Re: [FRnOG] [TECH] Les routeurs dépendent-ils du serveur de licence ?

[Thierry Chich]

Ca me parait effectivement extrêmement improbable. Ne serait-ce parce 
qu'il faudrait que tous les routeurs soient sur des réseaux IP publics 
ou a minimum natté ce qui est un postulat absolument faux. Et quand on 
voit la fréquence des blackhole ICMP sur les réseaux WAN, Je pense que 
ça se saurait depuis longtemps.


Le 13/03/2022 à 18:41, Raphael Mazelier a écrit :


Sur ce que je connais le mieux : junos sur du mx gamme classique (240, 
480, 960 qui constituent encore le cœur de nombreux réseaux opérateur) 
il n'y a ma connaissance aucun mécanisme de licence enforcé.


Si c'était le cas cela voudrait dire que tout les routeurs en 
circulation devraient avoir des licences à jour et être dûment déclaré 
chez Juniper. Hors de ce que j'en sais (ou même déployé) il existe de 
nombreux routeur en prod issu du grey market avec un junos hors 
support. A priori tout ces routeurs sont toujours up and running.


--
Raphaël Mazelier


On 13/03/2022 16:08, David Ponzone wrote:
Perso, j’y crois pas. Il y a forcément des réseaux sur lesquels les 
routeurs n’ont pas accès au net, pour des raisons de topo ou de 
sécurité.


Quelqu’un veut bien faire le test ?

David Ponzone




Le 13 mars 2022 à 15:48, Wallace  a écrit :

Pas entendu parlé mais ça m'étonnerait à peine et beaucoup de 
réseaux sont full open en sortie même si l'entrée est filtrée, je 
doute même que beaucoup de monde aient une vue sur le trafic émis 
par un backbone puisqu'il n'y a pas de firewall pour loguer et 
filtrer en amont.


En tout cas je sors les popcorns j'ai hâte de voir les retours.


Le 13/03/2022 à 14:27, Stephane Bortzmeyer a écrit :
Dans le cadre de la réflexion sur la robustesse de l'Internet au cas
où un russe / un chat / un chat russe couperait les câbles
transatlantiques, certains disent que les routeurs Cisco / Juniper /
etc cesseraient de fonctionner au bout de N jours s'ils ne peuvent pas
joindre leur serveur de licences.

Cela me parait fort de café (bien des routeurs sont dans des réseaux
fermés, sans accès à l'extérieur) mais avez-vous des informations
fiables à ce sujet ?


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

--
Thierry

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

RE: [FRnOG] Re: [ALERT] Google down ?

[Thierry Chich]

Merci. J'avais pas identifié que le problème était localisé sur Oleane. Je 
viens de virer ce reliquat de la conf d'un de nos résolveurs. 

Toujours aussi utile cette liste.

Thierry 


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stephane 
Bortzmeyer
Envoyé : mercredi 19 janvier 2022 15:35
À : Pierre DOLIDON 
Cc : frnog-al...@frnog.org
Objet : [FRnOG] Re: [ALERT] Google down ?

On Wed, Jan 19, 2022 at 11:14:02AM +0100,  Pierre DOLIDON  
wrote  a message of 26 lines which said:

> # dig www.google.com 
> [...]
> ;; ANSWER SECTION:
> www.google.com. 3587IN  ::1 [...]

https://www.bortzmeyer.org/oleane-dns-google.html

(Davantage à venir.)


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


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

RE: [FRnOG] Re: [TECH] question sur les DNS publics et edns client subnet

[Thierry Chich]

Ben cette idée vient probablement du fait qu'on peut distribuer les IP des 
serveurs DNS par DHCP, et donc que c'est fait en beaucoup beaucoup d'endroit de 
rediriger sur un forwarder local. 
Alors que les services DoH, en gros, 98% des utilisateurs vont choisir parmi 
les quelques opérateurs proposés par le navigateur. Dans le cas de firefox, en 
gros, couldfare. 

Dans les faits, je ne vois pas comment ça n'aurait pas un effet centralisateur. 

Thierry 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de 'Stephane 
Bortzmeyer'
Envoyé : jeudi 13 janvier 2022 15:21
À : Thierry Chich 
Cc : 'Stephane Bortzmeyer' ; 'Pierre-Yves Kerembellec' 
; dwet...@atanar.com; frnog-t...@frnog.org
Objet : [FRnOG] Re: [TECH] question sur les DNS publics et edns client subnet

On Thu, Jan 13, 2022 at 03:14:12PM +0100,  Thierry Chich 
 wrote  a message of 30 lines which said:

> Dans DoU ou DoT, il y a beaucoup de résolveurs récursifs 
> intermédiaires. Pour DoH, c'est quand même bien plus centralisé par 
> nature, non ?

Non, et je me demande vraiment d'où vient cette idée. (Dans les trois cas, on 
peut avoir 0, 1 ou N résolveurs intermédiaires.)


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


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

RE: [FRnOG] Re: [TECH] question sur les DNS publics et edns client subnet

[Thierry Chich]

Dans DoU ou DoT, il y a beaucoup de résolveurs récursifs intermédiaires. Pour 
DoH, c'est quand même bien plus centralisé par nature, non ? 

Thierry 
-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stephane 
Bortzmeyer
Envoyé : jeudi 13 janvier 2022 14:46
À : Pierre-Yves Kerembellec 
Cc : dwet...@atanar.com; Stephane Bortzmeyer ; 
frnog-t...@frnog.org
Objet : [FRnOG] Re: [TECH] question sur les DNS publics et edns client subnet

On Thu, Jan 13, 2022 at 02:37:23PM +0100,  Pierre-Yves Kerembellec 
 wrote  a message of 99 lines which said:

> Dans le cas de DoH, le client qui se connecte directement au resolver 
> ("over HTTPS"), le resolver « voit » donc directement l’IP réelle du 
> client et peut faire du geo si besoin.

Rien de spécifique à DoH, dans toute communication IP, c'est pareil.


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


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

RE: [FRnOG] [BIZ] [DNS4EU] Appel à projets européen pour un résolveur DNS

[Thierry Chich]

Désolé, mais je n'ai pas compris comment un appel d'offre pour fournir des 
infras aux territoires isolés (small islands) peut être vu comme une volonté de 
mettre en place un kill switch ?

Thierry 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Wallace
Envoyé : jeudi 13 janvier 2022 14:18
À : frnog@frnog.org
Objet : Re: [FRnOG] [BIZ] [DNS4EU] Appel à projets européen pour un résolveur 
DNS

Et personne ne réagit à ce projet qui sous couvert d'améliorer des choses veut 
centraliser le contrôle des connexions?

https://hadea.ec.europa.eu/calls-proposals/backbone-connectivity-digital-global-gateways-works_en

Un kill switch européen à la Russe pour isoler l'Europe en cas de besoin?

Cumulé au resolver ouvert en EU c'est exactement ce qu'il faut pour s'isoler.

Le 12/01/2022 à 17:56, Stephane Bortzmeyer a écrit :
> Si vous voulez 14 millions d'euros, cet appel à projets pourrait vous 
> intéresser (il s'agit de faire un concurrent de 8.8.8.8 et 1.1.1.1) :
>
> https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks
> -high-performance-and-secure-dns-resolution-infrastructures-works_en
>
> (Il y a aussi 65 millions pour du cloud mais je n'ai pas lu cette
> partie.)
>
>
> ---
> 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] notation ipv6

[Thierry Chich]

Honte à moi

Thierry 




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Thierry 
Chich
Envoyé : jeudi 25 novembre 2021 15:39
À : 'Erwan David' 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] notation ipv6

Je me demande quand même si on ne devrait de temps à autres faire une cagnotte 
collaborative pour financer des contrats contre les auteurs de RFC/développeurs 
qui sont à l’origine de ce genre de fantaisies.

# ping one.one.one.one

Envoi d'une requête 'ping' sur one.one.one.one [1.1.1.1] avec 32 octets de 
données :
Réponse de 1.1.1.1 : octets=32 temps=41 ms TTL=54 Réponse de 1.1.1.1 : 
octets=32 temps=43 ms TTL=54 Réponse de 1.1.1.1 : octets=32 temps=41 ms TTL=54

Et ne me demandez pas pourquoi
# ping one.one.one.one

Envoi d'une requête 'ping' sur one.one.one.one [1.0.0.1] avec 32 octets de 
données :
Réponse de 1.0.0.1 : octets=32 temps=42 ms TTL=54


Thierry 

> Le 24 nov. 2021 à 11:45, Erwan David  a écrit :
> 
> Le 24/11/2021 à 09:44, Benjamin Abadie via frnog a écrit :
>>> On 11/23/21 6:09 PM, Vincent Tondellier via frnog wrote:
>>> il n'existe pas a ma connaissance de format compressé pour les ipv4.
>> Il me semble que si :
>> $ ping 1.1
>> PING 1.1 (1.0.0.1) 56(84) bytes of data.
> 
> Il y a même
> 
> $ ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.066 ms
> 
> 
> ---
> 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] notation ipv6

[Thierry Chich]

Je me demande quand même si on ne devrait de temps à autres faire une cagnotte 
collaborative pour financer des contrats contre les auteurs de RFC/développeurs 
qui sont à l’origine de ce genre de fantaisies.

# ping one.one.one.one

Envoi d'une requête 'ping' sur one.one.one.one [1.1.1.1] avec 32 octets de 
données :
Réponse de 1.1.1.1 : octets=32 temps=41 ms TTL=54
Réponse de 1.1.1.1 : octets=32 temps=43 ms TTL=54
Réponse de 1.1.1.1 : octets=32 temps=41 ms TTL=54

Et ne me demandez pas pourquoi 
# ping one.one.one.one

Envoi d'une requête 'ping' sur one.one.one.one [1.0.0.1] avec 32 octets de 
données :
Réponse de 1.0.0.1 : octets=32 temps=42 ms TTL=54


Thierry 

> Le 24 nov. 2021 à 11:45, Erwan David  a écrit :
> 
> Le 24/11/2021 à 09:44, Benjamin Abadie via frnog a écrit :
>>> On 11/23/21 6:09 PM, Vincent Tondellier via frnog wrote:
>>> il n'existe pas a ma connaissance de format compressé pour les ipv4.
>> Il me semble que si :
>> $ ping 1.1
>> PING 1.1 (1.0.0.1) 56(84) bytes of data.
> 
> Il y a même
> 
> $ ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.066 ms
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] RE: BGP et /24

[Thierry Chich]

Je me demande si vous ne vous emballez pas un peu. On peut être connecté à 
Internet sans voir des millions de routes sur son routeur.
Si ça se trouve, il s'agit juste d'annoncer à son fournisseur d'accès 3 4 
routes. Dans ce cas, utiliser un firewall pour faire les annonces BGP n'est pas 
forcément absurde. 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : mardi 26 octobre 2021 20:23
À : Jerome Lien 
Cc : frnog-tech 
Objet : Re: [FRnOG] [TECH] RE: BGP et /24


> Le 26 oct. 2021 à 19:36, Jerome Lien  a écrit :
> 
> Étant un débutant dans ce monde, j'entends les conseils et j'ecoutes 
> les retours d'expériences. Car difficile de bien ce faire conseiller 
> au final sur le choix des équipements d'où ma question ;-)

Pouvoir faire du BGP n’est pas le seul paramètre.
Il faut aussi voir ce qu’on va mettre comme lien.
Pour du sub-1G, on peut faire ça sur à peu près n’importe quoi.
Si un port 10G de transit est nécessaire (mais suffisant pour tenir quelques 
années), ça élimine quelques options.
J’oublierais VyOS et toute autre routeur soft qui n’implémente pas DPDK ou 
équivalent.
Donc plutôt 6Wind (c’est très bien 6Wind).
Après, un ASR1001-X avec 16Go de RAM doit faire le job, mais tu peux pas 
dépasser 3 ports 10G. Après faut prendre un chassis plus gros, ou du HX (arggg 
le porte-monnaie).

> Effectivement, un opérateur ( luxembourgeois) m'a parlé de le faire 
> avec un fortinet... Mais j'étais fort septique…
> 

Ca a aucun sens.
Un Forti avec la RAM pour tenir la full-table, c’est minimum un 500, mais 
plutôt un 1000.
Leur CPU sont optimisés pour le filtrage, mais je doute qu’ils le soient pour 
BGP.
Si le but c’est de faire que du BGP, pourquoi mettre autant de pognon dans un 
firewall ?
Si le but c’est de faire BGP et sécurité, il va y avoir concurrence en 
permanence sur le CPU entre le filtrage et le BGP, et en cas de délire de l’un 
ou de l’autre, ça va pas être beau à voir.
La séparation des fonctions, c’est quand même un principe hyper sympa.
Si Forti a mis du BGP dans les chassis, c’est pas pour en faire un routeur de 
transit, mais plutôt pour iBGP je pense.

Je suis prêt à être contredit, si quelqu’un ose avouer que ses borders sont des 
FG :)


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


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

Re: [FRnOG] [TECH] Passerelle de filtrage de mails à base d'IA ?

[Thierry Chich]

Le 04/03/2021 à 09:32, Stéphane Rivière a écrit :



Accessoirement aussi, les enfants qui n'ont pas été accoutumé à voir des
gens d'autres ethnies avant un certain age seront bien moins performants
pour différencier les visages de l'ethnie en question que les enfants
habitués.

+1 La plupart des blancs sont incapables de distinguer des ethnies
africaines ou simplement des guadeloupéens noirs-afros, noirs-coolies ou
métis.


Ça va bien au -delà. Quelqu'un qui n'a concrètement pas vu de visages de 
chinois avant l'age de 2 ans n'aura jamais la finesse de différenciation 
des visages chinois d'un natif. C'est le fameux "ils se ressemblent 
tous". Mais ce n'est pas une question de racisme ou d'ouverture 
d'esprit, c'est une question de câblage neuronal. On peut progresser 
tardivement, mais jusqu'à un certain point.


Donc que les réseaux neuronaux fassent la même chose, ça n'a rien 
d'étonnant. Ou plutôt si ! Ce qui est étonnant, c'est à quel point 
certains mécanismes sont similaires entre RN et cerveau humain, y 
compris dans les erreurs.


Thierry
--



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

Re: [FRnOG] [TECH] Passerelle de filtrage de mails à base d'IA ?

[Thierry Chich]

Accessoirement, après un auto-entrainement de 3 jours avec la seule 
connaissance des règles, ça bat un champion du monde d'échec et de GO. 
Mais c'est vrai, c'est de la merde.


Accessoirement aussi, les enfants qui n'ont pas été accoutumé à voir des 
gens d'autres ethnies avant un certain age seront bien moins performants 
pour différencier les visages de l'ethnie en question que les enfants 
habitués.


Je n'ai absolument aucun doute sur le fait que des RN sont parfaitement 
capables de faire un travail très correct sur les spams. Le problème 
principal, c'est d'avoir une base suffisante d'apprentissage, et de ce 
point de vue, Google a de l'avance. En demandant à ces utilisateurs de 
classer eux-mêmes les indésirables, ils ont ce qu'il faut depuis 
longtemps. Ils ont d'ailleurs appliqué la même tactique avec les images 
par le biais des capchas : de temps en temps, vous remarquerez que l'on 
vous fait classifier des images et que votre réponse n'a pas 
d'importance. Google a utilisé une partie de notre pouvoir de 
reconnaissance pour nourrir ses bases.


Le vrai problème de l'IA, c'est que n'importe quoi est vendu comme de 
l'IA. Spamassassin, c'est bien, mais c'est pas de l'IA pour l'heure. 
Loin de là.


Quant aux systèmes de sandbox, j'en pense un mal infini dans le cas du 
mail. A partir du moment où les ressources demandées pour se défendre 
sont plusieurs ordres de grandeur supérieures à celles nécessaires à 
l'attaquant, le combat est perdu. S 'il n'arrive pas à vous spammer, il 
vous dossera (du verbe dosser récemment incorporé au dictionnaire de 
l'académie française).



Thierry

Le 03/03/2021 à 11:49, Stéphane Rivière a écrit :

L'IA ne sait pas répondre à cette question fort simple : "Quelle est la
couleur du cheval blanc d'Henri IV ?".

L'Idiotie Artificielle peut être implémentée avec des réseaux de
neurones pour te reconnaître un visage de blanc parmi 1 M visages de
blancs. Et se plantera lamentablement sur les noirs car elle n'aura été
entraînée qu'avec des blancs. Ce qui a d'ailleurs fait des drames.

Mais tu poses une vraie question.

Hormis la VM temporaire avec observation du comportement de la PJ (ce
dernier point démontrant déjà un joli savoir faire), je ne vois pas trop
ce qui peut être sûr.

--



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

Re: [MISC] [FRnOG] [TECH] Téléphonie 3CX

[Thierry Chich]

Bonjour

J'ai découvert le SBC il y a peu. Je n'arrivais pas à comprendre qu'il y 
n'y ait pas de proxy dans ce monde, et mon téléphoniste ne comprenait 
pas ce que je voulais ni de quoi je m'offusquais  (ben quoi, de l'UDP 
ouvert entre tous les postes et tous les téléphones quelque soit leur 
provenance, il est où le problème ?).


Il se trouve que le SBC, c'est un peu un proxy, non ?

Le 02/03/2021 à 16:08, Gaëtan a écrit :

3cx permet d'avoir un sbc dans le lan qui fait passer tous les appels dans un 
tunnel vers le serveur 3cx. Si c'est le cas et que tu as de la qos c'est pas du 
sip. Si y en a pas, sip et le nat c'est toujours fun à dépanner. J'ai gagné en 
tranquilité quand j'ai installé un sbc dans le lan

++

Gaëtan

Le 2 mars 2021 15:15:43 GMT+01:00, Michel KOENIG  a 
écrit :

Bonjour,

J'ai un client qui rencontre de nombreux soucis de qualité de voix avec
sa solution 3CX (en mode Cloud)

Je gère le firewall et le LAN sur ce site et pour moi tout semble OK

On est dans une bataille entre opérateur, prestataire de la solution
3CX et config FW

Quelqu'un a des retour sur ce type d'installation ?

Un mode de test permettant d'isoler l'origine du mal ?

Michel

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

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

--

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/

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

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

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/

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

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/

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

[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: [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] 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]

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

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/

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

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/

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

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

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: [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/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: [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] 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] 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] [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 "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] 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/

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

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]

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