[technique] problèmes d'auto-hébergement

Jeu 14 Juil 21:12:54 CEST 2016

On Thu, 2016-07-14 at 21:07 +0200, Luc Maisonobe via technique wrote:
> Le 14/07/2016 à 20:54, Luc Maisonobe via technique a écrit :
> > Bonjour à tou-te-s,
> >
> > Je suis actuellement confronté à des problèmes d'auto-hébergement que
> > je n'arrive pas à résoudre.
> 
> Voici un petit complément.
> 
> Comme je l'écris ci-dessous, ce message a bien transité par
> mon serveur, en émission puis en réception. Dans les en-têtes,
> je viens de repérer la séquence suivante :
> 
>     Received: from smtp.spaceroots.org (unknown [89.234.156.231])
>     (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
>     No client certificate requested)
>     by mx3.tetaneutral.net (Postfix) with ESMTPS id D5ADC3232B8
>     for <technique at lists.tetaneutral.net>; Thu, 14 Jul 2016 20:54:40 
> +0200 (CEST)
> 
> C'est le unknown [89.234.156.231] qui m'intrigue. Si sur une machine
> à la maison je fais un host 89.234.156.231, j'obtiens :
> 
>    231.156.234.89.in-addr.arpa domain name pointer cavae.spaceroots.org.

De l'exterieur (jai pris une machine Renater) 89.234.156.231 n'a pas de
reverse c'est la source de tes problemes :

dig 231.156.234.89.in-addr.arpa +trace
...
231.156.234.89.in-addr.arpa. 7200 IN	NS	ns.spaceroots.org.
231.156.234.89.in-addr.arpa. 7200 IN	NS	cavae.spaceroots.org.

dig 231.156.234.89.in-addr.arpa @cavae.spaceroots.org
(pas de reponse)
dig 231.156.234.89.in-addr.arpa @ns.spaceroots.org
(pas de reponse)

Laurent

> Je n'ai donc pas smtp.spaceroots.org, bien que ce soit ce que je déclare
> dans le fichier db.231.156.234.89.in-addr.arpa. Avant, il y avait bien
> cavae, mais maintenant j'ai mis smtp pour être sûr que le serveur
> mail soit présenté à l'extérieur sous ce nom. Cela n'a manifestement
> pas marché. Cela pourrait-il être la raison de mes problèmes. La
> conversation 
> <https://community.sophos.com/products/unified-threat-management/f/55/t/44481> 
> mentionne un truc dans ce genre, et j'imagine
> que pour un serveur mail externe, cela pourrait être une raison
> de refuser la connexion.
> 
> Si c'est cela, il faudrait que je trouve un moyen de passer ce nom à 
> "smtp" car mon certificat SSL est valide pour smtp.spaceroots.org,
> pas pour cavae.spaceroots.org.
> 
> Luc
> 
> >
> > En prévision d'un déménagement et d'une perte de connexion internet
> > certainement prolongée, je migre les services d'un petit serveur
> > personnel installé à mon domicile (derrière une ligne ADSL FDN), appelé
> > B3 dna sla suite de ce mail vers le jumeau de ce petit serveur installé
> > à TLS00, donc chez tetaneutral et dénommé cavae dans la suite de ce
> > mail.
> >
> > Les services qui me posent problème dans cette migration sont les
> > DNS et le mail.
> >
> > En ce qui concerne les DNS, mon domaine spaceroots.org déclare
> > actuellement dans db.spaceroots :
> >
> >   3 serveurs de noms
> >     ns chez TTN, b3 chez moi, ns6.gandi.net. chez gandi
> >   2 serveurs de mail
> >     smtp chez TTN, b3 chez moi
> >   des serveurs web annexes
> >     calendar, munin, www, weather ...
> >
> > ns, smtp et cavae sont la même machine, renseigné à chaque fois
> > avec des enregistrements A et AAAA. b3, est une machine renseignée
> > avec des enregistrements A et AAAA. calendar, munin et les autres
> > sont des CNAME.
> >
> > Il faut noter qu'en plus je renseigne de façon identique dans la
> > mesure du possible la page de gestion des DNS de gandi pour mon
> > domaine.
> >
> > Dans mes fichiers db.* de bind, j'ai :
> >
> >  db.2001.910.10e5.ip6.arpa pour l'IPV6 FDN, donc mon domicile
> >  db.2a03.7220.8083.e700.ip6.arpa pour l'IPV6 TTN, à TLS00
> >  db.229.176.67.80.in-addr.arpa pour l'IPV4 FDN
> >  db.231.156.234.89.in-addr.arpa pour l'IPV4 TTN
> >
> > J'ai « l'impression » que ça marche, car diverses commandes
> > dig ou host semblent donner les bons résultats.
> >
> > Cependant, j'ai dans les logs de cavae (donc à TLS00) ces
> > messages  toutes les 5 minutes.
> >
> > Jul 14 20:30:36 cavae named[20208]: error (unexpected RCODE REFUSED)
> > resolving
> > 'e.0.0.0.c.3.2.0.0.0.0.0.0.0.0.0.1.a.0.0.1.0.0.0.0.c.0.b.3.0.a.2.ip6.arpa/PTR/IN':
> > 2400:cb00:2049:1::adf5:3b29#53
> > Jul 14 20:30:36 cavae named[20208]: error (unexpected RCODE REFUSED)
> > resolving
> > 'e.0.0.0.c.3.2.0.0.0.0.0.0.0.0.0.1.a.0.0.1.0.0.0.0.c.0.b.3.0.a.2.ip6.arpa/PTR/IN':
> > 173.245.58.51#53
> > Jul 14 20:30:36 cavae named[20208]: error (unexpected RCODE REFUSED)
> > resolving
> > 'e.0.0.0.c.3.2.0.0.0.0.0.0.0.0.0.1.a.0.0.1.0.0.0.0.c.0.b.3.0.a.2.ip6.arpa/PTR/IN':
> > 2400:cb00:2049:1::c629:dead#53
> > Jul 14 20:30:36 cavae named[20208]: error (unexpected RCODE REFUSED)
> > resolving
> > 'e.0.0.0.c.3.2.0.0.0.0.0.0.0.0.0.1.a.0.0.1.0.0.0.0.c.0.b.3.0.a.2.ip6.arpa/PTR/IN':
> > 173.245.59.41#53
> > Jul 14 20:30:36 cavae named[20208]: error (unexpected RCODE REFUSED)
> > resolving
> > 'e.0.0.0.c.3.2.0.0.0.0.0.0.0.0.0.1.a.0.0.1.0.0.0.0.c.0.b.3.0.a.2.ip6.arpa/PTR/IN':
> > 2400:cb00:2049:1::adf5:3a33#53
> >
> > Les moteurs de recherche mentionnent que cela serait dû à des forwarders
> > (les IP à la fin de la ligne, devant le #53) qui refusent de résoudre la
> > réquête. Cependant, d'une part je n'ai aucune idée de l'origine de cette
> > requête (c'est *toujours* la même), et d'autre part
> > je n'ai aucun forwarder! Mon fichier named.conf a le bloc de la conf
> > d'origine en commentaire :
> >
> >     // forwarders {
> >     //     0.0.0.0;
> >     // };
> >
> > Je ne comprends donc pas ce qui se passe et ce que j'ai mal fait dans
> > mes DNS.
> >
> > Mon second problème, porte sur le mail. C'est celui qui m'embête en
> > fait le plus, car dans quelques jours je déménage et mon serveur à la
> > maison ne répondra plus du tout.
> >
> > J'ai configuré cavae (à TLS00) avec postfix, dovecot, SPF, DKIM, DMARK,
> > sasl ... comme j'avais configuré le mail à la maison, qui marche depuis
> > des années. Une fois la configuration réalisée, j'ai basculé dans les
> > DNS le nom "smtp" de la machine à la maison vers la machine à TLS00,
> > en prenant bien garde d'utiliser des A et AAAA et pas un CNAME (on m'a
> > dit qu'un enregistrement MX ne devait jamais pointer vers un CNAME).
> > J'avais mis des TTL assez courts sur les enregistrements depuis quelques
> > jours, pour faciliter cette transition.
> >
> > J'ai l'impression que seules les machines « proches » (c'est à dire mon
> > réseau à la maison et les machines gérées par TTN) passent bien par
> > le nouveau smtp.spaceroots.org et que celui-ci me transmet bien le
> > mail. Mes essais locaux ont marché, et en fait les deux trois mails
> > qui viennent de passer sur cette liste tetaneutral ainsi qu'un mail
> > de Laurent sont tous passés par mon nouveau serveur. Par contre, les
> > machines « éloignées » (les mails envoyés du bureau, envoyés par mes
> > correspondants ou les services de test automatique de mail sur le net)
> > passent tous systématiquement par l'ancien serveur. Je ne vois en fait
> > même pas de tentative de connection dans les logs, et j'ai vérifié mon
> > pare-feu qui laisse normalement entrer smtp, smtps et imaps. Pourtant,
> > ces machines distantes semblent savoir que smtp.spaceroots.org est
> > la machine à TLS00. J'ai fait un "host" depuis une machine distante
> > pour vérifier, elle connait la nouvelle adresse, mais envoie le
> > courrier par l'ancienne. De plus, le service en ligne
> > <https://mxtoolbox.com/> me donne bien tous mes serveurs mails, et
> > me dit que smtp ne répond pas à la connexion (pourtant je ne vois
> > aucune trace de ses tentatives). Je ne sais pas s'ils essaient le
> > nouveau serveur, qu'il ne répond pas pour une raison que j'ignore,
> > puis ils passent sur l'ancien serveur et là ils résussissent. Ce qui
> > me surprend, c'est que les mails typiquement envoyés sur cette liste
> > (donc pas du tout gérés par moi, mais gérés par tetaneutral) passent
> > tout à fait correctement sur mon serveur. Comme je ne vois strictement
> > aucune trace de ce que tentent les serveurs qui essaient de m'envoyer
> > du courrier, je n'arrive pas à identifier l'erreur.
> >
> > Voilà, si quelqu'un à une idée, je suis preneur. Il faut vraiment que
> > je trouve une solution avant que l'ancien serveur ne soit coupé, lundi
> > soir.
> >
> > cordialement,
> > Luc
> > _______________________________________________
> > technique mailing list
> > technique at lists.tetaneutral.net
> > http://lists.tetaneutral.net/listinfo/technique
> 
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique