Discussion :

[zooffy]

J'ai un nouveau paramettre qui va peut-être être utile pour comprendre : j'ai tenté d'installer le MembreShip du Framework .NET

C'est le truc qui permet de gérer des utilisateurs avec les contrôles de connexion du FrameWork .NET. ça crée des table et des Procédures Stockées qui commence toutes par aspnet_.

ça se configure avec l'outil aspnet_regsql.exe.

Le truc est simple : sur le serveur on lance cet exécutable qui se trouve dans le répertoire V2.0 du FrameWork dans Windows. Cet outil demande une conexion à une base de donnée. Il a trouvé tout seul le serveur et m'a demandé une connexion. J'ai renseigné l'utilisateur SA avec son mot de passe et là j'ai eu le même message que depuis ma machine cliente.

J'en déduis donc que j'ai dû oublier d'activer un truc, mais le quel, là est toute la question ?


[EDIT] : j'ai fait un autre test : j'ai activé mon serveur IIS et commencé à metre mon site en place. J'ai donc naturellement changé ma chaine de connexion à la BDD et spécifié mon utilisateur spécialement créé pour faire les connexion à partir du site Web.
Là, j'ai un autre message d'erreur qui me rassure : il ne trouve pas la première table qu'il doit ouvrir.

Pourquoi cela me rassure ? Parce que cela veut dire que le serveur IIS arrive, lui, à se connecter à la Base de donnée. Celle ci étant vide, c'est normal qu'il en trouve pas la table.

En espérant apporter des infos qui font avancer le souci, parce que je continue de chercher, mais je ne comprends toujours pas.

[mikedavem]

J'ouvre le Studio Management (sur le serveur), je me connecte sur l'instance (la seule que j'ai créée) avec le compte SA, je fais un clic droit sur le nom de l'instance, je choisi "propriétés".

Vous effectuez cette manipulation depuis votre poste client ou en local sur le serveur ?

++

[zooffy]

Sur le serveur, directement, j'ai un accés RDP dessus.

[mikedavem]

Je m'en doutais .. si vous faites le même test sur votre poste client, je pense que vous aurez le même souci que pour votre application

Vous pouvez essayer avec l'outil en ligne de commande sqlcmd si vous avez installé les outils de connectivité.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

> sqlcmd -S <ipserveur>\SQLExpress -U<user> -P<pass>

Que donne les commandes netstat -a et sqlcmd -L sur votre serveur ?

++

[zooffy]

La commande SQL donne cela sur ma amchine Client et sur le serveur directement :

C:\Users\Administrator>sqlcmd -S 82.165.146.31\SQLExpress -U odin -P *****
HResult 0xFFFFFFFF, Level 16, State 1
Interfaces réseau SQL Server : Erreur lors de la localisation de Server/Instance
spécifié [xFFFFFFFF].
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Une erreur liée au rése
au ou spécifique à l'instance s'est produite lors de l'établissement d'une conne
xion à SQL Server. Le serveur est introuvable ou n'est pas accessible. Vérifiez
si le nom de l'instance est correct et si SQL Server est configuré pour autorise
r les connexions distantes. Pour plus d'informations, consultez la documentation
en ligne de SQL Server..
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Délai d'attente de conn
exion expiré.

C:\Users\Administrator>

Netstat - a donne cela :

C:\Users\Administrator>netstat -a

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:25 s15425814:0 LISTENING
TCP 0.0.0.0:80 s15425814:0 LISTENING
TCP 0.0.0.0:110 s15425814:0 LISTENING
TCP 0.0.0.0:135 s15425814:0 LISTENING
TCP 0.0.0.0:143 s15425814:0 LISTENING
TCP 0.0.0.0:445 s15425814:0 LISTENING
TCP 0.0.0.0:1433 s15425814:0 LISTENING
TCP 0.0.0.0:3306 s15425814:0 LISTENING
TCP 0.0.0.0:3389 s15425814:0 LISTENING
TCP 0.0.0.0:8306 s15425814:0 LISTENING
TCP 0.0.0.0:8443 s15425814:0 LISTENING
TCP 0.0.0.0:8880 s15425814:0 LISTENING
TCP 0.0.0.0:47001 s15425814:0 LISTENING
TCP 0.0.0.0:49152 s15425814:0 LISTENING
TCP 0.0.0.0:49153 s15425814:0 LISTENING
TCP 0.0.0.0:49154 s15425814:0 LISTENING
TCP 0.0.0.0:49155 s15425814:0 LISTENING
TCP 0.0.0.0:49156 s15425814:0 LISTENING
TCP 0.0.0.0:49157 s15425814:0 LISTENING
TCP 0.0.0.0:49248 s15425814:0 LISTENING
TCP 82.165.146.31:53 s15425814:0 LISTENING
TCP 82.165.146.31:139 s15425814:0 LISTENING
TCP 82.165.146.31:3389 muz56-1-78-231-238-176:54319 ESTABLISHED
TCP 127.0.0.1:53 s15425814:0 LISTENING
TCP 127.0.0.1:953 s15425814:0 LISTENING
TCP 127.0.0.1:8106 s15425814:0 LISTENING
TCP [::]:80 s15425814:0 LISTENING
TCP [::]:135 s15425814:0 LISTENING
TCP [::]:445 s15425814:0 LISTENING
TCP [::]:1433 s15425814:0 LISTENING
TCP [::]:3389 s15425814:0 LISTENING
TCP [::]:8443 s15425814:0 LISTENING
TCP [::]:8880 s15425814:0 LISTENING
TCP [::]:47001 s15425814:0 LISTENING
TCP [::]:49152 s15425814:0 LISTENING
TCP [::]:49153 s15425814:0 LISTENING
TCP [::]:49154 s15425814:0 LISTENING
TCP [::]:49155 s15425814:0 LISTENING
TCP [::]:49156 s15425814:0 LISTENING
TCP [::]:49157 s15425814:0 LISTENING
TCP [::]:49248 s15425814:0 LISTENING
TCP [::1]:953 s15425814:0 LISTENING
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:1434 *:*
UDP 0.0.0.0:4500 *:*
UDP 0.0.0.0:5355 *:*
UDP 82.165.146.31:53 *:*
UDP 82.165.146.31:137 *:*
UDP 82.165.146.31:138 *:*
UDP 127.0.0.1:53 *:*
UDP 127.0.0.1:52850 *:*
UDP 127.0.0.1:65304 *:*
UDP [::]:500 *:*
UDP [::]:1434 *:*
UDP [::]:4500 *:*
UDP [::]:5355 *:*

C:\Users\Administrator>

Et sqlcmd -L donne cela

C:\Users\Administrator>sqlcmd -L

Servers:
S15425814\SQLEXPRESS


C:\Users\Administrator>

C'est bon comme résultat ?

[mikedavem]

Une question bête : est ce que votre hébergeur CLOUD vous permet d'attaquer le port 1433 ? Est ce qu'il n'aurait pas bloqué ce port ?

Pour pouvoir tester cela en attendant vous pouvez changer le numéro de port pour votre instance SQL Express dans le configuration manager et le protocole TCPIP. Mettez 1436 par exemple ou autre chose.

Une fois que vous avez redémarré le service SQL Server vous pouvez utiliser la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

> sqlcmd -S <ipserveur>,<port> -U<user> -p<password>

++

[zooffy]

Côté ouverture de port pas de soucis : l'hébergeur m'a bien spécifié que je faisais ce que je voulais, tout est ouvert.

Il y a juste les règles de Fire Wall à respecter :
- de base tout est fermé
- un groupe de règle système ouvre des ports tel que le 3389 (connex RDP) ou le 80 (conex HTTP)
- j'ai ajouté un groupe de règles spécifique qui ouvre le 1433 et le 1434 en TCP et en UPD à partir de toutes les adresses IP distantes (que je vérouillerais sur la mienne quand ça marchera)

Donc, j'ai rajouté des règles pour ouvrir aussi le 1436 et faire le test : même résulat.

Comme la règle de Fire Wall est que ce qui n'est pas explicitement ouvert est fermé et que j'ai explicitement ouvert les ports, je pense pouvoir dire que le souci n'est pas là.

Ce que je ne comprends pas c'est que même sur le serveur, directement, cela ne se connecte pas et là, je passe pas par le FireWall.

IIS se connecte et pas aspnet_regsql.exe, c'est ça que je trouve trés, trés bizarre.

[mikedavem]

Récalcitrant votre problème

Je résume :

- Vous avez vérifié les règles de port du firewall (entrantes et sortantes)
- Les accès distants autorisés sur votre instance SQL Server
- Le protocole TCP IP activé avec utilisation d'un port spécifique

- Les ports définis précédemment sont bien utilisés (netstat -a avec les ports en LISTED)

Vous pouvez à tout hasard vérifier si déjà vous pinger votre serveur avec l'adresse ip (truc bête mais je n'ai pas vu dans les précédents posts si vous l'avez fait)

Tentez également un tracert et telnet sur le port utilisé par SQL Server pour voir si celui-ci est actif

On va y arriver

++

[zooffy]

On va y arriver

++

Je n'en doute pas et merci pour tout.

Alors, le ping OK, ça roule avec des temps de réponse acceptables.

Le Telnet : pas possible, je suis sur windows Seven et l'outil n'est plus là, ou laors bien caché et je ne sais pas comment le retrouver.

Le tracert sur l'ip donne cela :

Microsoft Windows [version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tous droits réservés.

C:\Users\Erick>tracert 82.165.146.31:1433
Impossible de résoudre le nom du système cible 82.165.146.31:1433.

C:\Users\Erick>tracert 82.165.146.31

Détermination de l'itinéraire vers www.test.one [82.165.146.31]
avec un maximum de 30 sauts*:

1 <1 ms <1 ms 1 ms 192.168.0.254
2 21 ms 20 ms 20 ms 78.231.238.254
3 21 ms 21 ms 21 ms 213.228.39.126
4 23 ms 22 ms 23 ms stnazaire-6k-1-po1.intf.routers.proxad.net [212.
27.57.30]
5 * 24 ms 24 ms nantes-6k-1-po7.intf.routers.proxad.net [212.27.
57.34]
6 30 ms 30 ms 29 ms bzn-crs16-1-be1104.intf.routers.proxad.net [212.
27.50.185]
7 30 ms 29 ms 30 ms th2-crs16-1-be2000.intf.routers.proxad.net [212.
27.57.209]
8 37 ms 36 ms 37 ms strasbourg-crs16-1-be2000.intf.routers.proxad.ne
t [212.27.50.10]
9 41 ms 39 ms 43 ms francfort-6k-1-po100.intf.routers.proxad.net [21
2.27.56.30]
10 48 ms 46 ms 47 ms amsterdam-6k-1-po100.intf.routers.proxad.net [21
2.27.56.38]
11 46 ms 46 ms 46 ms amsix.bb-c.nkf.ams.nl.oneandone.net [195.69.144.
220]
12 53 ms 52 ms 53 ms te-4-1.bb-c.act.fra.de.oneandone.net [212.227.12
0.130]
13 55 ms 55 ms 55 ms te-3-3.bb-c.bs.kae.de.oneandone.net [212.227.120
.53]
14 55 ms 55 ms 56 ms ae-7.gw-distp-a.fs.kae.de.oneandone.net [212.227
.121.225]
15 55 ms 54 ms 54 ms ae-1.gw-prtr-r1-2a.fs.kae.de.oneandone.net [195.
20.247.202]
16 * * * Délai d'attente de la demande dépassé.
17 54 ms 55 ms 55 ms www.test.one [82.165.146.31]

Itinéraire déterminé.

C:\Users\Erick>

Avec le port, je ne sais pas comment le faire, l'expression que j'ai essayé en premier n'a pas fonctionné.
Par contre, je suis étonné d'avoir un délai dépassé en avant dernier et surtout, j'ai pu voir que je me balade pas mal.......

Pour info : www.test.one est une entrée que j'ai rajouté dans mon Host pour faire des tests sur les sites internet de mon serveur.

Un autre test à faire ?