Je ne suis pas un expert de tcpdump donc corrigez-moi si je me trompe. Bon d’abord les checksums invalides, c’est parce que leur calcul est/serait offloaded à ta carte réseau (pour des raisons de perf), donc on peut ignorer.
Ensuite on voit bien que ton serveur envoie un paquet SYN de taille 0 à Infomaniak (Flags [S]) :
02:45:55.033301 IP (tos 0x0, ttl 64, id 53229, offset 0, flags [DF], proto TCP (6), length 60)
172.18.0.4.57754 > mail.infomaniak.com.submissions: Flags [S], cksum 0x8f17 (incorrect -> 0x5338), seq 1833280861, win 64240, options [mss 1460,sackOK,TS val 1141911759 ecr 0,nop,wscale 7], length 0
Infomaniak répond avec un SYN+ACK (Flags [S.] - le point veut dire ACK) de taille 0 :
02:45:55.067265 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 60)
mail.infomaniak.com.submissions > 172.18.0.4.57754: Flags [S.], cksum 0xa38f (correct), seq 773621594, ack 1833280862, win 65160, options [mss 1460,sackOK,TS val 772262016 ecr 1141911759,nop,wscale 8], length 0
Et enfin ton serveur termine le 3-way handskake de TCP avec un ACK (Flags [.]) :
02:45:55.067286 IP (tos 0x0, ttl 64, id 53230, offset 0, flags [DF], proto TCP (6), length 52)
172.18.0.4.57754 > mail.infomaniak.com.submissions: Flags [.], cksum 0x8f0f (incorrect -> 0xcecd), seq 1, ack 1, win 502, options [nop,nop,TS val 1141911793 ecr 772262016], length 0
Donc en quelques millisecondes tu as construit une connexion TCP fonctionnelle. Si un firewall avait du se mettre en travers de ta route, il aurait très probablement empêcher ce 3-way handshake de se faire en bloquant un des paquets (probablement le premier SYN tout simplement).
Donc tu as bien un tunnel de donné fonctionnel entre tes deux serveurs. Maintenant que se passe t’il ensuite ? Et bien… pas grand chose. Du moins pendant exactement 5 secondes - soit une éternité pour un réseau - il ne se passe rien du tout.
Et donc exactement 5 secondes plus tard, ton serveur se décide à proprement fermer la connexion TCP avec Infomaniak en envoyant un paquet FIN (Flags [F.]) - et un ACK qui traine - qui indique la fermeture de la connexion TCP :
02:46:00.072597 IP (tos 0x0, ttl 64, id 53231, offset 0, flags [DF], proto TCP (6), length 52)
172.18.0.4.57754 > mail.infomaniak.com.submissions: Flags [F.], cksum 0x8f0f (incorrect -> 0xbb3f), seq 1, ack 1, win 502, options [nop,nop,TS val 1141916798 ecr 772262016], length 0
Et le serveur d’Infomaniak de confirmer la bonne fermeture de la connexion avec un paquet FIN + ACK (Flags [F.]). La connexion est alors officiellement fermée dans le sens ton serveur → Infomaniak :
02:46:00.106689 IP (tos 0x0, ttl 50, id 21024, offset 0, flags [DF], proto TCP (6), length 52)
mail.infomaniak.com.submissions > 172.18.0.4.57754: Flags [F.], cksum 0xa886 (correct), seq 1, ack 2, win 255, options [nop,nop,TS val 772267055 ecr 1141916798], length 0
Et un dernier ACK pour confirmer la fermeture de la connexion dans le sens Infomaniak → ton serveur :
02:46:00.106720 IP (tos 0x0, ttl 64, id 53232, offset 0, flags [DF], proto TCP (6), length 52)
172.18.0.4.57754 > mail.infomaniak.com.submissions: Flags [.], cksum 0x8f0f (incorrect -> 0xa76d), seq 2, ack 2, win 502, options [nop,nop,TS val 1141916832 ecr 772267055], length 0
En résumé :
- Tu ouvres une connexion sans encombre avec Infomaniak
- Il ne se passe rien pendant 5 secondes
- Tu ferme la connexion avec Infomaniak sans encombre
Mon hypothèse : le client attendait que le serveur lui envoie un truc, et quant au serveur, il attendait que le client lui envoie un truc.
Typiquement, dans le cas du TLS implicite (port 465 aka submissions), on peut voir avec un openssl s_client -connect xxxx que c’est au client de commencer à envoyer de la donnée. On voit par exemple sur ce bout de capture que le client, après avoir terminé le 3-way handshake envoie un paquet de 349 octets (Flags [P.] - flag push) qui doit être l’initialisation de la connexion TLS :
17:34:49.040270 IP (tos 0x0, ttl 64, id 44496, offset 0, flags [DF], proto TCP (6), length 52)
rincevent.lan.42908 > scorpio.site.deuxfleurs.fr.urd: Flags [.], cksum 0xc816 (correct), seq 1, ack 1, win 502, options [nop,nop,TS val 2787908762 ecr 1842650114], length 0
17:34:49.040629 IP (tos 0x0, ttl 64, id 44497, offset 0, flags [DF], proto TCP (6), length 349)
rincevent.lan.42908 > scorpio.site.deuxfleurs.fr.urd: Flags [P.], cksum 0x1b1b (correct), seq 1:298, ack
Par contre, si je fais du STARTTLS, je commence avec le protocole en clair SMTP, et dans ce cas c’est au serveur de commencer à envoyer de la donnée. Ici on voit mon client qui termine le 3-way handshake et le serveur d’envoyer directement l’en-tête SMTP (avec un flag push aussi Flags [P.]) :
18:45:04.073710 IP (tos 0x0, ttl 64, id 14136, offset 0, flags [DF], proto TCP (6), length 52)
rincevent.lan.55802 > mail.infomaniak.com.submission: Flags [.], cksum 0xaf19 (correct), seq 1, ack 1, win 502, options [nop,nop,TS val 2282564785 ecr 309300980], length 0
18:45:04.115427 IP (tos 0x0, ttl 50, id 3775, offset 0, flags [DF], proto TCP (6), length 89)
mail.infomaniak.com.submission > rincevent.lan.55802: Flags [P.], cksum 0x2a26 (correct), seq 1:38, ack 1, win 255, options [nop,nop,TS val 309301031 ecr 2282564785], length 37
En-tête qui ressemble à ça :
220 mail.infomaniak.com ESMTP ready
Donc moi votre cas me fait penser que :
- votre client Greenlight a été configuré, d’une manière ou d’une autre, pour du STARTTLS sur le port 465 (ce qui n’est pas du tout du tout standard)
- étant donné le protocole SMTP, votre client Greenlight attend donc que le serveur lui envoie de la donnée
- le serveur a été configuré pour du TLS implicite sur le port 465 (comme il se doit)
- étant donné le protocole TLS, le serveur attend donc que le client lui envoie de la donnée
- rien ne se passe car les deux parties s’attendent mutuellement
- si le client Greenlight ne reçoit aucune donnée pendant 5 secondes alors qu’il s’attend à en recevoir, il timeout
Mon conseil : si vous n’arrivez pas à conigurer Greenlight en 465/submissions/TLS implicite, essayez de le configurer en 587/submission/STARTTLS en mettant SMTP_PORT=587, c’est aussi supporté par Infomaniak.
, attirer l’attention des maintainers sur ton problème.
