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 Anonyme . É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 gouttegd . É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 Anonyme . Évalué à 2.
merci je vais tenter
[^] # Re: même pas un petit indice ?
Posté par Anonyme . Évalué à 2.
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 gouttegd . Évalué à 3.
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 Anonyme . Évalué à 1.
voici mon /etc/network/interfaces :
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 nono14 (site web personnel) . É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 - Ouvert à de nouvelles opportunités
[^] # Re: même pas un petit indice ?
Posté par Anonyme . Évalué à 2.
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 Anonyme . Évalué à 2.
cette commande règle le problème
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 Anonyme . É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 nono14 (site web personnel) . É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 - Ouvert à de nouvelles opportunités
[^] # Re: même pas un petit indice ?
Posté par Anonyme . Évalué à 2.
donc théoriquement ça semble être davantage une solution qu'une source de problèmes potentiels
merci
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.