[technique] problèmes d'auto-hébergement
Luc Maisonobe
luc at spaceroots.org
Jeu 14 Juil 21:07:00 CEST 2016
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.
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
Plus d'informations sur la liste de diffusion technique