Ferrero Rocher, Kinder Surprise, Kinder Bueno ! Je tiens à publiquement remercier le fabricant de Nutella pour les merveilleuses inventions qu’il a créées ; la vie m’apporte chaque jour un bonheur supplémentaire et je ne compte plus ma joie lorsque j’ouvre mon Kinder Surprise pour monter le truc en plastique, mais... mais malheureusement... ...récemment... mon chien est devenu aveugle depuis qu’il a mangé le jouet du Kinder ! Las !J’ai donc décidé d’écrire cette lettre ouverte à M. Ferrero Rocher pour qu’il remplace les jouets moisis des Kinder Surprise par des board WRAP ou Soekris – et pour le même prix modique bien entendu – l’intérêt est MULTIPLE !!!!

• pédagogique (oui, un enfant devant un WRAP avec un BSD est un enfant de moins dans les rues !) ;
• psychologique ;
• instructogique ;
• mégalogique ;
• funogique ;
• glandogique.

Les avantages pour M. Ferrero Rocher seraient énormes : il pourrait toucher un plus grand nombre de consommateurs, dans les catégories cibles que sont les ISP, les utilisateurs de salles blanches et de téléphones VoIP tout en conservant ses atouts décisifs dans les cours d’école. Tweaker une WRAP, c’est plus FUN qu’une partie de POG, enfin voilà tu vas gagner de l’argent, plein, M. Ferrero, alors écoute, écoute bien, toi aussi ami du Nutella et toi aussi le borgne qui mange des œufs au fond là-bas...

Pourquoi des Å“ufs Kinder plus gros !

Ils sont trop petits pour des VRAIS jouets !!!! D’abord j’avais rien, enfin rien, j’avais mon p’tit routeur "maggy-knor-rajoute-de-l-eau-c’est-prêt", ensuite j’ai eu envie de faire un projet à la noix, pour passer le temps de manière fun, cela a été l’occasion de refaire mon réseau interne, et je me suis dit alors pourquoi pas un article ! Grave question : pourquoi je me suis fait chier à faire un LAN interne blablabla blablabla ? Pas d’autre motivation que le fun, comprendre et gérer les flux, s’éclater à monter et bidouiller des trucs, améliorer la visibilité et potentiellement la sécurité du LAN. Tout ce qui est nécessaire ne sera pas forcément décrit, _toutes_ les configurations ne seront pas forcément dumpées intégralement, enfin bref, je vais vous présenter une démarche, des concepts initiaux avant de passer à une mise en pratique ! SPUD !! LES SLIDES !!! PASSE À LA SUIVANTE Le rapport avec BSD ?! Hmm, les routeurs sont des p’tits routeurs embedded faits maison, comme pour l’access point, pareil pour le VPN-SSL, etc., et tout tourne avec du BSD à la fraise avec du chocolat dedans. Sachant que je suis un fanatique religieux et que je porte une barbe orange, j’ai principalement utilisé NetBSD. Le rapport avec Kinder Surprise ? M. Ferrero les routeurs sont petits et tiennent dans un œuf. Pour les routeurs, les access points et le serveur VPN, j’ai utilisé du WRAP, la _gateway_ va (sous peu) être une Soekris, le reste est constitué de machines plus ou moins exotiques (Intel, MIPS, Sparc64, etc.). Ca n’est pas gratuit, mais c’est un moyen de bâtir une infrastructure soi-même, avec _TOUS_ les éléments utiles et d’en faire une expérience amusante :) Ca sent l’assouplissant, hmm, hmmm, vous sentez, là, le printemps, la lavande, les cigales, le propre et tout ça ?

Le fantasme, le rêve, le schéma de la conquête du moooOOOonde !

Dans l’architecture finale, la passerelle (GW) s’occupera du NAT et du filtrage interne -> externe et les WRAP ne feront que du routage ainsi que du filtrage interne -> interne.

 

Mis à part les quelques services décrits ci-dessous, ces routeurs se doivent de rester légers et simples.

Le matos

• 1 switch (genre un Xylan 24 ports capable de faire des vlans) ;
• 1 switch "àpacher" (genre un 8 ports Netgear) ;
• 2 WRAP (3 LAN, 1 avec carte Wifi atheros minipci et 1 avec carte crypto hifn(4)) ;
• 1 Soekris (5 LAN avec une hifn(4)) ;
• des câbles, plein ! ;
• du temps, aussi, oui :)

Les pré-requis

• un peu de connaissance de base sur les réseaux ;
• un peu de bidouille et d’espièglerie ;
• un peu de connaissance en code système ;
• des connaissances de base sur l’administration système BSD ;
• les articles du HS BSD Acte I (allez l’acheter ! OSPF, PF, IPSEC, etc.) ;
• du matos (comme décrit ci-dessus) ;
• de la farine, un Å“uf ;
• une poupée vaudou (huuh :)) ;
• une chèvre (en vie !) et un bouc (pour la chèvre et les p’tits poils).

Le plan d'adressage : pourquoi les jouets en plastique c'est dépassé ?

Ne me saoulez pas parce que c’est pas des /30 ou des réseaux plus petits ou plus segmentés ou je ne sais quel truc pour rendre les choses moins lisibles. Maman m’a dit [3] KISS principle, allez, que tout le monde aille lire [2] ARTU, avant de dormir, un bécot et dodo. Alors voilà : GW :

• Inet/PPPoE/PPPoA ;
• 10.9.33.1/24 g Interconnexion/Backbone (wow !).

WRAP #1 :

• 172.16.10.1/24 g wifi network ;
• 10.7.33.1/24 g internal network ;
• 10.4.33.1/24 g service network ;
• 10.9.33.2/24 g Interconnexion/Backbone (p’tain j’me sens plus là !).

WRAP #2 :

• 10.3.33.1/24 g DMZ network ;
• 10.8.33.1/24 g Lab network ;
• 10.16.1.1/24 g VPN network (découpé en /30 en fait mais on y reviendra après) ;
• 10.9.33.3/24 g Interconnexion/Backbone (haha, ça claque de dire ça chez soi).

Sur le switch convivial ça se matérialise comme ça (j’ai fait des ‘tits vlans, des domaines de broadcast séparés pour bien isoler chaque subnet) :

L'installation : le nouveau jouet Kinder !

WRAP/Soekris : N’ayant pas encore reçu mon Soekris, je ne peux encore rien confirmer, mais bon ça ne doit pas être très difficile. Je ne suis – et par conséquent vous n’êtes – pas le premier à faire des installs sur ces trucs-là, y a des milliers de docs sur comment, quoi, où, pourquoi, etc. Référez-y vous si un problème fait son apparition (à moins d’être poisseux, a priori, c’est peu probable :). Alors plusieurs choix sont possibles selon évidemment le matériel que vous allez utiliser. Certains préfèrent le PXE. D’autres, comme moi, sont des grosses feignasses et préfèrent utiliser un lecteur de Compact flash externe USB. Comme j’ai pris une archi toute simple, AMD Geode, de l’Intel compatible, niveau install, pas de prise de tête, je prends ma ‘tite carte Compact flash, je l’insère dans mon lecteur Compact flash USB, hop, je boote mon Laptop en USB and voilà !!! L’install est identique à une install standard à l’exception du fait que vous n’avez pas un disque dur de 250 Go, mais une carte Compact flash de 512 Mo (à quelques Go près), donc essayez d’être économe. Sur les deux WRAP, le partitionnement ressemble à ça : Eh oui, il n’y a pas de partition swap, ces p’tites machines tournant sur des Compact flash avec un nombre d’écritures limité, il faut bien entendu éviter de faire des écritures régulières et intensives (genre syslog) sur le disque. Les options sont là pour illustrer un moyen parmi tant d’autres de restreindre un p’tit peu plus l’usage du disque, mais nous savons que la sécu, c’est bien plus que quelques droits sur une partition, bref... (ça veut dire venez pas me relouter avec SAYNUL SAYPASAYSECURE). Une fois votre petit joujou installé, vous avez un NetBSD standard qui tourne là-dessus. Nous allons commencer par l’access point qui gère également le réseau interne ainsi que le réseau des services internes. Note pour ceux qui ont un lecteur CF N’oubliez pas que le nom des devices pendant votre install et au moment du reboot ne sont PAS les mêmes. Votre WRAP ne rebootera pas si vous ne pensez pas à éditer votre /etc/fstab avant de redémarrer complètement. N’oubliez pas de configurer l’adresse IP du WRAP sur au moins une interface réseau, le série c’est sympa cinq minutes. Pensez à avoir au moins un sshd qui démarre et une IP configurée et routée. On rajoute donc ça : Et ça aussi : Puis ça (rajoutez vos nameservers) : Et finalement ça dans le /etc/rc.conf : Voici également le fichier de configuration du noyau pour les deux [1] WRAP. On va faire tourner un p’tit NetBSD 4.0_BETA2. Tu peux donc compiler tranquille sur ta box et balancer le binaire compilé direct sur le [1] WRAP après son premier reboot. La config quenelle à récupérer ici :

• http://team.gcu-squad.org/~rival/WRAP.ap (pour l’access point de base) ;
• http://team.gcu-squad.org/~rival/WRAP.vpn (pour le server VPN avec hifn(4) ou ubsec(4)) ;
• http://team.gcu-squad.org/~rival/WRAP.local (blah !).

Attention, c’est une config assez générique/safe, elle ne contient PAS les quelques optimisations qui se doivent d’être faites pour un routeur/firewall (mbufs, nmbcluster, tailles des states tables, etc.). Allez maintenant que tes WRAP redémarrent avec ce qu’il faut et un OS du bien et propre on va s’occuper de la conf de chacun d’entre eux.

WRAP #1 : access point et routeur interne #1

Liens : Services network, Internal network, Wifi network On commence simple, la configuration des interfaces : SIP 0 (uplink) : SIP 1 (internal network) : SIP 2 (service network) : ATH0 (wifi network) : Bien évidemment, c’est ce [1] WRAP qui va gentiment distribuer les adresses aux machines qui se connectent sur ton réseau poilu, DHCP est donc activé sur les interfaces gérant le réseau wifi et le réseau interne. Alors pour te faciliter la tâche, je colle une conf DHCP simple et claire, pour le reste dhcpd.conf(5) : Pour être sûr qu’il remplisse bien sa fonction de routeur, il faut évidemment le lui dire. Il y a bien entendu quelques tunings de base pour un fonctionnement correct de l’AP : ou À ce stade, on a un truc à nous, propre (powered by NetBSD) et qui tourne. On va s’occuper de la partie un peu spéciale (wouaaaa, ça brillllleeeee !!!) :

• la configuration de l’access point :

Comme on l’a vu avant, mon interface wifi a pour nom ‘ath0’. Voici la configuration associée dans le fichier /etc/ifconfig.ath0 : Décrivons les paramètres peu courants de cette ligne :

• hostap : mode point d’accès ;
• hidessid : active le SSID cloaking (cela ne rend en _RIEN_ votre access point invisible, tant que vous générez du trafic :) ;
• -apbridge : désactive le dialogue entre les clients du point d’accès.

Plus d’infos là-dedans -> ifconfig(4) (oui, il faut toucher la page, laaaa ouiiii, comme çaaa ouiii... tu sens ?) hostapd(8) : Le daemon hostapd s’occupe de gérer l’authentification et l’accès au périphérique via les standards IEEE802.1X/WPA/WPA2/EAP, etc. En gros, il va donner accès au link-level de ton réseau wifi, donc à ton réseau. Ce daemon est présent par défaut dans l’installation standard de NetBSD, rien à faire, *feign* powered, il faut juste le configurer et lui dire de démarrer au boot. La configuration : Voilà c’est fait, vous avez un access point qui fonctionne en WPA2-PSK avec comme passphrase d’accès ‘this is my elite passphrase :)’. Passer en WPA1 ? Rien de plus simple : wpa=1. Le fichier hostapd.conf par défaut vous donne tous les détails pour vous authentifier via un serveur RADIUS, définir des ACL MAC, etc. Il est franchement convivial et très très simple à comprendre, ceci est bien évidemment un proof-of-concept (wouuuuaaaaaa le mot anglais bien classeeeee), en fait comme vous voyez, c’est super simple, c’est cucul la praline. Message pour Kinder Surprise : offrir des [1] WRAP à monter dans ses œufs au lieu d’offrir des brouettes miniatures à monter soi-même. Maintenant pour que tout reboote bien tranquillou, hopla, on rajoute ça dans le /etc/rc.conf : Et pour être sûr de l’heure, on va se synchroniser sur le ntp local à notre zone, hopla, encore un truc à rajouter : Après ce début de démonstration, il vous sera aisément compréhensible que les gamins et l’association mouflets du 21ème siècle que je représente vous demandent de bien vouloir considérer notre requête ; néanmoins, je vais continuer ma démonstration et vous exposer la suite de ce plan de restructuration qui pourrait faire décoller les ventes de Kinder Surprise EMEA... et p’têt worldwide.

WRAP #2 : VPN Server/Routeur interne #2

Liens : Lab network, DMZ network, VPN network On recommence simple et souple, la configuration des interfaces : SIP 0 (uplink) : SIP 1 (DMZ network) : SIP 2 (service network) : TUN0 (VPN network, elle n’existe pas encore !?!?!?!?!) : On active le routage comme tout à l’heure : NOTE Ne pas oublier /etc/sysctl.conf pour que ça RESTE. Le VPN -> OpenVPN : La fonction de ce [1] WRAP c’est de router, c’est de filtrer, de NAT-er aussi temporairement, on verra pourquoi plus tard. Il fournit également un accès interne au réseau externe. L’avantage est d’avoir un VPN multiplateforme, facile à mettre en œuvre (entendre : sans problèmes d’interopérabilité à la noix) et relativement "safe". Pour cela, d’abord l’installer (et c’est là que vous sacrifiez la chèvre) : Nous allons attribuer une classe d’adresses associée aux utilisateurs VPN. J’ai associé des adresses IP statiques à chacun des utilisateurs ayant besoin d’accéder à certaines machines de mon LAN (je suis aussi un de ces utilisateurs :). Bon, allons directement au fond des choses : voici la configuration, ça facilite toujours le boulot. Ce n’est pas un article sur OpenVPN, ni sur les VPN. Le fichier de config WRAP.vpn contient le support tun(4)/tap(4) nécessaire au fonctionnement d’OpenVPN dans tout type de configuration. Après test, on devrait voir apparaître une interface tun0, etc., (enfin, bref OpenVPN quoi !) un truc comme ça : L’authentification se fait par certificat, signé par mon autorité de certification, pour gérer vos certificats, utilisez tinyCA ou proutCA ou chaispasquoiCA ou ce petit Makefile BSD fait maison, accompagné des fichiers de conf qui vont bien (openssl.cnf, etc., mais c’est pas non plus un article sur la PKI) : # # Little Makefile for handling signing certs requests + creating crl # this Makefile also create initial CA files # # this makefile is inpirated from the idea of jmates # it has been rewritten. # # for UW : # rival@phear.org # # TODO: certificate revocation # # it Uses BSD Makefiles!$ #@!#@! $!@ !@ # # # Some Docs : # 1. create a CA directory # 2. create CA/conf # 3. cp openssl.cnf CA/conf/ # 4. wget -O Makefile http://no.phear.org/codes/misc/Makefile.CA # 5. config CAROOT, OSSL_CONF, OSSL_SERV_CONF variables in the Makefile # 6. make init # You're ready :) # NB: if you want to generate server/clients csr install server.cnf in CA/conf and use 'make gencsr name=<name>' # # Common Use: # Signing a CSR : # 1. put new CSR in CA/csr directory (i.e. filename.csr) # 2. make sign csr=filename.csr # 3. get the cert in CA/cert/filename.cert if the operation is successfull # # OPENSSL=/usr/bin/openssl CAROOT=/home/rival/dev/soul/no.phear.org/CA OSSL_CONF_DIR=$(CAROOT)/conf OSSL_CRL_DIR=$(CAROOT)/crl OSSL_CERTS_DIR=$(CAROOT)/certs OSSL_NEWCERTS_DIR=$(CAROOT)/newcerts OSSL_PRIV_DIR=$(CAROOT)/private OSSL_CSR_DIR=$(CAROOT)/csr OSSL_CONF=$(OSSL_CONF_DIR)/openssl.cnf OSSL_SERV_CONF=$(OSSL_CONF_DIR)/server.cnf all: help list: listcsr listcrt listkey listcrt: @echo 'Listing CERTs:' @cat ${CAROOT}/index.txt listcsr: @echo 'Listing pending CSRs:' @/bin/ls -l ${OSSL_CSR_DIR} listkey: @echo 'Listing private KEY:' @/bin/ls -l ${OSSL_PRIV_DIR} sign: @if [ ! -f $(OSSL_CSR_DIR)/{csr} ]; then echo "{csr} : no such file or directory" ; exit 1 ; fi @$(OPENSSL) ca -config ${OSSL_CONF} -in ${OSSL_CSR_DIR}/{csr} -out ${OSSL_CERTS_DIR}/{csr:.csr=.cert} @[ -s $(OSSL_CERTS_DIR)/{csr:.csr=.cert} ] && rm -P ${OSSL_CSR_DIR}/{csr} # args name= server=yes gencsr: @echo 'Create the CSR for ${name}' @$(OPENSSL) req -config ${OSSL_SERV_CONF} -newkey rsa:2048 -keyout ${OSSL_PRIV_DIR}/${name}.key -keyform PEM -out ${OSSL_CSR_DIR}/${name}.csr -outform PEM @echo 'Create an unlocked CSR key version for ${name}' @$(OPENSSL) rsa < ${OSSL_PRIV_DIR}/${name}.key > ${OSSL_PRIV_DIR}/${name}_unlocked.key gencrl: @$(OPENSSL) ca -config ${OSSL_CONF} -gencrl -out ${OSSL_CRL_DIR}/ca-crl.pem revoke: @$(MAKE) gencrl init: @test ! -f serial @mkdir $(OSSL_CRL_DIR) $(OSSL_NEWCERTS_DIR) $(OSSL_PRIV_DIR) $(OSSL_CSR_DIR) $(OSSL_CERTS_DIR) @chmod 700 $(OSSL_PRIV_DIR) @echo '01' > $(CAROOT)/serial @touch $(CAROOT)/index.txt @$(OPENSSL) req -config $(OSSL_CONF) -days 1825 -x509 -newkey rsa:2048 -out $(CAROOT)/cacert.pem -outform PEM caclean: @echo cleaning CA files @rm -rf $(CAROOT)/cacert.pem $(OSSL_CSR_DIR) $(CAROOT)/index.* $(CAROOT)/serial.* $(OSSL_NEWCERTS_DIR) $(OSSL_PRIV_DIR) $(OSSL_CERTS_DIR) help: @echo make help @echo ' - this help' @echo make init @echo ' - init the CA authority' @echo make list @echo ' - list known key, signed certs (index.txt) & pending CSR' @echo make gencsr name=\<name\> @echo ' - generate a CSR (<name>.csr) & associated key (<name>.key)' @echo ' location CSR: ${OSSL_CSR_DIR}/<name>.csr' @echo ' location KEY: ${OSSL_PRIV_DIR}/<name>.key' @echo make gencrl @echo ' - generate the CRL (Certificate Revocation List)' @echo ' location: ${OSSL_CRL_DIR}/ca-crl.pem' @echo make sign csr=filename.csr @echo ' - sign the filename.csr with CA authority' @echo ' location: ${OSSL_CSR_DIR}/filename.csr' @echo ' result: ${OSSL_CERTS_DIR}/filename.cert' @echo ' csr is automagically deleted.' @echo make revoke cert=filename.cert @echo ' - revoke the filename.cert certificate and generate a new crl'[/crayon]

OpenOSPF (le routage entre tout le monde !)

Ahhhhhhhhh, c’est là que les choses deviennent marrantes :). Alors si vous montez le [1] WRAP avec un OpenBSD pas de souci, [5] OpenOSPF compile sans problème, ça marche out of the box tout ça, tout ça. Si comme dans notre (allez encore de l’anglais) use case, on fait tourner tout sous NetBSD, alors là, y a pas encore de [5] OpenOSPF sous NetBSD. Alors, j’ai fait un petit portage de la version 3.9 d’OpenOSPF (la version 4.0 est en cours de portage aussi, mais j’ai trop de boulot, les structures ont changé entre OpenBSD et NetBSD et j’ai pas terminé pour cet article, oui, je suis fainéant !) Le patch du portage se trouve ici : http://no.phear.org/codes/misc/openospf/ C’est trivial et ça n’a pris que quelques heures. J’ai également fait un pkgsrc, qui se trouve au même endroit, mais il n’est pas tout à fait terminé (il marche quand même, hein, mais il copie pas le script de démarrage comme il faut :), bref... vous avez les billes de base *feign* *feign*. Le but étant d’éviter les routes statiques partout et à maintenir soi-même. À problème simple, solution simple, du routage dynamique, youpi ! Sur chacun des routeurs, je configure OpenOSPF de la manière suivante, avec une area 0. Je redistribue toutes les routes des interfaces connected à tous mes neighbours, sur le VPN je rajoute : pour distribuer les routes statiques provenant des tunnels VPN qui se montent dynamiquement, and voilà !!!! Un joli résultat : et ça de l’autre côté : On mate vite fait les routes sur l’un des deux : Ça marche ! Le troisième et dernier routeur, qui n'est pas encore là (eh oui, je l’ai commandé, mais il est pas encore là), aura exactement la même configuration. Alors c’est pas tout simplet tout ça ?!

Le NAT

Le tout dernier souci à régler avant de pouvoir avoir un truc complètement fonctionnel (dont tous les réseaux arrivent à joindre tous les réseaux) est de permettre à ces réseaux d’accéder (ou NON) à l’internet convivial Ferrero Rocher. Dans mon plan de conquête du monde, tout le trafic de l’interne passerait par un serveur SOCKS local, les autres réseaux utiliseraient également le même SOCKS et aucune translation ne serait effectuée, excepté pour le server SOCKS, je n’en suis pas encore là. En plus, mon routeur ADSL est encore un vieux truc convivial qu’on administre via une page web (USRobotics de mes $#@$!#@), donc pas d’OSPF pour lui, ni rien, je ne contrôle pas mon NAT là-dessus, donc j’ai du NATer au niveau des WRAP en attendant de terminer tout ça. Cet article se conclut donc par ces règles de NAT qui vous permettront d’avoir un réseau fonctionnel avec pleins de trucs kikoo lol qui claquent. Les règles parlant d’elles-mêmes, je n’en dirai pas plus. Voici sur Airprout (wrap #1) : Et voici sur Earthprout (wrap #2) : Oui, oui, je sais, c’est du hack tout laid, mais bon, j’ai pas fini, c’est en cours de finition. Les règles de filtrages sont à déterminer selon VOS besoins (faites une offrande au dieu des firewalls, il vous donnera probablement une réponse), de même que les autres services de base qui se situent dans le "service network" :

• DNS ;
• SOCKS ;
• syslog ;
• tor proxy ;
• Intranet + zabbix, etc.

Reste à faire :

• SNMP v3 ;
• router hardening ;
• OS hardening ;
• etc. ;
• acheter une nouvelle chèvre ;
• acheter des poules ;
• commander un AbdoFlex 3000 ;
• vendre des champignons.

Le test & l'instant Kodak

Du réseau interne : J’atteins donc : La DMZ : Le Lab : L’interco : et tout le reste. Et l’image de l’installation faite maison :

Conclusion

M. Ferrero, cette démonstration faite, tout est désormais entre vos mains. Il me paraît clair que le consommateur est roi dans votre industrie, je vous invite donc à intégrer ces nouvelles données dans la fabrication de vos œufs pour l’année 2008. Je suis sûr que vos profits en ressentiront l’effet salvateur. Je vous prie d’agréer, M. Ferrero, l’assurance de mes sentiments les plus cordiaux et distingués et vous remercie de l’attention portée à ce courrier. Dans l’attente de vous lire en retour, je vous souhaite un bon week-end. (NB : L’important c’est de tripper... et je trippe les Kinder surprises, je les tripperai d’autant plus si y a des trucs gratuits où on peut installer NetBSD dessus, merci de réaliser mes rêves !).

Références [1] WRAP : http://pcengines.ch/wrap.htm [2] The Art of UNIX programming : http://www.faqs.org/docs/artu/ [3] KISS principle : http://www.faqs.org/docs/artu/ch01s07.html [4] NetBSD : http://netbsd.org [5] OpenOSPF : http://www.openbgpd.org/ [6] BSD Acte I, "Répartition de charge et haute disponibilité sur les OS *BSD (Partie 1)", Linux Magazine, hors-série n° 29. [7] BSD Acte I, "Routage dynamique et haute disponibilité (Partie 2)", Linux Magazine, hors-série n° 29. [8] ospfd.conf(5) [9] openvpn(8) [10] hostapd.conf(5) Remerciements

• mes doigts ;
• la lessive (pour des habits qui sentent bon) ;
• mon écran (car il m’affiche des trucs) ;
• la tomate (prout !) ;
• le friand (contre prout !) ;
• GCU (maison !!!!) – I’m loving it
• les relecteurs (Benoyst, Courgette, Wilk, etc.)