Discussion :

[Damdew]

Bonjour,

Nouveau sur ce forum, j'en profite pour vous poser une question qui me pose probleme.

Voici la config actuelle:

- Win 2003 SP1
- SQL 2000 SP3
- 2 interfaces réseau, chacune sur un VLAN
- 2 instances MS SQL, chacune comportant plusieurs BDD

Pour les instances:
- instance "1": protocole TCP activé sur port 1433, Named Pipes désactivé.
- instance "2": protocole TCP activé sur port 2433, Named Pipes désactivé

Je voudrait forcer l'ecoute de chaque instance sur une seule interface.
Actuellement, l'ecoute se fait sur les deux interface pour les deux instances.

Voici un extrait de la log de demarrage pour les deux instances.

La premiere:

Code :

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

1
2
3
2006-05-23 12:44:01.14 server    Serveur SQL à l'écoute sur 10.0.6.170: 1433.
2006-05-23 12:44:01.14 server    Serveur SQL à l'écoute sur 172.20.34.33: 1433.
2006-05-23 12:44:01.14 server    Serveur SQL à l'écoute sur 127.0.0.1: 1433.

et pour la deuxieme instance:

Code :

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

1
2
3
4
 
2006-05-23 12:43:59.59 server    Serveur SQL à l'écoute sur 10.0.6.170: 2433.
2006-05-23 12:43:59.59 server    Serveur SQL à l'écoute sur 172.20.34.33: 2433.
2006-05-23 12:43:59.59 server    Serveur SQL à l'écoute sur 127.0.0.1: 2433.

Avez-vous une idée ?

Merci pour votre aide.

[SQLpro]

Si mes souvenir sont exac, c'est dans :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp

mais j'en suis pas sûr !

Voir :
http://support.microsoft.com/kb/823938

A +

[rudib]

Bonjour,

Vous pouvez aussi faire le filtrage à la configuration des interfaces au niveau de l'OS. Dans Win 2000, il y a des options de filtrage TCP/IP, je suppose que c'est identique ou amélioré sur Win 2003.

[Damdew]

Merci pour la rapidité.

Les changements au niveau du registre n'influent que sur le port d'ecoute des instances. J'ai configuré via le registre le port 1433 pour l'un et le port 2433 pour l'autre.

Le port 1434 ne sert que dans le cas d'une allocation dynamique des ports, via une négociation avec le client a la connexion.

J'ai épluché le registre et rien ne precise l'interface reseau utilisée par telle ou telle instance. Il semble que par defaut, l'ecoute se fait sur chaque interface. Mais cela me parait leger de ne pouvoir le configurer outre mesure, la log mentionnant chaque interface independemment ...

La solution de bloquer au niveau de l'OS reste possible mais je prefere éviter de brider le fonctionnement de SQL Server via l'OS, celui-ci cherchera sans doute à réetablir le port d'écoute. J'ai peur que cela influe sur la stabilité et les performances générale...

[rudib]

Bonjour,

Je n'ai vu mentionner nulle part que l'interface d'écoute pouvait être choisie, à priori cela ne semble pas possible. Mais peut-être ai-je manqué qqch.
On pourrait d'ailleurs y voir une certaine logique : la couche applicative n'a pas forcément à s'occuper des interfaces réseau.

Le fait de bloquer le port en entrée pour une interface au niveau de l'OS ne devrait avoir aucune conséquence sur la stabilité du système ou le comportement de SQL Server. Les paquets en entrée sont rejetés par l'OS, SQL Server ne s'en aperçoit jamais et chaque instance ne reçoit des connexions que depuis le port laissé ouvert sur l'interface. C'est un genre de firewall local. Mettre un serveur SQL derrière un firewall ne trouble pas son bon fonctionnement.

[SQLpro]

Ce qu'il faut comprendre c'est que la gestion des écoutes de SQL Server est faites en fait par l'OS et non pas SQL Server lui-même. C'est donc bien dans l'OS qu'il faut paramétrer la chose et non dans SQL Server, à l'inverse de ce qui se fait en matière de mémoire ou disque (gérés par l'OS SQL Server).

A +

[Damdew]

Merci pour vos réponses, je vais donc bloquer cela via l'OS.

@ bientôt