Aller au contenu

Messages recommandés

Posté(e)

Si tu fais un nslookup sur ns.mia.lcl tu obtiens quoi?

192.168.0.1 est ton serveur et 192.168.0.5 une autre ressource si je comprends bien?

Dans les liste ip sources tu as bien mis l'adresse 192.168.0.0 ?

Et on sait jamais....Le statut des zones est bien activé? :)

Posté(e) (modifié)
il y a 9 minutes, Spi a dit :

Si tu fais un nslookup sur ns.mia.lcl tu obtiens quoi?

192.168.0.1 est ton serveur et 192.168.0.5 une autre ressource si je comprends bien?

Dans les liste ip sources tu as bien mis l'adresse 192.168.0.0 ?

Et on sait jamais....Le statut des zones est bien activé? :)

Merci Spi pour tes réponses.

 

192.168.0.1 est mon routeur sur lequel le paquet DNS Server est activé.

192.168.0.65 est un raspberry avec une solution domotique dessus.

 

Les listes IP source (dans Résolution, paramètre de la zone et Vue) sont toutes de la sorte :

Capture2.JPG.a695f99fbec1d35b26fbbc42bbc43c1e.JPG

(Le PC avec lesquels je fait les tests est en 192.168.0.25).

 

Le statut de la zone est bien activé.

 

Voici ce que me retourne le nslookup sur ns.mia.lcl

> ns.mia.lcl
Serveur :   UnKnown
Address:  192.168.0.1

*** UnKnown ne parvient pas à trouver ns.mia.lcl : Non-existent domain

 

Modifié par Sartog
Posté(e) (modifié)

@Spi

Au moins ça prouve que les vues font leur travail :biggrin:

Par contre je viens de m'apercevoir qu'il y avait une faute dans mon tuto (personne ne s'en est aperçu) =>

  • Dans ta zone directe, il te manque un enregistrement, le "naked domain" : truc.info A 172.16.1.X

En local ce n'est pas grave, mais en publique il y a 3 enregistrements obligatoires :

  • le SOA : le nas te le créé, mais tu peux/dois l'ajuster
  • les NS (il en faut 2) : ça tu as compris
  • le domaine lui même => si ton domaine est truc.info il faut créer un enregistrement : truc.info A une.adresse.ip.publique

Si l'ip est la bonne, fais pointer tes CNAME dessus plutôt que sur ns.truc.info, c'est plus "esthétique" et ça te permet de bouger le ns sans devoir modifier les autres enregistrements.

Dernier point, en local tu peux mettre des TTL plus court si besoin.

@Sartog

il y a 27 minutes, Sartog a dit :

Je créé ma Zone Master comme indiqué avec le Nom de domaine fictif souhaité (j'ai testé avec .local, .home, .home.lcl, sans succès).

Le 29/01/2017 à 01:58, Fenrir a dit :

nb : il ne faut jamais utiliser le suffixe ".local", même en interne

Utilise plutôt .maison (ou un truc qui a peu de chance d'exister sur Internet).

Mais techniquement, ton .lcl devrait fonctionner de ce que je vois. Par contre il y a peut être une subtilité avec le RT, il doit probablement faire serveur DNS cache par défaut, il y a peut être un conflit (ssh : netstat -luntp | grep 53). À tout hasard, dans la conf il doit bien y avoir un endroit où tu configures ses serveurs DNS à lui (en tant que client), demande lui d'utiliser 127.0.0.1 pour tester

Modifié par Fenrir
Posté(e)

@Fenrir

Merci pour les précisions! Mais du coup justement je ne peux actuellement pas créer cet enregistrement car je ne suis pas en ip fixe... J'utilise le DDNS d'OVH et j'attends de changer de provider pour voir si je pourrais avoir une ip fixe, du coup en attendant je ne peux pas le créer.

@Sartog

Je n'avais pas compris que tu étais sur un routeur, je t'avoue que je ne les connais pas du coup je manque un peu de vue sur le sujet... Il y'a un routeur et un Syno en fait? Avec le DNS géré par le routeur?

Posté(e) (modifié)
il y a 29 minutes, Fenrir a dit :

 

@Sartog

Utilise plutôt .maison (ou un truc qui a peu de chance d'exister sur Internet).

Mais techniquement, ton .lcl devrait fonctionner de ce que je vois. Par contre il y a peut être une subtilité avec le RT, il doit probablement faire serveur DNS cache par défaut, il y a peut être un conflit (ssh : netstat -luntp | grep 53). À tout hasard, dans la conf il doit bien y avoir un endroit où tu configures ses serveurs DNS à lui (en tant que client), demande lui d'utiliser 127.0.0.1 pour tester

Merci Fenrir pour ta réponse.

 

Pour le .local, oups !! Heureusement que je suis passé sur autre chose rapidement.

Pour le netstat, voici le résultat :

HomeRouteur1> netstat -luntp | grep 53
tcp        0      0 192.168.4.1:53          0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 192.168.0.1:53          0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 192.168.2.1:53          0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 IPExterne:53       0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN                                                                                              14544/named
tcp        0      0 ::%8:53                 :::*                    LISTEN                                                                                              14544/named
udp        0      0 192.168.4.1:53          0.0.0.0:*                                                                                                                   14544/named
udp        0      0 192.168.0.1:53          0.0.0.0:*                                                                                                                   14544/named
udp        0      0 192.168.2.1:53          0.0.0.0:*                                                                                                                   14544/named
udp        0      0 IPExterne:53       0.0.0.0:*                                                                                                                   14544/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                                                                                                                   14544/named
udp        0      0 127.0.0.1:31067         0.0.0.0:*                                                                                                                   32539/vpnauthd
udp        0      0 127.0.0.1:31068         0.0.0.0:*                                                                                                                   32539/vpnauthd
udp        0      0 0.0.0.0:38350           0.0.0.0:*                                                                                                                   4153/avahi-daemon:
udp        0      0 192.168.0.1:5351        0.0.0.0:*                                                                                                                   22781/miniupnpd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                                                                                                                   4153/avahi-daemon:
udp        0      0 ::%1:53                 :::*                                                                                                                        14544/named

Le 192.168.4.1 est un réseau invité imposé par le RT.

Le 192.168.2.1 est le réseau WAN 2 qui ne sert que de connexion de secours en cas de perte de l'ADSL).

 

Pour le paramétrage des serveurs DNS, je n'ai trouvé que 2 endroits (et impossible d'y mettre 127.0.0.1) :

Capture3.JPG.f871da47c7a7bf45858c89ecac285e97.JPGCapture4.JPG.467f99732a24a728349510b8b89f184d.JPG

Modifié par Sartog
Posté(e) (modifié)

Tu n'as pas fais le netstat en root, du coup il manque une colonne. Celle du "p" pour avoir les process associés

Refais la commande en root (ou avec sudo), puis coupe le paquet DNS server et relance la commande.

Pour les DNS externes, évite d'utiliser ceux de Google ou de Cisco (=opendns), ceux de FDN sont bien plus propres.

(et en passant, supprime ton adresse IP publique des commandes)

Modifié par Fenrir
Posté(e) (modifié)
il y a 14 minutes, Fenrir a dit :

Tu n'as pas fais le netstat en root, du coup il manque une colonne.

Refais la commande en root (ou avec sudo), puis coupe le paquet DNS server et relance la commande.

Pour les DNS externes, évite d'utiliser ceux de Google ou de Cisco (=opendns), ceux de FDN sont bien plus propres.

(en passant, supprime ton adresse IP de commandes)

Merci Fernrir pour le rappel concernant l'IP Publique que j'avais laissé !

 

Sudo n'existe pas sur le RTT, mais je suis bien connecté en root par contre.

Voici le résultat avec le paquet activé puis le paquet désactivé :

---- PAQUET DNS SERVER : START ----

HomeRouteur1> netstat -luntp | grep 53
tcp        0      0 192.168.4.1:53          0.0.0.0:*               LISTEN      14544/named
tcp        0      0 192.168.0.1:53          0.0.0.0:*               LISTEN      14544/named
tcp        0      0 192.168.2.1:53          0.0.0.0:*               LISTEN      14544/named
tcp        0      0 IP.Externe.133:53       0.0.0.0:*               LISTEN      14544/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      14544/named
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      14544/named
tcp        0      0 ::%8:53                 :::*                    LISTEN      14544/named
udp        0      0 0.0.0.0:35360           0.0.0.0:*                           23193/avahi-daemon:
udp        0      0 192.168.4.1:53          0.0.0.0:*                           14544/named
udp        0      0 192.168.0.1:53          0.0.0.0:*                           14544/named
udp        0      0 192.168.2.1:53          0.0.0.0:*                           14544/named
udp        0      0 IP.Externe.133:53           0.0.0.0:*                           14544/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           14544/named
udp        0      0 127.0.0.1:31067         0.0.0.0:*                           32539/vpnauthd
udp        0      0 127.0.0.1:31068         0.0.0.0:*                           32539/vpnauthd
udp        0      0 IP.Externe.255:137          0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.133:137          0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.255:137       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.1:137         0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.255:137       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.1:137         0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.255:138          0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.133:138          0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.255:138       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.1:138         0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.255:138       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.1:138         0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           23193/avahi-daemon:
udp        0      0 ::%1:53                 :::*                                14544/named


---- PAQUET DNS SERVER : STOP ----

HomeRouteur1> netstat -luntp | grep 53
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3114/dnsmasq
tcp        0      0 ::%8:53                 :::*                    LISTEN      3114/dnsmasq
udp        0      0 0.0.0.0:35360           0.0.0.0:*                           23193/avahi-daemon:
udp        0      0 0.0.0.0:53              0.0.0.0:*                           3114/dnsmasq
udp        0      0 127.0.0.1:31067         0.0.0.0:*                           32539/vpnauthd
udp        0      0 127.0.0.1:31068         0.0.0.0:*                           32539/vpnauthd
udp        0      0 IP.Externe.255:137          0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.133:137          0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.255:137       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.1:137         0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.255:137       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.1:137         0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.255:138          0.0.0.0:*                           23153/nmbd
udp        0      0 IP.Externe.133:138          0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.255:138       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.0.1:138         0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.255:138       0.0.0.0:*                           23153/nmbd
udp        0      0 192.168.2.1:138         0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           23153/nmbd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           23193/avahi-daemon:
udp        0      0 ::%1:53                 :::*                                3114/dnsmasq

 

Modifié par Sartog
Posté(e)

Première chose, pas demain la veille que je conseillerais un RT. Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... :evil: (j'ose espérer que le fw bloque bien le trafic)

À première vu, dnsmasq est remplacé par bind (named), donc il ne devrait pas y avoir de conflit à ce niveau (sauf nat farfelu de la part de syno, mais j'en doute)

C'est donc un souci de conf (de ta part ou de celle de syno).

Le souci c'est que si le paquet est comme celui de DSM, la conf est éclatée en plein de fichiers dans : /volume1/@appstore/DNSServer/named/etc

Le fichier d'entrée est named.conf, ensuite il faut suivre les includes (attention, tu es dans un chroot, donc /etc = /volume1/@appstore/DNSServer/named/etc). La conf de bind est très facile à lire, tu devrais la comprendre aisément.

Tu peux aussi tester le nslookup directement depuis le syno en ssh :

  • nslookup
  • server 192.168.0.1
  • nas-forum.com
  • ns.mia.lcl

Comme je n'ai jamais eu ce routeur entre les mains, je peux difficilement t'aider plus via le forum.

Posté(e)
Il y a 11 heures, Fenrir a dit :

Première chose, pas demain la veille que je conseillerais un RT. Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... :evil: (j'ose espérer que le fw bloque bien le trafic)

À première vu, dnsmasq est remplacé par bind (named), donc il ne devrait pas y avoir de conflit à ce niveau (sauf nat farfelu de la part de syno, mais j'en doute)

C'est donc un souci de conf (de ta part ou de celle de syno).

Le souci c'est que si le paquet est comme celui de DSM, la conf est éclatée en plein de fichiers dans : /volume1/@appstore/DNSServer/named/etc

Le fichier d'entrée est named.conf, ensuite il faut suivre les includes (attention, tu es dans un chroot, donc /etc = /volume1/@appstore/DNSServer/named/etc). La conf de bind est très facile à lire, tu devrais la comprendre aisément.

Tu peux aussi tester le nslookup directement depuis le syno en ssh :

  • nslookup
  • server 192.168.0.1
  • nas-forum.com
  • ns.mia.lcl

Comme je n'ai jamais eu ce routeur entre les mains, je peux difficilement t'aider plus via le forum.

Bonjour Fenrir et, une nouvelle fois, merci pour tes réponses.

 

J'ai profité d'un voyage en train ce matin pour me remettre sur ce problème (en VPN) et tester le nslookup en ssh, et là ça fonctionne ....

Du coup, je test de nouveau sur mon PC le nslookup ... ça fonctionne ...

Je tape jeedom.mia.lcl dans l'explorateur web ... ça fonctionne ...

Apparemment, la nuit porte conseil aussi pour le RT :lol: 

Je verrais ce soir, en local, si ça fonctionne également.

 

Citation

Un routeur/firewall grand public qui laisse le netbios écouter coté WAN ... :evil: (j'ose espérer que le fw bloque bien le trafic)

Je ne m'y connais pas en netbios, donc je ne sais pas ce que cela génère comme risque.

Pour le FW, je ne suis pas expert non plus dans ce domaine, mais en comparaison de ce que j'avais avant, je peux dire que c'est une passoire et que les règles servent à boucher les trous de cette dernière :cry: J'essais de le rendre le plus étanche possible.

Posté(e)

@Sartog

Peut-être tout simplement que ton cache sur le pc ne s'était pas encore mis à jour et que du coup il ne demandait pas l'info au routeur? Quand tu fais des modifs sur le paquet et que tu testes depuis un pc tu peux toujours utiliser ipconfig /flushdns pour vider ce cache et être sur qu'il monte bien chercher l'info sur le DNS. :)

@Fenrir

J'étais un peu fatigué hier soir et en relisant ton dernier message sur ma config il me vient un doute, concernant l'enregistrement naked domain. Il y a donc toujours une erreur dans ma config? Même si ce n'est pas grave au niveau local autant faire un truc propre et prendre les bonnes habitudes, du coup si je dois modifier quelque chose tu peux me le préciser stp? Merci d'avance!

Posté(e)

nslookup n'utilise pas le cache local normalement

Rajoute juste un enregistrement de type A qui pointe sur ton ip est dont le nom est le domaine géré :

Il y a 22 heures, Fenrir a dit :

Dans ta zone directe, il te manque un enregistrement, le "naked domain" : truc.info A 172.16.1.X

 

Posté(e) (modifié)

172.16.1.1 dans mon cas, qui est l'ip de mon Syno où est le DNS, correct?

Et si à un moment j'ai une ip fixe je remplacerais cet enregistrement par l'ip fixe côté WAN?

Modifié par Spi
Posté(e)

Bon, malheureusement le test en local n'est pas concluant :cry:

Le plus "drôle" : en local chez moi, je me connecte en VPN chez moi (donc je sors pour re-rentrer), et bha là ça fonctionne :surprised:

 

Il faut que j'aille voir les fichier de conf, comme tu l'as indiqué Fenrir, parce que là je ne comprends pas.

Posté(e)

@Spi

tu peux mettre l'IP de ton choix, ça n'a d'importance que si tu te sers de ce nom.

@Sartog

à ta place je commencerai par vérifier les filtres car en relisant ce que tu as posté, je m'aperçoit que tu n'as pas respecté mes reco, j'ai recommandé de mettre 4 réseaux, ce n'est pas un hasard :

06.png

03.png

et

13.png

14.png

idem coté firewall

Pas certain que ça soit la cause de ton problème, mais quand ça fonctionne depuis un point A mais pas depuis un point B, toutes choses égales par ailleurs, c'est généralement qu'il y a un filtrage sur B.

Posté(e) (modifié)

Dernière petite question pour moi me concernant... Je n'avais pas pensé à quelque chose mais en mettant le serveur DNS je ne peux plus accéder à mon deuxième nas. :/

Il n'est géographiquement pas au même endroit que l'autre, du coup pas le même LAN...

srv01.domaine.com | srv02.domaine.com

Les deux sur DDNS OVH, qu'est-ce que je dois faire pour pouvoir le contacter de nouveau? Dans le DHCP les deux DNS configurés sont le Syno et 80.67.169.12, qui apparemment ne se met pas aussi vite à jour que les autres DNS. :/ Je peux peut-être faire une redirection spéciale pour ce domaine là seulement?

Modifié par Spi
Posté(e)

Je suis perdu là, sur ovh j'ai configuré le domaine srv02.domaine.com, il faut créer un identifiant/pass et dans le Syno dans l'onglet accès externe j'ai ajouté OVH comme provider DDNS avec ces identifiants.
Mais dans le DNS, je ne peux rien lui rajouter, je n'ai pas une ip ou autre vers laquelle me diriger. Du coup j'ai manqué une info. ^^

Posté(e)

Tu as mal compris ma réponse, mais j'ai mal compris ton problème.

Admettons ceci :

  • ton domaine est : domaine.com
  • ton ddns est : srv02.autre.chose
  • => tu fais un alias (CNAME) de srv02.domaine.com vers srv02.autre.chose

Par contre, si ton dyndns est aussi en exemple.com, alors il faut être plus malin :biggrin:.

C'est très facile à faire, mais très long à expliquer, le principe est celui que j'utilise ici : http://www.nas-forum.com/forum/topic/55206-tuto-dns-server/?do=findComment&comment=1319318099

3 manières de faire (au choix même si elles peuvent fonctionner de concert) :

  • tu créés une zone srv02.domaine.com (ce nom en entier) de type forward et comme redirecteur tu indiques les NS d'OVH
  • dans ta zone domaine.com, tu indiques que les NS de srv02.domaine.com (ce nom en entier) sont ceux d'OVH
  • tu créés une zone srv02.domaine.com (ce nom en entier) de type direct et tu indiques dedans que les NS sont ceux d'OVH

Dans un cas comme dans l'autre, il faut régler les vues en mettant cette zone en prioritaire par rapport à la zone domaine.com (donc au dessus dans la liste).

Si tu comprends bien les 3 méthodes et que tu es capable de les appliquer, c'est que tu as franchi un palier dans ton apprentissage du DNS (au sens architecture du terme).

Posté(e)

Parfait j'ai level up!!

Je cherchais justement cette notion de forwarder (à la base j'avais fait quelques labos avec des DNS sur Windows Server), j'ai testé les deux premières et ça marche au poil.
Finalement j'ai gardé la deuxième (qui ne nécéssite pas de changer les vues), parce-que sinon la commande nslookup ne donnait plus le nom du serveur DNS!

Tout beau tout propre niveau config, merci!

Posté(e) (modifié)

Bonjour,

Tout d'abord merci pour ce tuto Fenrir, j'ai enfin pu mettre en place un serveur DNS fonctionnel.
Du moins en partie... car le wifi n'est pas impacté par la zone DNS mais tout fonctionne bien sur mon PC branché en ethernet.

Donc quand je me connecte avec mon smartphone en wifi, je vois bien l'ip du téléphone (192.168.1.5) qui a été donnée par le DHCP du syno et avec l'ip du nas (192.168.1.1) comme DNS primaire.
Mais si je tape nas.home, ça me dit adresse introuvable. Si je tape l'ip du nas, c'est ok.

Si je fais un lookup sur nas.home, ça me retourne :
A: ns.home./192.168.1.1
CNAME: nas.home. ns.home.

Si je fais un ping sur nas.home, pas de retour.

J'ai fait ces tests avec l'application android DNS tools.
Je me demande comment c'est possible qu'un lookup trouve l'ip associé à nas.home mais que le ping ne fonctionne pas ?

 

Modifié par Keverage
Posté(e) (modifié)

J'ai réfléchi un bon moment avant de me rappeler d'un truc => Je pense que c'est tout simplement ton ordiphone qui ne se sert pas des DNS envoyés par le DHCP, mais utilise des DNS codés en dur (au hasard, ceux de Google). Certaines versions d'android on ce détestable comportement.

Je n'y fais jamais attention chez moi car j'intercepte toutes les requêtes DNS sortantes et les redirige vers mes propres serveurs.

Tu as 5 possibilités dans ce cas (aucune n'est simple, merci Google :evil:) :

  1. fixer les DNS manuellement, mais ça impose aussi de fixer l'IP :confused:
  2. utiliser un vrai nom de domaine combiné à des vues
  3. intercepter le trafic DNS vers 8.8.8.8 et 8.8.4.4 pour le rediriger vers ton nas
  4. configurer ton android pour passer par un vpn (celui du nas par exemple), dans ce cas la conf dns semble respectée
  5. si ton téléphone est rooté, tu as des applis qui permettent de changer les DNS

Si tu trouve une autre manière de faire (je n'ai pas beaucoup cherché), n'hésites pas à nous en faire part.

------------

Même si ce n'est probablement pas la cause de ton problème, le .home fait parti des tld que j'éviterai d'utiliser pour des questions de sécurité, plutôt qu'un long discours, un article : https://umbrella.cisco.com/blog/blog/2014/04/23/malicious-gtld-squatting/

Il n'existe que 4 tld dispo pour un usage interne : .test, .example, .invalid et .localhost

En pratique, même si dans mon tuto je n'ai été très loquace à ce sujet, il vaut mieux utiliser un vrai nom de domaine de premier niveau ou de second niveau (lan.monvraidomaine.fr). J'ai éditer mon tuto pour être plus explicite à ce sujet.

Modifié par Fenrir

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.