Utilisation de mes adresses IP sur le server OVH via GRE

Je ne peux pas apather mes IP vers un server OVH, puis-je m'aider à find le problème?

Mikrotik GRE IP: 192.168.55.10
OVH Server GRE IP: 192.168.55.20
Nom de l'ombre GRE: ali1_fr1-ovz1
IP pour passer de Mikrotik à OVH Server: 185.47.128.50 (je veux utiliser cette IP dans un conteneur VZ)

Ping de Mikrotik à OVH GRE IP -> GRE OK

 ping 192.168.55.20
 TAUX D'HÔTÉ TTL HEURE STATUT                   
 192.168.55.20 56 64 28ms 
 192.168.55.20 56 64 28ms 
 192.168.55.20 56 64 28ms 
     envoyé = 3 reçus = 3 packages-perte = 0% min-rtt = 28ms avg-rtt = 28ms max-rtt = 28ms 

Traceroute de Mikrotik vers IP apathée -> via GRE, Route OK

  # ADRESSE PERTE ENVOYÉE DERNIÈRE AVG MEILLEUR PETIT
  1 192.168.55.20 0% 6 28.4ms 28.3 28.2 28.4
  2 185.47.128.50 0% 5 28.2ms 28.3 28.2 28.7

Ping du server OVH à l'adresse IP, l'adresse IP est atsortingbuée à un conteneur VZ -> ping local, OK

 # ping 185.47.128.50
 PING 185.47.128.50 (185.47.128.50) 56 (84) octets de données.
 64 octets à partir de 185.47.128.50: icmp_seq = 1 ttl = 64 fois = 0.019 ms

Passer du server OVH vers l'IP de Mikrotik GRE: -> GRE OK

 # ping 192.168.55.10
 PING 192.168.55.10 (192.168.55.10) 56 (84) octets de données.
 64 octets de 192.168.55.10: icmp_seq = 1 ttl = 64 fois = 28.1 ms

route sur le server OVH ( server OpenVZ, 185.47.128.50 est le conteneur)

 [root @ fr1-ovz1 ~] # route -n
 Table de routing IP Kernel
 Passerelle de destination Genmask Flags Mesortingc Ref Utilisez Iface
 185.47.128.50 0.0.0.0 255.255.255.255 UH 0 0 0 venet0
 192.168.55.10 0.0.0.0 255.255.255.255 UH 0 0 0 ali1_fr1-ovz1
 94.23.252.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
 0.0.0.0 94.23.252.254 0.0.0.0 UG 0 0 0 eth0

Ping de l'Internet vers l'IP routée: -> timeout 🙁

 PING 185.47.128.50 (185.47.128.50) 56 (84) octets de données.

 --- 185.47.128.50 ping statistics ---
 8 packages transmis, 0 reçus, 100% perte de packages, time 5454ms

Une idée? Merci!

Votre description n'est pas très claire sur le stream de trafic, mais je dirais que l'itinéraire de return du server va directement à Internet et qu'il est filtré.

Vous pouvez le prouver ou le refuser, en exécutant tcpdump sur l'interface sur le server, vous devriez voir le ping de l'internet à venir, mais la réponse ne traverse pas le tunnel, il passe directement par eth0.