[janus57]

Bonjour,

Tu parles d'une tentative de connexion mais la connexion est pourtant bien indiquée comme établie, non ?

SSH c'est en TCP, donc pour envoyer un login et un password (même si il est faux) faut bien se connecter , non ? =)

Sinon bonne chance sous windows serveur, peut être que des personnes connaissent une alternative fiable à fail2ban.

Cordialement, janus57

[Yves_L]

Bonjour

C'est un serveur Windows. Existe-t-il une alternative à fail2ban ?

Tu parles d'une tentative de connexion mais la connexion est pourtant bien indiquée comme établie, non ?

EDIT: je viens d'installer EvlWatcher, une alternative à fail2ban pour Windows. Malgré des échecs de l'audit qui défilent par paquets de 3 toutes les 6 secondes dans l'observateur d'évènements, il ne m'a encore banni aucune IP.

EDIT 2 : OK ça fonctionne après 2h00 de mise en service

[nowwhat]

extrait du netstat -an :
TCP    188.165.196.135:22     218.87.111.109:54319   ESTABLISHED

Un traceroute de 218.87.111.109 me fait passer par chinatelecom…

Lance la commande
who
Normalement, il n'y que toi qui est mentionné.
T'auras une ligne comme:
root pts/0 Apr 25 20:43 (abordeaux-158-1-78-217.w90-60.abo.wanadoo.fr)

Si t'es à deux dessus, le mot n'est plus parano, mais contacte Houston .... car t'as un problème.

Il s'agit normalement une connexion temporaire depuis un proxy en Chine** que fait quelques essais sur ta porte "22" - une tentative pur voir si "le type" entre. Ce n'est rien de spécial.
Pour ce genre de tentatives, t'as fail2ban.
Et encore, ça ne risque rien (nada, zéro) car ton serveur n'accepte plus un accès avec un utilisateur ("root", ou autre) et son mot de passe. T'as ton clé publique sur le serveur qui demande la clé privée (sur ton ordi).
T'as rien de tout ça ? ..... Comme tu veux, mais enlève le mot 'parano' de ton dictionnaire


** "Le type" peut bien être un Français, Américain, Canadien - peut être même un Chinois.

[Yves_L]

Bonjour,

J'ai eu un retour du support par mail m'indiquant que des modifications sur les infrastructures avaient été effectuées et qu'ils m'invitaient à leur retourner par mail mes résultats d'une nouvelle vérification de la stabilité de mes ports UDP. Humm… j'ai la vague impression que je ne suis pas encore rendu…

Avant de relancer quelques tests, j'ai tenté une connexion client/serveur sur les ports problématiques, sans succès.

Par contre en lançant un netstat -an, hier soir, je me suis aperçu qu'une IP située aux alentours de Santa Clara en Californie était connectée 24 fois simultanément sur le port 9002, un des ports qui refuse la connexion de mon client : http://pastebin.com/RJ6MfdaG

J'ai arrêté les instances de mon appli serveur, j'en ai profité pour faire quelques mises-à-jour Windows, j'ai redémarré le serveur et relancé les instances. Les connexions clients/serveur posaient toujours problème sur certains ports, les mêmes que depuis le début de cette affaire.

Plus tard, j'ai relancé un netstat -an pour constater qu'une IP distante autre que la mienne avait établi une connexion sur le port 22 (la première IP sur le port 22 , c'est la mienne) :

extrait du netstat -an :

TCP    127.0.0.1:54487        127.0.0.1:54486        ESTABLISHED
TCP    188.165.196.135:22     92.137.182.254:56642   ESTABLISHED
TCP    188.165.196.135:22     218.87.111.109:54319   ESTABLISHED
TCP    188.165.196.135:53     0.0.0.0:0              LISTENING
TCP    188.165.196.135:139    0.0.0.0:0              LISTENING

etc…

Un traceroute de 218.87.111.109 me fait passer par chinatelecom…

Je suis novice dans ce domaine (dans d'autres aussi )… Est-ce que j'ai raison de m'inquiéter ou je suis un peu trop parano ?

[Yves_L]

En effet. La console du simulateur indique une erreur ressemblant à un timeout peu de temps après le gel du client:

17:18:41 - [LLUDPSERVER]: No packets received from root agent of Kyle Brynner fo
r 60000ms in AIRE.  Disconnecting.

A noter que d'autres ports semblent accepter la connexion. Par exemple les clients parviennent à se connecter sur un simulateur avec le port UDP 9111. C'est le cas également avec les ports 9114 ou 9118, entre autres, mais pas avec les ports 9115 ou 9119.

[SD90078-OVH]

je retire, c'est bien ouvert, mais c'est looooooooonnnnnnng a repondre

root@debian7x64:~# nmap -p 9002 -sU grid.aire-mille-flux.org

Starting Nmap 6.00 ( http://nmap.org ) at 2015-04-14 16:27 CEST
Nmap scan report for grid.aire-mille-flux.org (188.165.196.135)
Host is up (0.024s latency).
rDNS record for 188.165.196.135: ks309808.kimsufi.com
PORT     STATE         SERVICE
9002/udp open|filtered dynamid

Nmap done: 1 IP address (1 host up) scanned in 3.10 seconds
root@debian7x64:~# nmap -p 9003 -sU grid.aire-mille-flux.org

Starting Nmap 6.00 ( http://nmap.org ) at 2015-04-14 16:27 CEST
Nmap scan report for grid.aire-mille-flux.org (188.165.196.135)
Host is up (0.015s latency).
rDNS record for 188.165.196.135: ks309808.kimsufi.com
PORT     STATE         SERVICE
9003/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds

ça serait pas ça le souci ?
ça tombe en timeout avant que le client connecte ?

[SD90078-OVH]

ce qui est bizare, c'est que vu de l'exterieur, le port 9002 par ex repond pas, alors que le 53 oui.

C:\PortQryV2>PortQry.exe -n grid.aire-mille-flux.org -e 9002 -p UDP

Querying target system called:

 grid.aire-mille-flux.org

Attempting to resolve name to IP address...


Name resolved to 188.165.196.135

querying...

UDP port 9002 (unknown service): LISTENING or FILTERED

C:\PortQryV2>PortQry.exe -n grid.aire-mille-flux.org -e 53 -p UDP

Querying target system called:

 grid.aire-mille-flux.org

Attempting to resolve name to IP address...


Name resolved to 188.165.196.135

querying...

UDP port 53 (domain service): LISTENING

ne pas de fier au LISTENING or FILTERED, ça tombe en timeout en fait.

[SD90078-OVH]

je ne sais pas si beaucoup de personne sur ce forum sont des "spécialiste" ou grand connaisseurs de "Windows Server".

c'est mon métier, je devrais pas trop répondre a coté de la plaque

[Yves_L]

Oui, effectivement. J'ai lancé la commande depuis Terminal après m'être connecté au serveur.

Je viens de désactiver le firewall sur tous les profils : domaine, public et privé. J'ai tenté de me connecter avec un client sur l'une des regions avec un port qui pose problème. Ça ne fonctionne toujours pas.

[janus57]

Bonjour,

de ce que j'ai compris, il a lancé la commande en a partir d'un client SSH mais connecté sur le serveur.
du coup, le résultât est celui attendu.

yep possible j'ai pas fait attention (en même temps un windows server avec du SSH sa doit pas être spécialement "standard").

Sinon il me semble qu'il ne savait pas comment faire ou du moins comment s'y prendre pour couper le firewall.

Après comme pour les distribution BSD je ne sais pas si beaucoup de personne sur ce forum sont des "spécialiste" ou grand connaisseurs de "Windows Server".

Cordialement, janus57

[SD90078-OVH]

j'ai la désagréable impression que tu as un firewall qui bloque quand même !!!
as-tu essayé en le désactivant (le temps de tests) ?
pas d'alertes sur le serveur ?

[SD90078-OVH]

de ce que j'ai compris, il a lancé la commande en a partir d'un client SSH mais connecté sur le serveur.
du coup, le résultât est celui attendu.

apparemment, ça écoute bien, accessoirement, le pool de sockets ouverts pour le serveur DNS peut être réduit, ça évitera que autant de ports UDP soient ouverts (pas gênant en soi, juste que du coup, ça réserve plein de ports qui ne peuvent plus être utilisés par d'autres softs)

[janus57]

Bonjour,

le netstat depuis le PC client est inutile (sauf si il est connecté au logiciel sur le serveur, cela confirmera juste les ports utilisés), si @SD90078-OVH le demande depuis le serveur c'est pour voir si le logiciel écoute bien sur le port UDP ou si cette partie du logiciel a foiré et n'écoute plus sur le port UDP (ou écoute par intermittence).

Cordialement, janus57

[Yves_L]

Bonjour,

L'invite de commande Windows est un peu limitée en nombre de caractères affichés. Comme je n'avais que la fin de la liste et que je ne connais pas le moyen de n'afficher que le début, j'ai fait le netstat -an en SSH depuis mon Mac. Voici le lien pastebin

Ce sont les ports 8002, 8003 ainsi que la série des ports 9000 qui concernent mon logiciel serveur.

[SD90078-OVH]

Bonjour,

tu peux faire un netstat -an sur le serveur et coller le résultat ?

[Yves_L]

Bonjour,

OK, je vais tenter le support.
Je ferai un point sur le résultat,

Merci pour ton aide et celles de ceux qui sont intervenus sur cette discussion

[janus57]

Bonjour,

Avant de contacter le support ou de changer de serveur, il n’y a rien à tenter avec le firewall, en mode WinpeRescue notamment et son outil SRVfirewall? J'aurais bien tenté le truc, mais je préfère poser la question plutôt que de faire une erreur…

ah moins que parmi les membres y a un "spécialiste" ou un grande utilisateur de "Windows Server" je pense pas que tu aura une réponse :/

Les nouveau KS ont seulement linux en distribution (je compte pas Windows Hyper-V), et de toute façons les 3/4 des personnes cherchent à faire du web en pensant que leur KS sont plus puissant qu'un mutualisé et tout aussi facile (cela doit représenter 1/4 des utilisateurs en 2015 facile).

Sinon comme dit plus haut mon nmap je vois rien en UDP, après si la session UDP s'ouvre après identification pas possible pour nous de faire plus de tests alors.

Tu peu toujours essayer de contacter le support mais faudra pas écrire de "blabla" inutile et surtout fournir des MTR, sinon ils vont dire que le problème est sur ton serveur et te ré-envoyer ici.

Bonne chance.

Cordialement, janus57

[Yves_L]

Bonjour,

Comme promis, quelques détails sur le fonctionnement de mon installation.

Mon logiciel serveur fait tourner des espaces virtuels 3D.
L’architecture de ce logiciel est constituée de 3 parties :
- un process qui réuni les services nécessaires au bon fonctionnement du système.
- un process pour le simulateur de chaque espace virtuel.
- une régions qui dépend de chaque simulateur.

Lorsqu’un logiciel client se connecte à un espace virtuel 3D, il contacte tout d’abord, entre autres, le service des logins et des utilisateurs en TCP, puis le simulateur, toujours en TCP et enfin la région en UDP.

Lors des échecs de connexions, sur la console du simulateur on voit bien que le client passe les deux premières étape. L’utilisateur est même déjà pris en compte et considéré comme quasi connecté mais un timeout fait planté le client systématiquement (freeze ou fermeture du client). Et c’est la même chose pour tout les utilisateurs qui se connectent depuis n’importe quel endroit en France et en Europe avec des machines variées et des FAI différents.

Avant de contacter le support ou de changer de serveur, il n’y a rien à tenter avec le firewall, en mode WinpeRescue notamment et son outil SRVfirewall? J'aurais bien tenté le truc, mais je préfère poser la question plutôt que de faire une erreur…

[Yves_L]

Wow !

Merci janus d'avoir pris le temps de faire tout ces tests et cette analyse !

Les erreurs sur les consoles de mes instances serveur font état de la connexion UDP lors de la connexion des clients, raison pour laquelle j'ai axé ma question sur ce protocole. Mais, à la connexion, le client communique aussi en TCP avec une instance centrale qui gère tous les services (login, assets, utilisateurs, etc…). Donc oui, il y a également du TCP.

Il est tard, et demain je serai AFK jusqu'au soir. J'essaierai alors de poster un résumé de l'architecture du truc, au moins pour info et même si ça ne nous mène pas plus loin.

Merci encore

[janus57]

Bonjour,

désolé mais je connais pas les serveurs Windows.

Mais là concrètement pour moi tous vos tests mettent en évidence que c'est +/- le serveur qui coupe et/ou rejet et/ou blackhole les connexion UDP comme si au bout d'un moment vous déclenché un genre d'anti-dos qui vous met à la porte niveau (peut être pas que UDP).

Sinon il faudrait carrément voir au niveau de l’application qui doit recevoir les connexion pour voir si elle vois les connexion ou non au moment des tests, si elle les vois c'est que c'est elle même qui les rejette, sinon l'udp est perdu entre le serveur et vous, mais au vu des différents tests cela semblr quand même bien perdu au niveau de l'entré du serveur.

Traceroute depuis mon PC :

Détermination de l'itinéraire vers ks309808.kimsufi.com [188.165.196.135]
avec un maximum de 30 sauts*:

  1     4 ms     2 ms     2 ms  LIVEBOX [192.168.1.1]
  2    24 ms    23 ms    22 ms  80.10.126.89
  3    23 ms    22 ms    25 ms  10.125.206.202
  4    24 ms    22 ms    25 ms  xe-2-3-1-0.ncncy101.Nancy.francetelecom.net [193
.249.215.14]
  5    27 ms    25 ms    24 ms  ae43-0.nrstr101.Schiltigheim.francetelecom.net [
193.252.160.90]
  6    28 ms    26 ms    25 ms  ae40-0.nrstr102.Strasbourg.francetelecom.net [19
3.252.160.126]
  7    36 ms    34 ms    40 ms  ae48-0.nridf302.Paris.francetelecom.net [193.251
.126.5]
  8    36 ms    34 ms    38 ms  ae48-0.nridf102.Aubervilliers.francetelecom.net
[193.251.126.126]
  9     *       34 ms    41 ms  lag-1.noaub602.Aubervilliers.francetelecom.net [
193.252.98.46]
 10   102 ms     *      100 ms  gsw-2-6k.fr.eu [91.121.131.49]
 11   112 ms   130 ms    98 ms  gsw-g1-a9.fr.eu [91.121.128.160]
 12   108 ms   110 ms   108 ms  rbx-g2-a9.fr.eu [91.121.131.213]
 13   171 ms   107 ms   106 ms  vss-3-6k.fr.eu [213.251.130.77]
 14   105 ms   117 ms   140 ms  ks309808.kimsufi.com [188.165.196.135]

Depuis mon KS :

root@janus57-experiment:~# traceroute 188.165.196.135
traceroute to 188.165.196.135 (188.165.196.135), 30 hops max, 60 byte packets
 1  vss-7a-6k.fr.eu (37.59.40.253)  1.146 ms * *
 2  10.21.50.20 (10.21.50.20)  151.366 ms  151.355 ms  151.333 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Depuis un VPS (OVH) :

root@janus57-beta:~# traceroute 188.165.196.135
traceroute to 188.165.196.135 (188.165.196.135), 30 hops max, 60 byte packets
 1  107.ip-151-80-138.eu (151.80.138.107)  0.100 ms  0.026 ms  0.023 ms
 2  10.21.50.21 (10.21.50.21)  0.696 ms  0.755 ms 10.21.50.20 (10.21.50.20)  0.908 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Bon visiblement en interne cela ne passe pas vraiment...

Test depuis ma VM Debian jessie :

janus57@test:~$ traceroute 188.165.196.135
traceroute to 188.165.196.135 (188.165.196.135), 30 hops max, 60 byte packets
 1  livebox.home (192.168.1.1)  0.891 ms  2.596 ms  4.019 ms
 2  80.10.126.89 (80.10.126.89)  46.093 ms  49.237 ms  51.122 ms
 3  10.125.206.202 (10.125.206.202)  52.109 ms  53.503 ms  55.357 ms
 4  xe-2-3-1-0.ncncy101.Nancy.francetelecom.net (193.249.215.14)  57.913 ms  58.885 ms  66.109 ms
 5  ae43-0.nrstr101.Schiltigheim.francetelecom.net (193.252.160.90)  68.018 ms  82.467 ms  85.032 ms
 6  ae40-0.nrstr102.Strasbourg.francetelecom.net (193.252.160.126)  85.468 ms  101.259 ms  195.561 ms
 7  ae48-0.nridf302.Paris.francetelecom.net (193.251.126.5)  241.771 ms  256.478 ms  258.561 ms
 8  ae48-0.nridf102.Aubervilliers.francetelecom.net (193.251.126.126)  259.630 ms  260.831 ms  263.070 ms
 9  * * *
10  gsw-2-6k.fr.eu (91.121.131.49)  305.915 ms * *
11  gsw-g1-a9.fr.eu (91.121.128.160)  264.334 ms  265.777 ms  267.921 ms
12  rbx-g2-a9.fr.eu (91.121.215.151)  329.189 ms  196.844 ms rbx-g2-a9.fr.eu (91.121.131.213)  192.211 ms
13  vss-3-6k.fr.eu (213.251.130.77)  191.159 ms  191.180 ms  193.195 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Là par contre c'est très bizarre qu'un tracert windows me donne le chemin complet et qu'un traceroute linux me lache après le routeur "vss-3-6k.fr.eu"

Bref j'ai un peu la flemme de lire le manuel pour comprendre cette différence, mais d'après le peu que j'ai lu/trouvé, windows == icmp ping / linux udp probes

Donc maintenant place au MTR depuis la VM Debian jessie :

janus57@test:~$ mtr -r 188.165.196.135
Start: Fri Apr 10 21:45:14 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home               0.0%    10    2.0   1.9   1.6   2.3   0.0
  2.|-- 80.10.126.89               0.0%    10   22.3  24.9  21.5  43.3   6.5
  3.|-- 10.125.206.202             0.0%    10   53.2  27.5  23.6  53.2   9.0
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%    10   24.7  29.3  23.3  75.0  16.1
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%    10   26.4  28.3  18.6  58.8  10.9
  6.|-- ae40-0.nrstr102.Strasbour  0.0%    10   58.5  29.2  25.1  58.5  10.4
  7.|-- ae48-0.nridf302.Paris.fra  0.0%    10   35.6  34.9  29.7  38.3   2.1
  8.|-- ae48-0.nridf102.Aubervill  0.0%    10   31.6  35.8  31.6  37.2   1.5
  9.|-- lag-1.noaub602.Aubervilli 50.0%    10   35.8  38.0  35.8  45.7   4.2
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- gsw-g1-a9.fr.eu            0.0%    10  105.6 102.8  88.0 114.3   7.7
 12.|-- rbx-g2-a9.fr.eu            0.0%    10  105.9 106.6  98.9 110.7   3.1
 13.|-- vss-3-6k.fr.eu            10.0%    10  982.4 220.7 102.7 982.4 290.6
 14.|-- ks309808.kimsufi.com      10.0%    10  104.2 106.5 103.8 109.6   2.1

root@test:/home/janus57# mtr -r -u 188.165.196.135
Start: Fri Apr 10 21:45:35 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home               0.0%    10    2.9   3.3   2.1   9.5   2.1
  2.|-- 80.10.126.89               0.0%    10   28.3  30.9  23.9  74.9  15.6
  3.|-- 10.125.206.202             0.0%    10   25.3  24.4  19.7  29.1   2.4
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%    10   23.6  26.0  23.4  31.4   2.9
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%    10   26.1  33.3  21.5  84.9  18.4
  6.|-- ae40-0.nrstr102.Strasbour  0.0%    10   25.6  29.1  20.1  53.5   8.9
  7.|-- ae48-0.nridf302.Paris.fra  0.0%    10   32.0  36.5  32.0  39.3   1.9
  8.|-- ae48-0.nridf102.Aubervill  0.0%    10   36.3  36.8  28.5  45.9   4.5
  9.|-- lag-1.noaub602.Aubervilli 50.0%    10   34.4  35.2  34.0  37.5   1.3
 10.|-- gsw-2-6k.fr.eu            80.0%    10  102.2 104.7 102.2 107.2   3.5
 11.|-- gsw-g1-a9.fr.eu            0.0%    10  101.2  99.3  87.6 107.6   5.4
 12.|-- rbx-g2-a9.fr.eu            0.0%    10  106.5 104.3  92.6 109.2   5.2
 13.|-- vss-3-6k.fr.eu             0.0%    10  189.9 257.9  99.0 879.7 245.0
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

janus57@test:~$ mtr -r -c 500 188.165.196.135
Start: Fri Apr 10 21:46:20 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home              47.0%   500    1.6   3.6   0.0  72.5   9.2
  2.|-- 80.10.126.89               0.0%   500   25.1  28.9  12.9 268.9  24.2
  3.|-- 10.125.206.202             0.0%   500   25.2  29.2  14.9 250.5  24.4
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%   500   25.0  37.2  12.2 222.4  23.4
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%   500   25.6  41.4  15.1 198.7  26.3
  6.|-- ae40-0.nrstr102.Strasbour  0.2%   500   27.3  40.2  16.7 239.6  28.4
  7.|-- ae48-0.nridf302.Paris.fra  0.0%   500   37.0  42.8  20.4 215.6  22.6
  8.|-- ae48-0.nridf102.Aubervill  0.2%   500   36.5  42.2  27.2 248.4  20.4
  9.|-- lag-1.noaub602.Aubervilli 50.2%   500   37.3  41.1  28.7 206.3  18.0
 10.|-- gsw-2-6k.fr.eu            79.0%   500  149.7 117.9  85.4 335.3  39.5
 11.|-- gsw-g1-a9.fr.eu            1.0%   500  995.3 105.8  46.1 995.3  44.8
 12.|-- rbx-g2-a9.fr.eu            0.4%   500   61.6 107.9  43.9 326.7  21.6
 13.|-- vss-3-6k.fr.eu             0.0%   500   62.6 175.9  47.3 1771. 210.8
 14.|-- ks309808.kimsufi.com       0.4%   500   61.8 107.1  48.7 347.8  20.5

Bon MTR en ICMP le premier 10% puis si on test un peu plus on tombe à 0.4%, donc légère perte.

Maintenant les MTR UDP un peu plus "poussé" :

janus57@test:~$ mtr -r -u -c 50 188.165.196.135
Start: Fri Apr 10 22:00:13 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home              46.0%    50    2.2   3.3   2.1  11.1   1.7
  2.|-- 80.10.126.89               0.0%    50   24.2  29.4  16.6  81.3  12.3
  3.|-- 10.125.206.202             0.0%    50   28.2  26.5  17.2  47.3   3.8
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%    50   13.8  29.7  13.8  81.7  11.3
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%    50   26.1  34.5  19.2 122.6  20.3
  6.|-- ae40-0.nrstr102.Strasbour  0.0%    50   27.8  31.8  18.0 123.2  16.1
  7.|-- ae48-0.nridf302.Paris.fra  0.0%    50   34.6  40.5  25.9  87.5  10.4
  8.|-- ae48-0.nridf102.Aubervill  2.0%    50   38.4  41.4  31.8  63.6   7.3
  9.|-- lag-1.noaub602.Aubervilli 50.0%    50   39.5  41.6  35.3  61.3   7.4
 10.|-- gsw-2-6k.fr.eu            56.0%    50  103.7 120.8  96.7 164.8  21.5
 11.|-- gsw-g1-a9.fr.eu            0.0%    50  114.1 120.2 104.7 249.6  21.2
 12.|-- rbx-g2-a9.fr.eu            0.0%    50  114.7 123.8 108.4 264.0  22.4
 13.|-- vss-3b-6k.fr.eu            2.0%    50  102.8 141.6  95.9 614.0  89.3
 14.|-- ???

janus57@test:~$ mtr -r -u -c 100 188.165.196.135
Start: Fri Apr 10 22:04:32 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home              41.0%   100    2.2   3.5   0.7  47.2   5.8
  2.|-- 80.10.126.89               0.0%   100   26.2  27.7  14.7  80.5  10.2
  3.|-- 10.125.206.202             0.0%   100   25.1  26.6  15.5 106.1   8.6
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%   100   28.9  30.2  23.0 129.4  14.1
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%   100   27.3  36.5  23.6 130.2  20.9
  6.|-- ae40-0.nrstr102.Strasbour  0.0%   100   28.2  34.2  19.2 107.9  18.1
  7.|-- ae48-0.nridf302.Paris.fra  0.0%   100   41.2  39.4  26.6  97.7   8.8
  8.|-- ae48-0.nridf102.Aubervill  0.0%   100   38.0  40.1  28.5  87.9   9.1
  9.|-- lag-1.noaub602.Aubervilli 54.0%   100   39.0  40.3  29.9  86.4   8.7
 10.|-- gsw-2-6k.fr.eu            74.0%   100  102.6 110.7  91.4 166.2  17.9
 11.|-- gsw-g1-a9.fr.eu            1.0%   100  112.9 114.4  98.7 173.5   8.6
 12.|-- rbx-g2-a9.fr.eu            2.0%   100  117.7 118.3  99.5 174.4   8.4
 13.|-- vss-3-6k.fr.eu             1.0%   100  210.6 163.7  95.1 1525. 206.2
 14.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

root@test:/home/janus57# mtr -r -u -c 500 188.165.196.135
Start: Fri Apr 10 21:59:11 2015
HOST: test                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home              14.0%   500    2.8 1520.   0.0 32642 22229.9
  2.|-- 80.10.126.89               0.2%   500   15.6  27.2  13.1 107.8   8.7
  3.|-- 10.125.206.202             0.0%   500   24.4  26.1  15.1 167.1   8.9
  4.|-- xe-2-3-1-0.ncncy101.Nancy  0.0%   500   24.7  28.2  14.9  92.1  10.1
  5.|-- ae43-0.nrstr101.Schiltigh  0.0%   500   27.9  32.8  17.1 177.4  18.3
  6.|-- ae40-0.nrstr102.Strasbour  0.0%   500   27.0  33.5  15.6 126.9  16.6
  7.|-- ae48-0.nridf302.Paris.fra  0.0%   500   37.8  38.4  24.2 158.6   8.4
  8.|-- ae48-0.nridf102.Aubervill  0.0%   500   38.6 683.1  16.5 32186 14392.3
  9.|-- lag-1.noaub602.Aubervilli 42.8%   500   30.4 17645  24.5 32686 63573.0
 10.|-- gsw-2-6k.fr.eu            52.4%   500  100.7 30787  81.1 32687 85941.8
 11.|-- gsw-g1-a9.fr.eu            0.4%   500  108.9 112.8  94.2 198.8   9.1
 12.|-- rbx-g2-a9.fr.eu            0.2%   500  118.0 771.0 100.3 32640 14606.6
 13.|-- vss-3b-6k.fr.eu            0.0%   500  107.4 158.6  93.0 1735. 162.5
 14.|-- vss-3b-6k.fr.eu           83.8%   500  32687 24535 61582 32687 119872.7
 15.|-- vss-3b-6k.fr.eu           84.2%   500  32687 16445 61520 32687 128581.0
 16.|-- vss-3b-6k.fr.eu           84.4%   500  32688 16578 61521 32688 128884.8
 17.|-- vss-3b-6k.fr.eu           88.0%   500  32674 12746 61515 32674 114666.6
 18.|-- 10.125.206.202            96.4%   500  32697 32461 32217 32697 1574.8
 19.|-- xe-2-3-1-0.ncncy101.Nancy 96.4%   500  32699 32463 32218 32699 1574.7
 20.|-- livebox.home              96.6%   496  32816 32456 32198 32816 1665.7
 21.|-- 80.10.126.89              96.6%   437  32657 32420 32201 32657 1536.7
 22.|-- 10.125.206.202            95.9%   436  32687 32447 32201 32687 1580.2
 23.|-- livebox.home              95.6%   436  32688 32434 32190 32688 1646.0
 24.|-- ae43-0.nrstr101.Schiltigh 95.9%   435  32698 32448 32203 32698 1430.3
 25.|-- ???                       100.0   119    0.0   0.0   0.0   0.0   0.0

Bon alors le dernier mtr en UDP est WTF complet ça fait Orange -> OVH -> OVH (boucle) -> Orange
Je sais pas si y a une sécu chez Orange ou OVH mais si on envois trop de packets/trafic UDP sa semble boucler et retour à l'envoyeur (dans mon cas...)

Sinon vous êtes bien sure que c'est de l'UDP qui est utilisé ???

PORT      STATE SERVICE       VERSION

22/tcp    open  ssh           OpenSSH 5.3 (protocol 2.0)
| ssh-hostkey: 
|   1024 17:6c:30:21:bb:f7:90:80:fc:d5:2d:73:5a:a8:93:55 (DSA)
|_  2048 5e:50:92:77:84:c9:c8:4a:cf:82:b1:4e:d0:af:53:7a (RSA)

53/tcp    open  domain        Microsoft DNS 6.1.7601
| dns-nsid: 
|_  bind.version: Microsoft DNS 6.1.7601 (1DB14556)

80/tcp    open  http          Microsoft IIS httpd 7.5
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: IIS7

135/tcp   open  msrpc         Microsoft Windows RPC
3306/tcp  open  mysql         MySQL (unauthorized)
3389/tcp  open  ms-wbt-server Microsoft Terminal Service

8002/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

9002/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

9003/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

9111/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

49154/tcp open  msrpc         Microsoft Windows RPC
49155/tcp open  msrpc         Microsoft Windows RPC

nmap -sS -sU -T4 -A -v grid.aire-mille-flux.org

Initiating UDP Scan at 21:59
Scanning grid.aire-mille-flux.org (188.165.196.135) [1000 ports]
Discovered open port 53/udp on 188.165.196.135
Completed UDP Scan at 21:59, 12.07s elapsed (1000 total ports)

PORT      STATE SERVICE       VERSION

22/tcp    open  ssh           OpenSSH 5.3 (protocol 2.0)
| ssh-hostkey: 
|   1024 17:6c:30:21:bb:f7:90:80:fc:d5:2d:73:5a:a8:93:55 (DSA)
|_  2048 5e:50:92:77:84:c9:c8:4a:cf:82:b1:4e:d0:af:53:7a (RSA)

53/tcp    open  domain        Microsoft DNS 6.1.7601

80/tcp    open  http          Microsoft IIS httpd 7.5
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-title: IIS7

135/tcp   open  msrpc         Microsoft Windows RPC
3306/tcp  open  mysql         MySQL (unauthorized)
3389/tcp  open  ms-wbt-server Microsoft Terminal Service

8002/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

9002/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

9003/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-title: 404 Page not found

9111/tcp  open  http          Tiny WebServer (OpenSimulator http config)
|_http-methods: No Allow or Public header in OPTIONS response (status code 200)
|_http-title: 404 Page not found

49154/tcp open  msrpc         Microsoft Windows RPC
49155/tcp open  msrpc         Microsoft Windows RPC

53/udp    open  domain        Microsoft DNS 6.1.7601 (1DB14556)
| dns-nsid: 
|_  bind.version: Microsoft DNS 6.1.7601 (1DB14556)

Alors je suis sans doute pas un pro de nmap mais quand je vois un script qui dit "Intense scan plus UDP" et que le seul UDP découvert est celui du DNS, hum je me dit que finalement votre programme ne parle pas UDP mais plutôt TCP ou alors comme le nmap le prouve bah il écoute pas ou m'a rejeté ou il m'a bloqué, donc...

EDIT :

Salut,

pour moi ceci : pastebin.com/U49FBxnu montre que 85 % des paquets sont perdus dès le début çà ne vient pas du serveur ...

c'est pas de la faute de OVH non plus vu que la perte à lieu sur le réseau FAI (Orange).

Bref c'est relativement chelou, perso je dirais de laisser tomber ce serveur (si c'est bien lui le problème) et selon son prix soit reprendre un KS soit prendre un SYS.
Sur SYS pas de bridage à 100Mega "best-effort" Windows de disponible et un support hard 24H/7J et surtout ils sont fait pour avoir des clients dessus contrairement aux KS.

Cordialement, janus57

[buddy]

Salut,

pour moi ceci : pastebin.com/U49FBxnu montre que 85 % des paquets sont perdus dès le début çà ne vient pas du serveur ...

[Yves_L]

Bonsoir Janus,

Oui, pour l'ICPM je m'en suis rendu compte ce matin en me documentant un peu plus sur MTR. J’avais justement fait un test MTR en mode udp ,entre midi et deux, depuis chez moi vers le serveur . Voici le résultat : pastebin[dot]com/U49FBxnu

Malheureusement, depuis mon serveur, il ne semble pas y avoir d’option pour l’udp avec WinMTR .

Par contre, j’ai trouvé un outil pour savoir si les ports UDP sont disponibles et atteignables. J’ai fait quelques tests : pastebin[dot]com/rKzpCvgZ

Les tests sont fait depuis mon Mac qui a autant de problèmes à connecter un client sur certaines instances du logiciel serveur que tous les autres utilisateurs qu'ils soient sur PC, Mac ou Linux.

D'autre part, j'ai fait un traceroute depuis un autre Mac situé sur un autre réseau (merci les voisins ) qui donne un résultat similaire au mien : bloqué à la porte du serveur.

… pour ma part je dirais quand même qu'il doit y avoir un logiciel de sécurité (firewall) ou autre qui doit "jouer" avec vous/vos clients.

Je n’ai installé aucun logiciel de sécurité sur ce serveur. Le firewall est actif avec des règles de connexions entrantes sur les ports dont j'ai besoin, et c'est tout.

C’est tout de même étrange que certains ports UDP fonctionnent avec les connexions client et d'autres non. Est-ce que le firewall ne serait pas devenu un peu parano, un bug ou autre ? J'ai vu qu'il y avait un outil en mode rescue, WinpeSRVFirewall, susceptible de le réveiller un peu en le désactivant/réactivant… Ça pourrait aider ?

[janus57]

Bonjour,

le MTR de base ne révèle rien surout qu'il est fait en ICMP.

Il aurait fallu utiliser cette commande :

mtr -u grid.aire-mille-flux.org

Et surtout, le tout depuis un PC qui a un problème de connexion.

Si votre PC n'a pas de problème de connexion cela ne sert à rien et si possible tester pendant le problème.

Sinon la seule chose qui me parait bizarre c'est que le traceroute s'arrête après "vss-3b-6k.fr.eu" alors qu'il ne devrait pas, sinon les MTR sont normaux (0.1% de perte sur 3 tests c'est pas énorme) et le MTR serveur->vous semble inutilisable car votre BOX/PC/Réseau bloque ICMP, donc MTR faussé à première vu.

EDIT :
le traceroute semble "bloqué" sur votre pastbin et pourtant vos MTR allez plus loin, et cela bloqué pile poil sur votre serveur (le traceroute), bizarrement pour ma part je dirais quand même qu'il doit y avoir un logiciel de sécurité (firewall) ou autre qui doit "jouer" avec vous/vos clients.
De mon côté le traceroute est normale (FAI : Orange / W7).

Cordialement, janus57

[Yves_L]

Bonjour à tous

J’ai donc fait quelques tests, hier. Un traceroute, quelques MTR reports, un MTR sur 2h45 et un MTR depuis le serveur vers chez moi sur une durée de 2h30 environ. Comme pour le moment je ne peux poster ni liens ni code, vous trouverez les résultats de ces tests sur pastebin[dot]com/AtUGX6TE

Il semblerait qu’il y ait quelques soucis sur ce serveur. Il me reste à savoir comment faire pour arranger ça. Peut-être un redémarrage du serveur en mode Winpe Rescue pour réveiller le firewall? Si c’est le cas (ou pas), quelle procédure effectuer une fois en mode rescue ?

Merci pour votre éclairage

PS : Au cas où, j’avais testé hier, et à plusieurs reprises, l’affichage dans Chrome de la page d’accueil IIS du serveur mais sans succès. Pas de message d’erreur, juste une attente du navigateur en cours de connexion. J’ai retenté l’opération à l’instant et c’était bon…

[Yves_L]

@ Janus : Non pas de VAC et le débit par session UDP reste bien en dessous des limites d'après ce que j'ai pu constater. D'autre part, tout fonctionne parfaitement sur mon autre serveur qui est en tout point identique à celui qui pose problème.

@nowwhat : merci pour le plan B. C'est idiot j'aurais dû y penser plus tôt. Je verrai ça demain. Là, c'est l'appel du lit…

[janus57]

Bonjour,

sinon question débile, le serveur à problème ne serait pas derrière le VAC par hasard ?

Il utilise beaucoup de débit pas session UDP le programme ? Car y a une limite de débit UDP chez OVH (genre 20 ou 50Mb/s inscrit en dur dans leur routeurs de mémoire).

Cordialement, janus57

[nowwhat]

et 5 balises code avec traceroutes et MTR.

Plan B : http://pastebin.org
Copie colle tes résultats la-bas. Poste le lien ici - comme http://pastebin.com/iwTDjd7E
Si ce forum te laisse pas poster des liens, fait comme ceci: pastebin.com / iwTDjd7E
Ça passera.

[Yves_L]

Bonsoir,

On verra donc demain avec l'espoir que mes résultats et ma question auront été validés entre-temps par la modération.
Si ce n'est pas le cas il faudra que je me débrouille avec mon ami Google.

En tout cas merci pour cet aiguillage vers MTR que j'ai eu l'occasion de découvrir. Son utilisation aura été très instructive.

[janus57]

Bonjour,

Je suis nouveau sur le forum… Quelqu'un peu m'expliquer pourquoi ?

réponse dans la question, nouveau == soumis au contrôle anti-spam.

Cordialement, janus57

[Yves_L]

Merci pour vos réponses

J'ai fait des tests… Seulement…
J'essaie de poster les résultats que j'ai obtenu, mais lors de la publication un message m'indique que la modération doit valider ma réponse.
Je suis nouveau sur le forum… Quelqu'un peu m'expliquer pourquoi ? Il n'y a qu'un peu de texte sans liens ni images et 5 balises code avec traceroutes et MTR. J'ai tenté de refaire une réponse partielle plus courte avec une seule balise mais sans plus de succès.

D'autre part, j'ai essayé de chercher sur le forum les règles et les limitations éventuelles en ce qui concerne les messages, sans succès pour le moment, et je ne sais pas s'il existe un moyen de contacter la modération pour signaler que des messages restent en attente de validation (comme le premier message que j'ai tenté de publié, il y a 6 jours maintenant et qui pour le coup ne sert plus à rien).

Merci de votre aide

[Yves_L]

Merci pour vos réponses

Je n'ai pas précisé qu'avec le changement de ports UDP, j'en avait profité pour faire une mise à jour Windows (sur le serveur qui pose souci comme sur l'autre) que je contrôle et effectue tous les 30 ou 45 jours environ.

Question backup, c'est régulièrement à jour sur le backup FTP mais les données de mon installation serveur et de sa base de données sont également sauvegardées sur un disque dur distant.

Concernant Kimsufi, il est vrai qu'à l'époque où j'ai loué ce serveur, c'était une solution abordable (50 euros sans la licence Windows) et plutôt performante par rapport à ce qui existait. Aujourd'hui, je n'envisagerais pas d'utiliser un des nouveaux serveurs Kimsufi qui ont désormais des spécifications bien différentes et pas de SLA contrairement à mes deux anciens Kimsufi. C’est vers Un SoYouStart que je m’orienterai pour un nouveau serveur.

Autre précision : les deux serveurs sont dans le même datacentre mais pas la même baie.

J’ai donc fait quelques tests. Un traceroute pour commencer :

Last login: Thu Apr  9 17:52:39 on ttys000
pc2:~ ******$ traceroute -m 15 grid.aire-mille-flux.org
traceroute to grid.aire-mille-flux.org (188.165.196.135), 15 hops max, 52 byte packets
 1  livebox (192.168.1.1)  2.919 ms  2.798 ms  2.878 ms
 2  80.10.120.229 (80.10.120.229)  24.279 ms  24.852 ms  24.584 ms
 3  10.125.115.202 (10.125.115.202)  92.961 ms  23.951 ms  25.961 ms
 4  xe-3-3-1-0.nclyo102.lyon.francetelecom.net (193.253.87.218)  24.480 ms  26.744 ms  24.089 ms
 5  ae41-0.nrlyo102.lyon.francetelecom.net (193.252.101.102)  26.528 ms  25.555 ms  25.613 ms
 6  81.253.182.198 (81.253.182.198)  24.608 ms  26.272 ms  24.521 ms
 7  * lyo-5-6k.fr.eu (178.33.100.181)  26.092 ms *
 8  th2-g1-a9.fr.eu (91.121.131.220)  30.855 ms  32.695 ms  31.668 ms
 9  rbx-g1-a9.fr.eu (91.121.131.209)  36.891 ms
    rbx-g1-a9.fr.eu (91.121.215.133)  34.368 ms
    rbx-g1-a9.fr.eu (91.121.131.209)  35.372 ms
10  vss-3b-6k.fr.eu (213.186.32.254)  81.602 ms  34.162 ms *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
pc2:~ ******$

Apparemment, il y a quelques soucis. Normalement il faut 11 hops pour arriver au server. Là, rien et il y a quelques astérisques qui se baladent lignes 7 et 10.

Au cas où, j’ai tenté d’afficher la page d’accueil IIS de mon serveur depuis Chrome, sans succès. Pas de message d’erreur, juste en tentative de connexion au nom de domaine du serveur.

Je continue les tests …

[Yves_L]

Merci pour vos réponses

Je n'ai pas précisé qu'avec le changement de ports UDP, j'en avais profité pour faire une mise à jour Windows (sur le serveur qui pose souci comme sur l'autre) ce que j'effectue habituellement tous les 30 ou 45 jours environ.

Question backup, c'est régulièrement à jour sur le backup FTP mais les instances et configurations de mon installation ainsi que sa base de données sont également sauvegardées sur un disque dur distant.

Concernant Kimsufi, il est vrai qu'à l'époque où j'ai loué ce serveur, c'était une solution abordable (50 euros sans la licence Windows) et plutôt performante par rapport à ce qui existait. Aujourd'hui, je n'envisagerais pas d'utiliser un des nouveaux serveurs Kimsufi qui ont désormais des spécifications bien différentes et pas de SLA contrairement à mes deux anciens Kimsufi. C’est vers Un SoYouStart que je m’orienterai pour utiliser un nouveau serveur..

Autre précision : les deux serveurs sont dans le même datacentre mais pas la même baie.

J’ai donc démarré quelques tests. Un traceroute depuis mon Mac pour commencer :

pc2:~ ******$ traceroute -m 15 grid.aire-mille-flux.org
traceroute to grid.aire-mille-flux.org (188.165.196.135), 15 hops max, 52 byte packets
 1  livebox (192.168.1.1)  2.919 ms  2.798 ms  2.878 ms
 2  80.10.120.229 (80.10.120.229)  24.279 ms  24.852 ms  24.584 ms
 3  10.125.115.202 (10.125.115.202)  92.961 ms  23.951 ms  25.961 ms
 4  xe-3-3-1-0.nclyo102.lyon.francetelecom.net (193.253.87.218)  24.480 ms  26.744 ms  24.089 ms
 5  ae41-0.nrlyo102.lyon.francetelecom.net (193.252.101.102)  26.528 ms  25.555 ms  25.613 ms
 6  81.253.182.198 (81.253.182.198)  24.608 ms  26.272 ms  24.521 ms
 7  * lyo-5-6k.fr.eu (178.33.100.181)  26.092 ms *
 8  th2-g1-a9.fr.eu (91.121.131.220)  30.855 ms  32.695 ms  31.668 ms
 9  rbx-g1-a9.fr.eu (91.121.131.209)  36.891 ms
    rbx-g1-a9.fr.eu (91.121.215.133)  34.368 ms
    rbx-g1-a9.fr.eu (91.121.131.209)  35.372 ms
10  vss-3b-6k.fr.eu (213.186.32.254)  81.602 ms  34.162 ms *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
pc2:~ ******$

Normalement au 11ème hop, mon serveur aurait dû être accessible, et il y a des astérisques qui se baladent lignes 7 et 10.

Au cas où, j'ai tenté d'atteindre la page par défaut du serveur depuis Chrome. C'est la page d'accueil IIS7 qui devrait s'afficher, mais Chrome n'y parviens pas. Pas d'erreur affichée, juste en attente de grid.aire-mille-flux.org…

Pour suivre le conseil de Janus57 je suis passé à un test MTR depuis mon Mac. J'ai lancé des commandes MTR plus ou moins espacées dans le temps et avec une moyenne sur 10 pings :

pc2:~ ******$ /usr/local/sbin/mtr -r grid.aire-mille-flux.org
Start: Thu Apr  9 11:13:39 2015
HOST: pc2.home                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home               0.0%    10    4.4   2.7   2.3   4.4   0.6
  2.|-- 80.10.120.229              0.0%    10   24.1  24.5  23.5  25.1   0.3
  3.|-- 10.125.115.202             0.0%    10   24.3  24.3  23.8  25.0   0.0
  4.|-- xe-3-3-1-0.nclyo102.lyon.  0.0%    10   23.4  24.4  23.4  25.7   0.3
  5.|-- ae41-0.nrlyo102.lyon.fran  0.0%    10   23.6  29.8  23.4  82.0  18.3
  6.|-- 81.253.182.198             0.0%    10   25.6  26.0  24.3  29.8   1.4
  7.|-- lyo-5-6k.fr.eu            70.0%    10   25.9  33.5  24.7  49.8  14.1
  8.|-- th2-g1-a9.fr.eu            0.0%    10   31.9  31.7  31.1  33.7   0.7
  9.|-- rbx-g1-a9.fr.eu            0.0%    10   36.3  36.1  33.6  38.2   1.3
 10.|-- vss-3b-6k.fr.eu            0.0%    10   34.4  37.4  34.2  59.9   7.9
 11.|-- ks309808.kimsufi.com       0.0%    10   33.9  36.7  33.7  54.3   6.2
pc2:~ ******$

pc2:~ ******$ /usr/local/sbin/mtr -r grid.aire-mille-flux.org
Start: Thu Apr  9 12:51:22 2015
HOST: pc2.home                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home               0.0%    10    2.3   2.5   2.3   3.1   0.0
  2.|-- 80.10.120.229              0.0%    10   24.0  24.3  23.6  25.8   0.5
  3.|-- 10.125.115.202             0.0%    10   24.4  24.0  23.5  24.4   0.0
  4.|-- xe-3-3-1-0.nclyo102.lyon.  0.0%    10   23.6  25.8  23.6  41.9   5.6
  5.|-- ae41-0.nrlyo102.lyon.fran  0.0%    10   24.6  24.9  23.4  26.9   1.1
  6.|-- 81.253.182.198            20.0%    10   25.1  25.2  24.2  26.6   0.5
  7.|-- lyo-5-6k.fr.eu            20.0%    10   24.9  47.9  24.6 125.1  36.6
  8.|-- th2-g1-a9.fr.eu            0.0%    10   30.7  33.3  30.3  49.8   5.9
  9.|-- rbx-g1-a9.fr.eu           20.0%    10   35.7  35.7  34.7  37.2   0.5
 10.|-- vss-3b-6k.fr.eu           10.0%    10   34.4 196.7  34.2 1134. 368.9
 11.|-- ks309808.kimsufi.com       0.0%    10   34.2  34.9  34.2  37.5   0.7
pc2:~ ******$

pc2:~ ******$ /usr/local/sbin/mtr -r grid.aire-mille-flux.org
Start: Thu Apr  9 13:22:30 2015
HOST: pc2.home                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home               0.0%    10    2.3   2.7   2.3   3.1   0.0
  2.|-- 80.10.120.229              0.0%    10   25.6  25.0  23.3  29.4   1.6
  3.|-- 10.125.115.202             0.0%    10   24.7  24.9  23.7  28.0   1.0
  4.|-- xe-3-3-1-0.nclyo102.lyon.  0.0%    10   24.6  25.2  23.6  29.3   1.7
  5.|-- ae41-0.nrlyo102.lyon.fran  0.0%    10   23.4  24.4  23.4  26.1   0.6
  6.|-- 81.253.182.198             0.0%    10   25.3  25.6  24.5  29.6   1.4
  7.|-- lyo-5-6k.fr.eu            50.0%    10   57.9  63.9  23.6 130.7  44.9
  8.|-- th2-g1-a9.fr.eu            0.0%    10   30.7  32.1  30.3  41.0   3.2
  9.|-- rbx-g1-a9.fr.eu            0.0%    10   38.5  37.4  35.3  44.1   2.6
 10.|-- vss-3b-6k.fr.eu            0.0%    10   33.5  39.4  33.5  74.4  12.4
 11.|-- ks309808.kimsufi.com       0.0%    10   34.3  35.2  33.6  39.3   1.5
pc2:~ ******$

Les pertes de paquets sont très variables et très importantes parfois. J’ai laissé tourner sans restriction pour voir ce qu'il se passait sur une durée plus importante :

                                     My traceroute  [v0.85]
pc2.home (0.0.0.0)                                                   Thu Apr  9 16:19:30 2015
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                     Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. livebox.home                                    0.0%  8837    2.3   2.2   2.1 236.6   7.8
 2. 80.10.120.229                                   0.0%  8837   26.4  23.8  22.6 285.7  11.4
 3. 10.125.115.202                                  0.0%  8837   24.8  24.1  22.2 303.5  14.9
 4. xe-3-3-1-0.nclyo102.Lyon.francetelecom.net      0.0%  8836   35.7  23.9  22.4 303.2  11.9
 5. ae41-0.nrlyo102.Lyon.francetelecom.net          0.0%  8836  139.6  29.4  22.3 315.3  22.2
 6. 81.253.182.198                                  0.4%  8836   26.6  24.6  23.3 308.4  10.8
 7. lyo-5-6k.fr.eu                                 22.0%  8836   25.1  40.0  22.8 524.3  42.7
 8. th2-g1-a9.fr.eu                                 0.0%  8836   31.4  30.8  29.6 356.4  11.4
 9. rbx-g1-a9.fr.eu                                17.2%  8836   34.6  35.8  33.3 293.7  11.2
10. vss-3b-6k.fr.eu                                 3.4%  8836  337.9  78.1  32.9 1896. 154.0
11. ks309808.kimsufi.com                            0.1%  8836   35.2  34.2  32.9 293.2  11.5

J’ai également fait un test MTR depuis le serveur vers ma box :

 |------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                         vss-3b-6k.fr.eu -    2 | 8337 | 8224 |    0 |   51 | 2028 |    0 |
|                         rbx-g2-a9.fr.eu -    1 | 8337 | 8332 |    0 |    1 |   32 |    0 |
|                         gsw-g1-a9.fr.eu -    1 | 8337 | 8331 |    0 |    1 |   31 |    0 |
|                          th2-5-6k.fr.eu -   87 | 8337 | 1166 |    0 |   13 |  375 |    0 |
|                         th2-g1-a9.fr.eu -    1 | 8337 | 8331 |    0 |    2 |   31 |    0 |
|                          lyo-5-6k.fr.eu -    3 | 8337 | 8161 |    0 |   20 |  343 |   78 |
|                   No response from host -  100 | 8337 |    0 |    0 |    0 |    0 |    0 |
|                          81.253.182.197 -    1 | 8337 | 8332 |    0 |   11 |  156 |    0 |
|  ae41-0.nclyo102.Lyon.francetelecom.net -    1 | 8337 | 8331 |    0 |    4 |   63 |    0 |
|   te4-1.nmlyo704.Lyon.francetelecom.net -    1 | 8336 | 8332 |    0 |    4 |  203 |   16 |
|                           80.10.120.229 -    1 | 8336 | 8328 |    0 |    2 |   32 |    0 |
|                   No response from host -  100 | 8336 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir  ( stanimir@cr.nivis.com )

Je suis très peu expérimenté dans ces domaines. Maintenant que je vois bien qu'il y a quelques soucis sur ce serveur, il me reste à savoir comment faire pour y remédier. Un redémarrage du serveur en mode Winpe Rescue ? Si oui, quelles procédures effectuer pour arranger tout ça ?

Merci pour vos éclairages.

[SD90078-OVH]

les 2 serveurs sont dans le même Datacenter/baie ?
parce que vu qu'il n'y a aucun SLA sur le réseau pour les kimsufi, un des 2 serveur est pt 'être dans une baie avec des voisins assez gourmands, et du coup, il ne vous reste rien.

faut pas oublier aussi que UDP, c'est le premier protocole a dégager en cas de congestion (0 SLA sur UDP aussi, mais la c'est pas la faute a OVH )

[janus57]

Bonjour,

je pense qu'il faut commencer par les tests basic MTR entre le serveur et un client qui a un problème, check du firewall, mise à jour de l'os (un serveur se met à jour c'est pas un PC personnel, si il se fait hack c'est tout vos clients qui ne pourront pas y accéder), et enfin on pense a une meilleur solution que KS pour ces clients vu que KS sont maintenant des serveurs de tests/apprentissage (0 SLA), donc même si c'est un vieux KS si votre HDD meurt vous allez pleurer (si pas de backup et si il se passe plusieurs jours avant le changement de HDD).

Cordialement, janus57

[Yves_L]

Bonjour,

J’ai un logiciel server installé sur un Kimsufi 24G dont les instances écoutent sur des ports UDP mais, depuis la fin mars, impossible pour les logiciels clients des utilisateurs de se connecter. Voici les spécifications du serveur :

Processeur Intel i7
Fréquence : 4x2(HT)x2.66+ Ghz
Architecture : 64 bits
NIC GigaEthernet
Mémoire vive : 24 Go
Disque dur : 2To
Backup FTP: 100 Go
Connexion réseau : 100 Mbps
bande passante : SLA standard 100 Mbps

Le sytème d'exploitation utilisé est Windows Server 2008 R2 SP1 Web Edition.

C’est une situation soudaine alors qu’aucune mise-à-jour ou maintenance quelconque n’avait été effectuée depuis au moins un mois avant cet incident. J’ai bien tenté d’ouvrir de nouveaux ports UDP et de les assigner à mes instances en tenant compte des ports UDP déjà utilisés par Windows. 12 des 22 instances sont de nouveau accessibles, mais toujours pas les 10 autres.

Je précise que j’utilise également un autre serveur Kimsufi, même spécifications hardware, même mise-à-jour Windows, même logiciel serveur avec les mêmes configurations et je n’ai pas ce problème.

Quelqu'un a-t-il une manip à me conseiller pour arranger ça ?

Merci d'avance pour votre aide