Problèmes de connexion SQL / serveur IIS 7/2008

Question

En essayant de connecter un serveur 2008 à un serveur SQL, j’ai remarqué un changement dans la pile IP 2008 qui m’avait un peu flétri. Je cherche soit un moyen d’exploitation de ce système, soit un moyen de programmation dans .NET, pour le remplacer.

Par souci d’argument, supposons que j’ai un serveur Web avec plusieurs adresses IP pour desservir plusieurs sites, se connectant à plusieurs ressources (service Web, SQL, etc.) derrière un pare-feu.

SERVER IP:   10.10.10.1
SITE1 IP:    10.10.10.10
SITE2 IP:    10.10.10.11

SQL SERVER:  10.10.10.2
WEB SERVICE: 10.10.10.15

Le pare-feu est configuré naturellement pour tout refuser, n'autoriser que ce qui est nécessaire. En d'autres termes:

ALLOW FROM 10.10.10.1 TO 10.10.10.2
ALLOW FROM 10.10.10.1 TO 10.10.10.15
DENY ALL

Avant Windows 2008, Windows 2000/2003 utilisait toujours l'adresse IP de base de la machine (10.10.10.1) pour demander des ressources réseau. Ainsi, les règles de pare-feu ont été respectées et l'accès a été accordé. Sous 2008, il semble que le choix qui se rapproche le plus se trouve:

La connexion à 10.10.10.2 provient d’IP 10.10.10.1. Le pare-feu est heureux. La connexion à 10.10.10.15 provient de IP 10.10.10.11, le pare-feu refuse les connexions.

La suppression de tous les IPS virtuels de la carte réseau fait bien sûr fonctionner les choses, car chaque volonté vient ensuite 10.10.10.1

Maintenant, je comprends un peu que si cette machine avait deux cartes réseau, cela a du sens en raison des modifications apportées à la mise en œuvre de RFC3484 et IPv6 ( http://support.microsoft.com/kb/968920 ) et un modèle hôte fort / faible entre en jeu, mais pour ma vie, je ne comprends pas pourquoi cela aurait dû changer fonctionnement de l'IP avec une seule carte réseau.

J'ai une demande d'assistance en cours et je ne mène nulle part. J'entends marmonner «Ouvrez simplement votre pare-feu pour permettre les connexions à partir de 10.10.10.11». Ce n'est pas pratique Cela voudrait dire qu’il faudrait ajouter une règle d’autorisation pour chaque adresse IP sur une machine multiréseau unique réservée aux fenêtres uniquement pour Windows 2008. Je ne peux pas croire que percer plus de trous dans votre pare-feu rien que pour 2008, la pile ip est une bonne réponse.

Existe-t-il un moyen de désactiver cette "fonctionnalité"? en 2008 au niveau de la machine? Existe-t-il un moyen de désactiver cela dans .NET au niveau de la machine? Existe-t-il un moyen de désactiver cela par connexion (SqlConnection, WebClient)?

Answer 1

Vous constatez les effets secondaires du calcul automatique de métrique de route. Lorsque plusieurs adresses sont en route vers une adresse et que l'option Metrics automatique (dans les paramètres avancés ... sous TCP) est activée, Windows utilise try et la prédiction du paramètre "le plus rapide". chemin d'accès à cette adresse.

Je soupçonne que vos deux interfaces (virtuelle ou autre) ont les mêmes métriques de route. Le choix n’est donc pas déterministe. Vous pouvez l'encourager à utiliser votre " back-edge " address for en définissant une métrique de route plus élevée sur vos adresses .10 / .11. Les métriques automatiques étant désactivées, vous pouvez également prescrire un itinéraire statique explicite à l’aide de votre adresse 10.10.10.1.

Plus de détails sur TechNet - recherchez sur la page des métriques automatiques.

http://technet.microsoft.com/en-us/library/bb727001.aspx

Pour le meilleur ou pour le pire. Si les deux interfaces annoncent un chemin avec des métriques égales, l'une ou l'autre des interfaces peut être gagnante. Le comportement dans le passé était non déterministe - il a changé.

La meilleure approche consiste à utiliser route sur la ligne de commande pour créer une route TCP statique persistante avec un coût inférieur ou inférieur entre 0,1 et 0,2. Augmentez alternativement le coût de chaque itinéraire sur 0,14 & amp; .15 adresses. J'utiliserais l'ancien car il y a moins de maintenance et moins d'effets secondaires sur les autres communications.