Problème réseau serveur injoignable

Support Debian
, ,
Tags: #<Tag:0x00007f63e5981f48> #<Tag:0x00007f63e5981e58> #<Tag:0x00007f63e5981d68>
#1

Bonjour à tous

J’ai un serveur de mail qui tourne avec iRedMail en production mais il semblerait que j’ai un soucis réseau sur ce serveur.

Typiquement j’ai des mails qui partent en connection timed out sur certain domaine parce que il arrive pas à les joindre.

J’ai fais deux essais :

Premier essai sur mon serveur de mail :

sudo traceroute -n -T -p 25 mx1.computop.com
traceroute to mx1.computop.com (213.155.65.81), 30 hops max, 60 byte packets
 1  152.228.208.1  0.611 ms  0.558 ms  0.519 ms
 2  192.168.143.254  0.490 ms  0.472 ms  0.456 ms
 3  10.224.153.62  0.440 ms  0.426 ms  0.484 ms
 4  10.224.137.126  0.468 ms  0.453 ms 10.224.137.124  0.438 ms
 5  10.224.138.30  0.422 ms 10.224.136.18  0.408 ms 10.224.136.12  0.392 ms
 6  10.17.151.116  0.604 ms 10.17.155.56  0.808 ms 10.17.146.0  0.776 ms
 7  10.73.0.226  0.393 ms 10.73.0.76  0.380 ms 10.73.0.126  0.364 ms
 8  178.33.99.149  0.348 ms  0.337 ms  0.314 ms
 9  10.73.0.24  0.330 ms  0.408 ms  0.602 ms
10  * 10.95.33.8  4.074 ms  4.349 ms
11  213.186.32.213  8.915 ms  8.850 ms  8.998 ms
12  10.200.0.13  8.836 ms  8.881 ms  8.867 ms
13  80.81.193.88  9.167 ms 80.81.192.88  9.070 ms 80.81.193.88  9.159 ms
14  62.128.0.126  9.275 ms  9.485 ms  9.439 ms
15  62.128.0.154  16.229 ms 213.95.0.110  16.347 ms 62.128.0.154  18.724 ms
16  * 62.128.0.154  16.411 ms  16.283 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

et un second sur un autre serveur (deux machines virtuelles différente chez le même fournisseur) qui la semble bien fonctionner :

traceroute -n -T -p 25 mx1.computop.com
traceroute to mx1.computop.com (213.155.65.81), 30 hops max, 60 byte packets
 1  51.254.128.1  0.617 ms  0.590 ms  0.585 ms
 2  192.168.143.254  0.577 ms  0.571 ms  0.563 ms
 3  51.255.249.254  0.556 ms  0.548 ms  0.542 ms
 4  10.97.155.87  0.533 ms 10.97.155.53  0.517 ms 10.97.155.87  0.503 ms
 5  10.17.134.24  0.968 ms 10.17.134.32  1.109 ms 10.17.136.58  1.084 ms
 6  10.73.0.206  0.517 ms 10.73.1.112  0.250 ms 10.73.2.30  0.248 ms
 7  178.33.99.149  0.461 ms  0.527 ms  0.525 ms
 8  10.73.0.30  0.442 ms  0.509 ms  0.506 ms
 9  10.95.33.10  1.724 ms  1.816 ms  4.459 ms
10  91.121.131.19  9.351 ms  8.987 ms  9.196 ms
11  10.200.0.15  8.802 ms  8.768 ms 10.200.0.19  8.913 ms
12  80.81.192.88  9.010 ms 80.81.193.88  9.278 ms 80.81.192.88  8.999 ms
13  213.95.0.110  16.242 ms  16.334 ms  16.331 ms
14  213.95.0.110  16.322 ms  16.169 ms  16.143 ms
15  62.128.0.154  16.275 ms *  16.244 ms
16  * * *
17  213.155.65.81  16.513 ms  16.477 ms  16.360 ms

Du coup… je me demande où chercher / pourquoi / comment ? Quelqu’un saurait m’aiguiller ? Je ne sais pas par où commencer.

Merci d’avance,

#2

Hello @AnGe7

Je viens de fouiller dans mes archives car cela m’a rappelé un problème similaire* rencontré en 2019.
*accès ssh entre mes différents serveurs situés à des endroits différents.

Je suppose, comme moi à l’époque, que tu n’as fait, a priori, aucune modif dans tes serveurs.

En ce qui me concerne, j’en ai conclu, en utilisant un vpn pour changer mon pays d’origine, que c’était un problème (volontaire ou non) chez mon fournisseur d’accès. Sans l’option -n (et en augmentant le nombre de hops dans ton cas ) je voyais bien que le blocage était sur une serveur sfr.

Par contre ce n’était pas aussi critique que toi, je pouvais contourner le pb,l’accès ssh fonctionnait dans l’autre sens et je n’ai pas essayé de joindre le service client … qui n’aurait probablement rien compris cependant :slight_smile:

Dans mes archives je n’ai pas noté si le problème a disparu « tout seul » et comme j’ai changé de FAI je ne peux pas dire combien de temps cela a duré.

#3

C’est curieux, en effet, le saut 15 est le même pour les deux, mais le premier ne va pas plus loin.
Est-ce que tu sais si tes deux machines virtuelles sont hébergées dans le même centre de données ?

#4

Les deux sont à Gravelines (OVH)

#5

Tes deux serveurs sont dans des réseaux publics différents.
Si l’on p eut reconnaitre des routeurs d’interconnexion dans les traceroutes, le choix des chemins peut être lié:

  • d’une part au sous-réseau d’origine, qui n’a pas les même passerelles probablement
  • d’autre part et lié au précédent, les règles de routages sont différentes selon qu’on passe par ces passerrelles différentes et de la source d’origine.
  • l’un est peut etre libre au niveau de l’accès port 25 et pas l’autre. Il y a des hébergeurs qui filtrent (notamment sur des critères de hops: si trop de hop, alors ça bloque, ou tout simplement du fait du TTL ou de la classe de service).
  • les routages automatiques comme OSPF et autres, peuvent aussi parfois dépasser le nombre de hops

Ce ne sont que des hypothèses. On voit bien les points de passages obligés (192.168.143.254, 10.73.0.226, 80.81.193.88, 62.128.0.154).

Qu’est-ce que cela donne avec l’option -e pour avoir les extensions icmp.
Assaye aussi le cas échéant avec --back pour voir si le résultat diffère en faisant le trajet dans l’autre sens.
Enfin essaye avec l’option -A pour voir les AS.

#6

Merci pour votre aide,

Avec l’option -e :

traceroute -e -n -T -p 25 mx1.computop.com
traceroute to mx1.computop.com (213.155.65.81), 30 hops max, 60 byte packets
 1  152.228.208.1  0.838 ms  0.633 ms  0.595 ms
 2  192.168.143.254  0.565 ms  0.537 ms  0.507 ms
 3  10.224.153.62  0.477 ms  0.448 ms  0.500 ms
 4  10.224.137.124  0.472 ms 10.224.137.126  0.446 ms 10.224.137.124  0.413 ms
 5  10.224.136.16  0.381 ms 10.224.138.30  0.353 ms 10.224.136.14  0.326 ms
 6  10.17.155.60  0.718 ms 10.17.149.118  0.837 ms  0.786 ms
 7  10.73.0.188  0.710 ms 10.73.0.122  0.695 ms 10.73.1.34  0.680 ms
 8  178.33.99.149  0.663 ms  0.647 ms  0.629 ms
 9  10.73.0.24  0.610 ms  0.647 ms  0.635 ms
10  10.95.33.8  1.611 ms  1.597 ms  1.584 ms
11  213.186.32.213  9.334 ms  9.271 ms  8.977 ms
12  10.200.0.13  8.870 ms 10.200.0.17  8.900 ms 10.200.0.13  8.834 ms
13  80.81.192.88  9.056 ms 80.81.193.88  9.167 ms 80.81.192.88  9.152 ms
14  62.128.0.126 <MPLS:L=296,E=0,S=1,T=1>  9.608 ms  9.595 ms  9.583 ms
15  213.95.0.110 <MPLS:L=1378,E=0,S=1,T=1>  16.462 ms 62.128.0.154  16.407 ms 213.95.0.110 <MPLS:L=1378,E=0,S=1,T=1>  16.142 ms
16  * 62.128.0.154  16.599 ms  16.460 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

avec l’option --back

traceroute --back -n -T -p 25 mx1.computop.com
traceroute to mx1.computop.com (213.155.65.81), 30 hops max, 60 byte packets
 1  152.228.208.1  0.772 ms  0.725 ms  0.709 ms
 2  192.168.143.254  0.695 ms  0.681 ms  0.667 ms
 3  10.224.153.62  0.653 ms  0.639 ms  0.680 ms
 4  10.224.137.124  0.666 ms  0.653 ms 10.224.137.126  0.650 ms
 5  10.224.138.28  0.627 ms 10.224.136.18  0.649 ms 10.224.138.28  0.611 ms
 6  10.17.146.0  1.530 ms 10.17.155.62  0.758 ms  1.303 ms
 7  10.73.0.184  0.640 ms 10.73.1.34  0.627 ms 10.73.1.38  0.614 ms
 8  178.33.99.149  0.599 ms  0.586 ms  0.573 ms
 9  10.73.0.24 '-7'  0.559 ms  0.501 ms  0.481 ms
10  10.95.33.8 '-8'  2.106 ms  2.093 ms  2.217 ms
11  213.186.32.213 '-9'  9.462 ms  8.915 ms  8.888 ms
12  10.200.0.17 '-10'  9.077 ms  9.327 ms 10.200.0.13 '-10'  8.933 ms
13  80.81.192.88  9.296 ms  9.283 ms  9.272 ms
14  * * 62.128.0.126 '-13'  9.751 ms
15  213.95.0.110 '-14'  39.768 ms  38.735 ms 62.128.0.154  18.283 ms
16  * 62.128.0.154 '-15'  16.488 ms  16.447 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

avec l’option -A

traceroute -A -n -T -p 25 mx1.computop.com
traceroute to mx1.computop.com (213.155.65.81), 30 hops max, 60 byte packets
 1  152.228.208.1 [AS16276]  0.649 ms  0.574 ms  0.548 ms
 2  192.168.143.254 [*]  0.522 ms  0.501 ms  0.473 ms
 3  10.224.153.62 [*]  0.456 ms  0.439 ms  0.468 ms
 4  10.224.137.124 [*]  0.496 ms  0.480 ms 10.224.137.126 [*]  0.461 ms
 5  10.224.138.30 [*]  0.435 ms  0.419 ms 10.224.136.18 [*]  0.402 ms
 6  10.17.155.60 [*]  0.830 ms 10.17.146.4 [*]  0.697 ms 10.17.149.114 [*]  0.741 ms
 7  10.73.1.16 [*]  0.574 ms 10.73.0.74 [*]  0.560 ms 10.73.1.38 [*]  0.548 ms
 8  178.33.99.149 [AS16276]  0.506 ms  0.490 ms  0.479 ms
 9  10.73.0.24 [*]  0.468 ms  0.513 ms  0.502 ms
10  10.95.33.8 [*]  4.626 ms  1.630 ms  1.594 ms
11  213.186.32.213 [AS16276]  9.576 ms  9.166 ms  9.176 ms
12  10.200.0.17 [*]  9.225 ms  9.242 ms 10.200.0.13 [*]  16.138 ms
13  80.81.193.88 [*]  9.509 ms 80.81.192.88 [*]  9.244 ms  9.222 ms
14  62.128.0.126 [AS12337]  9.599 ms  9.602 ms  9.557 ms
15  213.95.0.110 [AS12337]  16.219 ms 62.128.0.154 [AS12337]  16.517 ms 213.95.0.110 [AS12337]  16.202 ms
16  62.128.0.154 [AS12337]  16.477 ms  16.457 ms  16.339 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
#7

Et cette piste ?

option -m

#8

Bonjour,

Vu que le ping ne passe ni de chez moi, ni d’un serveur hébergé chez OVH, mais que la machine est joignable sur le port 25, cela ressemble à problème de pare-feu qui bloque trop de choses (l’IP de ton serveur ?)

$ ping -c2 mx1.computop.com
PING mx1.computop.com (213.155.65.81) 56(84) bytes of data.

--- mx1.computop.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1017ms

$ telnet mx1.computop.com 25
Trying 213.155.65.81...
Connected to mx1.computop.com.
Escape character is '^]'.
220 mx.computop.com ESMTP
quit
221 2.0.0 Bye
Connection closed by foreign host.
#9

Un problème de pare-feu chez eux ? Parce que du coup pourquoi ça fonctionne de mon VPS ?

#10

Non sur ton serveur. Au lieu de faire des traceroute, fais tes tests avec des commandes ping et éventuellement nmap. Tu verras qu’il y a bien un pare-feu qui bloque au niveau du serveur mx1.computop.com
Si cela fonctionne de ton VPS, c’est sans doute que son IP n’est pas bloquée par mx1.computop.com.

#11

On a pas la même analyse, je contacterais l’assistance OVH …

1 J'aime
#12

Ah oui ! J’ai vraiment très mal interprété. Je suis bêtement parti du principe que mx1.computop.com était son serveur. Mais c’est apparemment un des serveurs tiers qu’il n’arrive pas à joindre.

Si le serveur de @AnGe7 est bloqué par mx1.computop.com et pas d’autres machines c’est que pour une raison ou une autre mx1.computop.com l’a mis en liste noire ou a carrément bloqué toute une plage d’IP :confused:

#13

C’est ce que j’ai fais.

je vois pas pourquoi mon serveur aurai été mis en liste noir, mais why not.

Je vais attendre de voir ce que me dit OVH

#14

As-tu regardé actuellement et il y a qq temps le résultat de testeurs de serveurr de mail, par ex www.mail-tester.com ?

J’auto-héberge mon serveur de mail (zimbra) et je regarde et garde les résultats régulièrement.

#15

Screenshot 2023-06-15 at 15-45-02 Résultat du Test de Spam

:confused:

#16

quelle est l’IP visible d’internet du serveur source, et il suffit de regar der sur des site de blacklist.
Sur le site ci-deszsous, entrer l’IP du serveur de messagerie source:

#17

Screenshot 2023-06-15 at 15-51-46 Network Tools DNS IP Email

#18

qu’est ce que c’est? quel contexte?. etc…?

#19

10/10, le serveur n’est pas black listé, encore un indice qui oriente vers un pb OVH … aucun regret d’être en auto-hébergement :slight_smile: (il y a tout de même des désavantage :frowning: ))

#20

Je pense qu’il y a des admins système assez cons pour utiliser UCEPROTECTL3 comme liste noire :confused:
Et là tu ne peux pas faire grand chose…

Vérifie ici http://www.uceprotect.net/en/rblcheck.php avec l’adresse IP de ton serveur et celle de ton VPS avec qui cela « passe »

EDIT : j’ai un serveur dont l’Ip est dans UCEPROTECTL3 qui peut atteindre mx1.computop.com sur le port 25. C’est donc probablement une autre source de blocage.

1 J'aime