Bonjour,
Je viens poster ici par dépit : depuis plusieurs semaines maintenant, le support OVH me fait tourner en rond et je n'ai pas de réponse à la question. La question de leur côté est "ça marche" mais dans la réalité, cela ne fonctionne pas. Je vous explique.
L'objectif est de me connecter depuis mon hébergement à une base de données hébergée chez Hosting24. Pourquoi ? Parce que les bases SQL ne sont pas accessibles de l'extérieur chez OVH et j'ai donc mis en place une base SQL qui sert pour un logiciel.
Depuis le site OVH, il me faut donc me connecter à cette base.
J'ai un simple script de test qui permet juste de m'afficher "ok" ou "ko" pour savoir si la connexion se fait.
Si je mets ce script depuis un autre hébergeur, quel qu'il soit, la connexion est réalisée et j'ai bien un "ok". Si je mets le même script (un tout bête mysql connect !) sur le mutu OVH, rien... J'ai "la page a été réinitialisée" qui s'affiche au bout d'un certain temps et pas de connexion..
Le support m'a répondu "si, si, regardez vos logs, vous avez bien une connexion qui se fait..." mais dans la pratique, ce n'est pas le cas.
Au cas où vous posez la question, oui, j'ai autorisé l'ip d'ovh et même le domaine pour la connexion à Mysql chez Hosting24.
La question que je me pose et donc je n'ai pas la réponse : est-ce que l'adresse ip de l'hébergement est différente de celle qui est fourni sur la console OVH ?
Le support me dit "Oui, vous pouvez parfaitement vous connecter à une base externe depuis les mutualisés" mais jusqu'ici pas du tout...
Est-ce qu'une personne peut me donner des renseignements pour que je tente de régler ce problème ?
Merci pour toute l'aide que vous pourriez m'apporter, je suis bloqué et je vais me retrouver à être obligé de changer d'hébergeur pour que cela fonctionne...
Merci !
Hébergements Web - Connexion à une base externalisée depuis mutu ovh
Related questions
- Connexion à mon compte client
152662 
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
126183 03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
110418 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
97835 28.07.2017 11:39
- Passage en php 7.4
96963 30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
91276 04.12.2019 21:52
- The requested URL / was not found on this server
90474 02.03.2017 18:25
- Deploy d'un projet Node JS
90438 12.10.2016 20:18
- NextCloud sur mutualisé
90299 07.04.2017 08:42
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
90088 16.10.2016 16:24
C'est possible que l'adresse du Mutualisé qui effectuent la connexion SQL ne soit pas celle qui te permet d'accéder au cluster.
Le mieux est de tout autoriser très temporairement pour faire un test de connexion. Tu auras ainsi la réponse.
Bonjour,
Sur le mutualisé, l'accès sur les bases exterieur est possible, toutefois il est soumis à des règles de restrictions:
- 1 connexion par seconde avec des burst à 5 par secondes possible.
Cdt,
Bonjour Buddy,
Même en ajoutant %.%.%.% pour autoriser n'importe quelle ip à se connecter temporairement, cela ne sort toujours pas...
A Ludo : OK, mais impossible d'avoir un simple retour "ok" !
Quelle est l'erreur mysql ?
OK ou ko ça doit être ton script qui le renvoie.. Mysql renvoie aussi des erreurs plutôt claires, il faut les récupérer et voir déjà qu'elle est l'erreur.
Salut,
En fait, pas d'erreur du tout ! La page tourne, tourne, tourne et au final, erreur de chargement au bout de quelques minutes :
Le script est ici : http://1france.fr/connection-keziaxl.phpfrance.fr/connection-keziaxl.php
C'est un simple script de test de connexion donc qui va aller tenter de se connecter à la base sql chez Hosting24 (qui contient un logiciel de caisse qui se synchronise avec le site, le logiciel de caisse devant aller dans la base sql, d'où l'obligation d'utiliser une base sql utilisable de l'extérieur, ce qui n'est pas possible sur le mutu ovh). Le script de test est donc :
**********************************
[CODE]
$dbname = 'xxxxx';
$dbuser = 'xxxxx';
$dbpass = 'xxxxx';
$dbhost = 'xx.xx.xx.xx';
$connection = mysqli_connect($dbhost, $dbuser, $dbpass);
echo "
Testing connection to " . $dbuser . "
";$connection = mysqli_connect($dbhost, $dbuser, $dbpass);
if (!$connection) {
if (mysqli_connect_error()) {
$mysqli_connect_errno = mysqli_connect_errno();
$mysqli_connect_error = mysqli_connect_error();
echo 'Error! Erreur de connexion (' . $mysqli_connect_errno . ') ';
echo 'Error! Erreur de connexion (' . $mysqli_connect_error . ') ';
return;
}
}
echo 'YOUPI';
$connection ->close();
[/CODE]
**********************************
Rien de particulier et qui fonctionne donc partout SAUF sur le mutu...
Tu pourrais peut-être faire un test en mode DBO :
--> https://www.wordetweb.com/word-et-web/OVH-Tester-une-base-de-donnees-via-un-script-PDO-FR.htm OVH - Test de Base de Données via un script en langage PDO
Il est possible d'utiliser or die avec mysql pour justement capturer les erreurs..
Bonjour,
Toujours pareil : cela ne fonctionne pas...
- ajout d'un die directement dans le sql connect : le résultat est "impossible de se connecter:" avec aucune erreur d'affichée
- test avec le script pdo fourni en lien : même résultat.
Le constat semble que malgré ce qu'annonce OVH, la connection sur une base externe depuis un mutualisé OVH n'est pas fonctionnelle !
En PDO, voilà ce que j'ai comme retour :
[CODE]
Version de PHP : 5.6.30
$DBconnect = 'mysql:dbname=asiamark_test2;host=31.220.21.83;port=3306'
Etablissement de la connexion SQL en mode PDO
Connexion échouée : SQLSTATE[HY000] [2003] Can't connect to MySQL server on '31.220.21.83' (110)
Durée du traitement = 127.33 secondes
[/CODE]
Es-tu sûr des paramètres ?
As-tu essayé la même opération depuis ton PC avec un serveur local (http://www.uwamp.com/fr/?page=download UwAmp) ?
Cela te permettra de déterminer si le blocage vient de OVH ou du serveur SQL chez l'autre hébergeur.
Bonjour,
voilà la FAQ de votre hébergeur : https://www.hosting24.com/faq.php?ID=27
Donc ça semble compliquer de whitelister toute les IPs de sortie de OVH…
Cordialement, janus57
Re,
J'ai whitelisté l'ip du site renvoyée par le domaine (213.186.33.2 correspondant à l'ip mutu OVH où se trouve le fichier de test), 31.220.21.83 est l'adresse du serveur sql de Hosting24.
J'ai autrement testé sur de multiples plateformes : en local, depuis un dédié, depuis un autre hébergement, cela fonctionne partout !...sauf OVH Mutu....
C'est donc bien pour cela que je suis venu poster ici...
Tu es sur un cluster, rien ne dit que le serveur Web lorsqu'il tente une connexion sortante vers ton mysql passe par cette ip. Je dirais même que c'est sur que non..
Cette méthode ne marche pour les vps et dédiés
Bonjour,
sauf que cette IP doit être une IP d'entrée et non de sortie (ou si elle fait les 2 vous avez peu de chance de tomber dessus).
Il faut whitelister l'IP de sortie et OVH en a plusieurs par cluster sinon il se ferait vite blacklister par des prestataires ou les API sont beaucoup utilisé par les clients.
Cordialement, janus57
Re,
Bien sur... sauf que même si je laisse rentrer toutes les connexions (avec une autorisation en %.%.%.% qui laisse donc entrer toutes les connexions), cela ne marche pas non plus...
Bonjour,
vous êtes sûr que votre hébergeur vous autorise ce genre de whitelistage ?
Cordialement, janus57
Oui, c'est dans leur doc.
Donc, retour à la case départ...
Encore une fois : cela fonctionne PARTOUT sauf sur le mutu OVH !!! Alors qu'OVH me dit sur le support "Si, si, ça marche !".
Même script, même test. Mutu ovh : non.
Si j'avais une réponse OVH qui me dit "non, ce n'est pas possible" alors je dirai "ok, faut que j'aille voir ailleurs". Mais là, on me dit "ça marche", je teste avec vos différentes idées et le résultat est toujours le même. J'ai une autre personne qui a également testé et même résultat !
La question est donc plutôt : si cela est sensé fonctionner, pourquoi dans les faits cela ne fonctionne pas ???
Il semble y avoir un timeout..
Si c'était un mauvais mdp ça serait refusé direct et pas après 2 minutes..
Soit ovh bloqué la connexion sortante. Soit le provider bloque les requêtes depuis ovh.
Bonjour Buddy,
Oui, c'est ce qui me semble aussi. Comme j'autorise tout (ip, domaine, ip générique, etc... j'ai tout essayé), que cela fonctionne partout ailleurs, je pense effectivement que c'est la connexion sortante qui est bloquée par OVH contrairement à ce qu'ils me disent.
C'est peut être le couple ovh/ton provider qui coincé quelque part..
Bonjour,
avez-vous tester OVH -> autre hébergeur que hosting24 pour vérifier que c'est bien OVH qui bloque ?
Cordialement, janus57
Et pourquoi tu veux absolument être sur OVH mutu? (à part si tu as déjà payé pour un an)
Bonjour,
l'autre question serait plutôt : pourquoi ne pas avoir choisit un autre hébergeur français pour avoir la latence la plus faible possible ?
De plus chose marrante si je fait un traceroute depuis un VPS OVH cela semble tomber dans un blackhole/filtrage alors que depuis une connexion FAI cela va jusqu'au bout.
Du coup on dirait bien un blocage de hosting24 ou se son fournisseur vis-à-vis de OVH.
Depuis un VPS OVH dans le range 164.132.0.0/16
ping -c4 31.220.21.83
PING 31.220.21.83 (31.220.21.83) 56(84) bytes of data.
64 bytes from 31.220.21.83: icmp_seq=1 ttl=51 time=24.5 ms
64 bytes from 31.220.21.83: icmp_seq=2 ttl=51 time=24.5 ms
64 bytes from 31.220.21.83: icmp_seq=3 ttl=51 time=24.5 ms
64 bytes from 31.220.21.83: icmp_seq=4 ttl=51 time=24.4 ms
--- 31.220.21.83 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 24.482/24.518/24.549/0.027 ms
janus57@vps:~# traceroute 31.220.21.83
traceroute to 31.220.21.83 (31.220.21.83), 30 hops max, 60 byte packets
1 164.132.96.1 (164.132.96.1) 0.284 ms 0.290 ms 0.287 ms
2 222.ip-92-222-54.eu (92.222.54.222) 0.283 ms 0.286 ms 0.283 ms
3 51.255.178.190 (51.255.178.190) 0.282 ms 0.281 ms 0.279 ms
4 10.99.169.235 (10.99.169.235) 0.270 ms 10.99.168.129 (10.99.168.129) 0.295 ms 0.309 ms
5 be1-121.1a9.fr.eua9.fr.eu (37.187.232.50) 0.359 ms be1-120.1a9.fr.eua9.fr.eu (37.187.232.52) 0.384 ms be1-120.1a9.fr.eua9.fr.eu (37.187.232.48) 0.359 ms
6 * 10.95.48.8 (10.95.48.8) 3.922 ms 10.95.48.10 (10.95.48.10) 3.868 ms
7 be99-1254.1a9.fr.eua9.fr.eu (94.23.122.139) 6.257 ms 6.294 ms be99-1258.1a9.fr.eua9.fr.eu (91.121.215.219) 6.439 ms
8 be99-2.1a9.fr.eua9.fr.eu (37.187.36.214) 6.806 ms equinix.bb1.par1.fr.m247.com (195.42.145.83) 10.020 ms 10.019 ms
9 * * *
10 * * *
11 10.bb1.man1.uk.m247.com0.bb1.man1.uk.m247.com (77.243.185.197) 24.296 ms 24.716 ms 24.612 ms
12 te-13-6-0.1dc2.man4.uk.m247.comdc2.man4.uk.m247.com (77.243.185.56) 23.826 ms 23.804 ms 23.743 ms
13 te-7-4-0.1dc1.man4.uk.m247.comdc1.man4.uk.m247.com (77.243.176.104) 24.531 ms 24.609 ms 24.603 ms
14 176.10.80.150 (176.10.80.150) 24.413 ms 24.324 ms te-7-4-0.1dc1.man4.uk.m247.comdc1.man4.uk.m247.com (77.243.176.104) 24.638 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Donc la requête sort bien du réseau/routeurs OVH, mais après y a du filtrage sur ce qui semble être le fournisseur de hosting24
Voici la même chose depuis une connexion orange grand public
Détermination de l'itinéraire vers srv73.hosting24.com [31.220.21.83]
avec un maximum de 30 sauts :
1 2 ms 2 ms 1 ms LIVEBOX [192.168.1.1]
2 23 ms 22 ms 22 ms 80.10.126.88
3 22 ms 22 ms 22 ms 10.125.29.74
4 26 ms 25 ms 26 ms 10.nistr102.Strasbourg.francetelecom.net0.nistr102.Strasbourg.francetelecom.net [193.252.163.174]
5 25 ms 25 ms 24 ms 10.nistr101.Schiltigheim.francetelecom.net0.nistr101.Schiltigheim.francetelecom.net [81.253.180.117]
6 30 ms 29 ms 34 ms 193.252.137.82
7 37 ms 31 ms 31 ms 12.ffttr4.FrankfurtAmMain.opentransit.net2.ffttr4.FrankfurtAmMain.opentransit.net [193.251.133.7]
8 28 ms 28 ms 29 ms 1link.telia.netlink.telia.net [213.248.82.193]
9 30 ms 30 ms 31 ms 1link.telia.netlink.telia.net [62.115.138.70]
10 29 ms 30 ms 29 ms 1link.telia.netlink.telia.net [62.115.142.31]
11 30 ms 29 ms 29 ms 1b12.c.telia.netb12.c.telia.net [213.248.84.211]
12 * * * Délai d'attente de la demande dépassé.
13 * * * Délai d'attente de la demande dépassé.
14 * * * Délai d'attente de la demande dépassé.
15 50 ms 49 ms 49 ms 10.bb1.man1.uk.m247.com0.bb1.man1.uk.m247.com [77.243.179.65]
16 50 ms 50 ms 50 ms te-5-4-0.1dc1.man4.uk.m247.comdc1.man4.uk.m247.com [77.243.185.58]
17 52 ms 52 ms 53 ms 176.10.80.150
18 51 ms 54 ms 51 ms srv73.hosting24.com [31.220.21.83]
Là j'arrive au bout du bout (avec le double de ping certes, mais c'est du grand public).
Et pour info j'ai le même comportement (arrête du traceroute arrivé sur 176.10.80.150) depuis l'hébergeur online.net ainsi que onetsolutions (qui utilise le réseau de netrix connu sous le nom de AS62000 de mémoire).
Donc du coup je sais pas comment vous avez testé ou avec quel hébergeur cela fonctionne, mais il semble quand même y avoir un filtrage côté hosting24 ou tout du moins cela parait bizarre que les IP FAI peuvent faire un traceroute jusqu'au serveur cible alors que si on passe par un réseau d'hébergeur on se fait bloquer.
Cordialement, janus57