Forum Linux.général [RESOLU] Postfix : lost connection after RCPT from gateway.startcom.org

Posté par . Licence CC by-sa
Tags :
1
12
oct.
2013

Bonjour,

suite à cette dépêche j'ai mis en place mon propre serveur mail avec une particularité : il gère des domaines virtuels.

Lors de mes tests, tout fonctionnait pour le mieux aussi bien à la réception qu'à l'envoi: le smtp de free reçoit mes emails de test et les envoie sans encombre au smtp de mon nouveau serveur; les emails envoyés depuis mon smtp vers une adresse gérée par gandi sont reçus sans problèmes (si ce n'est ce $@#! de greylisting qui introduit un délai de 5 minutes entre l'envoi et la réception).
Les auto-répondeurs suggérés dans les commentaires de la dépêche fonctionnent également sans problème.

Je décide donc de générer un certificat signé par startssl et là c'est le drame: pour valider le domaine, startssl doit envoyer un email vers une adresse de ce domaine, ici webmaster@example.com (un alias vers moi@example.com): et bien je suis incapable de recevoir ce courrier puisque la connexion s'interrompt.

Voici le log:

postfix/smtpd[1474]: connect from gateway.startcom.org[212.117.158.94]
postfix/smtpd[1474]: CCC0A2BA073B: client=gateway.startcom.org[212.117.158.94]
postfix/smtpd[1474]: lost connection after RCPT from gateway.startcom.org
postfix/smtpd[1474]: disconnect from gateway.startcom.org[212.117.158.94]

Un courrier envoyé à cette même adresse depuis le smtp de free ne pose pas de soucis.

si je met l'ip 212.117.158.94 dans les debug_peer_list, j'obtiens un peu plus d'info

les lignes suivantes me semblent donner des indices:
179 => le double-bounce et l'adresse double-bounce@mail.example.com qui de toute façon n'est pas définie, ni dans mes utilisateurs, ni dans mes alias
252 => le smtp_get: EOF

Mes recherches dans l'immensité du web n'ont rien donné, et comme je suis incapable de me dépatouiller tout seul, une âme charitable pourrait-elle me dire ce que je fais de mal ?

Au cas où, voici mes fichiers de configuration:
main.cf
master.cf

Merci

  • # même pas un petit indice ?

    Posté par . Évalué à 3.

    40h de stress et toujours rien … ah si ! à cette heure, et au total, une personne a considéré cette question pertinente, mais n'a pas osé se dévoiler !

    Alleeeeeez, soyez sympa !
    Ne serait ce qu'un petit indice, ou alors simplement me dire si les logs fournis sont utiles ou si il faut d'autres infos et comment les obtenir.

    • [^] # Re: même pas un petit indice ?

      Posté par (page perso) . Évalué à 3.

      À ta place, je capturerais le traffic passant par ta carte réseau (tcpdump) pendant une période donnée, pendant laquelle je redemanderais une validation à StartSSL. Puis tu rapatries la capture sur ton poste de travail et tu l’ouvres avec Wireshark (ou un outil du même genre), et tu tentes de comprendre ce qui se passe.

      • [^] # Re: même pas un petit indice ?

        Posté par . Évalué à 2.

        merci je vais tenter

      • [^] # Re: même pas un petit indice ?

        Posté par . Évalué à 2.

        1   0.000000000  212.117.158.94      192.168.XXX.XXX      TCP   74  47907 > smtp [SYN] Seq=0 Win=5840 Len=0 MSS=460 SACK_PERM=1 TSval=3008239109 TSecr=0 WS=128
        2   0.000048000  192.168.XXX.XXX     212.117.158.94       TCP   74  smtp > 47907 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=44490871 TSecr=3008239109 WS=128
        3   0.091151000  212.117.158.94      192.168.XXX.XXX      TCP   66  47907 > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=3008239201 TSecr=44490871
        4   0.099595000  192.168.XXX.XXX     XXX.XXX.XXX.XXX.XXX  DNS   87  Standard query 0x0cc5  PTR 94.158.117.212.in-addr.arpa
        5   0.100168000  XXX.XXX.XXX.XXX.XXX 192.168.XXX.XXX      DNS   177 Standard query response 0x0cc5  PTR gateway.startcom.org
        6   0.100382000  192.168.XXX.XXX     XXX.XXX.XXX.XXX.XXX  DNS   80  Standard query 0x5c3c  A gateway.startcom.org
        7   0.101071000  XXX.XXX.XXX.XXX.XXX 192.168.XXX.XXX      DNS   271 Standard query response 0x5c3c  A 212.117.158.94
        8   0.104673000  192.168.XXX.XXX     212.117.158.94       SMTP  116 S: 220 mail.example.com ESMTP Postfix (Debian/GNU)
        9   0.195484000  212.117.158.94      192.168.XXX.XXX      TCP   66  47907 > smtp [ACK] Seq=1 Ack=51 Win=5888 Len=0 TSval=3008239305 TSecr=44490897
        10  0.195628000  212.117.158.94      192.168.XXX.XXX      SMTP  93  C: HELO gateway.startcom.org
        11  0.195642000  192.168.XXX.XXX     212.117.158.94       TCP   66  smtp > 47907 [ACK] Seq=51 Ack=28 Win=14592 Len=0 TSval=44490920 TSecr=3008239305
        12  0.195748000  192.168.XXX.XXX     212.117.158.94       SMTP  89  S: 250 mail.example.com
        13  0.287033000  212.117.158.94      192.168.XXX.XXX      SMTP  103 C: MAIL FROM:<certmaster@startcom.org>
        14  0.291604000  192.168.XXX.XXX     212.117.158.94       SMTP  80  S: 250 2.1.0 Ok
        15  0.382307000  212.117.158.94      192.168.XXX.XXX      SMTP  100 C: RCPT TO:<webmaster@example.com>
        16  0.387298000  192.168.XXX.XXX     212.117.158.94       SMTP  80  S: 250 2.1.5 Ok
        17  0.478206000  212.117.158.94      192.168.XXX.XXX      TCP   66  47907 > smtp [FIN, ACK] Seq=99 Ack=102 Win=5888 Len=0 TSval=3008239588 TSecr=44490968
        18  0.478776000  192.168.XXX.XXX     212.117.158.94       TCP   66  smtp > 47907 [FIN, ACK] Seq=102 Ack=100 Win=14592 Len=0 TSval=44490991 TSecr=3008239588
        19  0.568667000  212.117.158.94      192.168.XXX.XXX      TCP   66  47907 > smtp [ACK] Seq=100 Ack=103 Win=5888 Len=0 TSval=3008239679 TSecr=44490991
        20  1.202825000  192.116.242.7       192.168.XXX.XXX      TCP   74  60416 > smtp [SYN] Seq=0 Win=5424 Len=0 MSS=1356 SACK_PERM=1 TSval=1763704518 TSecr=0 WS=128
        21  1.202871000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        22  2.200999000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        23  3.201000000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        24  4.201043000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        25  4.204388000  192.116.242.7       192.168.XXX.XXX      TCP   74  [TCP Retransmission] 60416 > smtp [SYN] Seq=0 Win=5424 Len=0 MSS=1356 SACK_PERM=1 TSval=1763705268 TSecr=0 WS=128
        26  5.200998000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        27  6.201004000  12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        28  10.205853000 192.116.242.7       192.168.XXX.XXX      TCP   74  [TCP Retransmission] 60416 > smtp [SYN] Seq=0 Win=5424 Len=0 MSS=1356 SACK_PERM=1 TSval=1763706768 TSecr=0 WS=128
        29  10.205884000 12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        30  11.205002000 12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        31  12.204979000 12:34:56:78:9A:BC   Broadcast            ARP   42  Who has 192.116.242.7?  Tell 192.168.XXX.XXX
        

        Avec mes faibles connaissances en la matière, je me dis que tout se déroule bien jusqu'au RCPT TO et la réponse de mon seveur, puis il y a un changement d'interlocuteur (192.116.242.7 qui fait partie des IPs de startcom, maison mère de startssl) et une demande d'identification qui cherche à envoyer une réponse à mon adresse LAN 192.168.XXX.XXX alors qu'il devrait l'envoyer à mon IP correspondant à mail.example.com.
        J'ai bon ?
        Si c'est le cas, et sachant que j'ai la configuration réseau suivante:

        internet -> example.com (IP externe) -> mail.example.com (192.168.XXX.XXX)
        et mail.example.com étant un container LXC auquel l'hôte example.com forward le traffic SMTP

        cela semble être un problème de configuration de mon réseau non ?

        Comment est ce que cela peut se régler ?

        merci

        • [^] # Re: même pas un petit indice ?

          Posté par (page perso) . Évalué à 3.

          je me dis que tout se déroule bien jusqu'au RCPT TO et la réponse de mon seveur

          Oui. L’établissement de la connexion et le début du dialogue SMTP se font correctement, mais après je ne comprends pas à quoi joue gateway.startcom.org… Une fois le 250 OK reçu en réponse à son RCPT TO, il met fin à la connexion. La terminaison elle-même se fait normalement (FIN, FIN/ACK, ACK).

          On dirait que gateway.startcom.org veut juste vérifier que l’adresse est correcte (ce que ton serveur lui apprend en renvoyant le code 2.1.5, signifiant une adresse de destination valide), mais n’a pas l’intention d’envoyer le mail lui-même. D’où sans doute l’intervention de la seconde machine (192.116.242.7), qui est, je suppose, chargée de l’envoi du mail proprement dit. Mais l’intérêt de cette procédure à deux étapes (une première machine qui se connecte juste pour confirmer l’adresse, puis une seconde pour envoyer effectivement le mail) m’échappe…

          Concernant la tentative de connexion de la seconde machine, je ne comprends pas ce que viennent faire les requêtes ARP. On dirait que ta machine s’attend à ce que 192.116.242.7 soit dans le même réseau qu’elle-même. Un problème de masque de sous-réseau, ou quelque chose de ce genre ? (Disclaimer : ces problèmes-là dépassent mes compétences, donc je dis peut-être une grosse connerie.)

          • [^] # Re: même pas un petit indice ?

            Posté par . Évalué à 1.

            voici mon /etc/network/interfaces :

            auto lxcnet0
            iface lxcnet0 inet static
                    address         192.168.XXX.XXX
                    broadcast       192.168.XXX.255
                    gateway         192.168.XXX.1
                    netmask         255.255.255.0
                    network         192.168.XXX.0
            

            je suppose que c'est la partie broadcast qui pose problème, mais je me suis borné à suivre le tuto debian LXC VLANNetworking, et jusqu'ici tout allait bien pour mes autres containers.
            Par contre je ne vois pas en quoi le modifier: si je ne fais pas d'erreur, dans cette configuration le broadcast est limité à mon réseau privé, donc forcément je ne trouve pas l'adresse mac de 192.116.242.7.

            Comment corriger ce problème ?
            si je met le broadcast à 255.255.255.255, il va chercher tout internet pour la bonne adresse mac et en plus il risque de leaker l'adresse mac virtuelle de mon container, ce qui ne plaira pas à mon hébergeur je pense.

            • [^] # Re: même pas un petit indice ?

              Posté par (page perso) . Évalué à 3.

              la table de routage ?
              la table adresse mac adresse ip ?

              la résolution ip ( 192.116.242.7 ) - arp n'est pas chez toi, si ?

              Système - Réseau - Sécurité Open Source

              • [^] # Re: même pas un petit indice ?

                Posté par . Évalué à 2.

                la résolution ip ( 192.116.242.7 ) - arp n'est pas chez toi, si ?

                aucune idée !

                pour ce qui est de la table de routage, j'ai du mal à comprendre pourquoi il faudrait une route particulière pour ce cas.

                Et comme je ne maitrise pas du tout le sujet, je ne comprend pas non plus pourquoi mon container n'envoie pas son paquet directement à l'adresse IP 192.116.242.7 par la route utilisée par tous les autres paquets (à savoir la gateway 192.168.XXX.1 qui transfert au grand internet), et a besoin de rechercher l'adresse MAC correspondante

              • [^] # Re: même pas un petit indice ?

                Posté par . Évalué à 2.

                cette commande règle le problème

                echo 1 > /proc/sys/net/ipv4/conf/_nom_du_bridge_lxc_/proxy_arp
                

                je suppose qu'elle permet de transférer la requête ARP à la passerelle du container, mais si un connoisseur pouvait m'en dire un peu plus, histoire de ne pas utiliser une solution dont je ne comprendrais pas toutes les conséquences et qui pourrait ouvrir un trou dans mon système, je lui en serait reconnaissant !

                • [^] # Re: même pas un petit indice ?

                  Posté par . Évalué à 2.

                  par curiosité, quel est l'imbécile qui moinse pourquoi moinser le commentaire ci-dessus tout en s'abstenant d'apporter la moindre explication, alors qu'il me semble que celui-ci propose une solution au problème abordé à l'origine ?

                  PS: merci à gouttegd et nono14 pour m'avoir amené sur la voie des requêtes ARP !

                  • [^] # Re: même pas un petit indice ?

                    Posté par (page perso) . Évalué à 3.

                    proxy: le fait d'agir pour une tierce personne.

                    proxy arp: signifie que le proxy tente la résolution arp pour les 2 cotés du pont ethernet

                    segment A ===== [ proxy arp ] ===== segment B

                    si du coté A le proxy reçoit une demande, il la propage de l'autre côté ( B ), et vice versa.

                    Système - Réseau - Sécurité Open Source

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.