différence d'équilibrage de charge entre DNS et IP - transfert vs redirection
9
J'ai rencontré une situation que je ne peux pas comprendre. Nous avons un pare-feu Fortigate que nous avons activé pour effectuer l'équilibrage de charge sur deux serveurs Web principaux Apache. Un nom DNS est ensuite mappé sur l'IP virtuelle sur l'équilibreur de charge.
Comme prévu, lorsque vous accédez au nom / URL DNS (par exemple, www.something.com), le Load Balancer sert une page à partir de l'un des serveurs Web Apache principaux. L'URL dans le navigateur reste www.something.com . D'après ce que je comprends, dans ce cas, l'équilibreur de charge transfère simplement des paquets entre le navigateur et Apache tout en restant sur le chemin.
Cependant, si je navigue jusqu'à l' adresse IP à laquelle le DNS est mappé, alors l'équilibreur de charge renvoie un HTTP 302 trouvé, avec l'en-tête Location défini sur l'URL DNS de l'un des Apaches. L'URL dans le navigateur devient le DNS du serveur principal.
Pourquoi le Load Balancer redirige-t-il lorsqu'il est interrogé via IP, mais transfère-t-il correctement dans le chemin lorsqu'il est interrogé via le nom DNS.
Je n'ai pas utilisé de Fortigate FW pour l'équilibrage de charge, je vais donc répondre à certaines des questions de manière plus générale.
Tout d'abord, en ce qui concerne votre problème, l'équilibreur de charge fait exactement ce qu'il est censé faire et je pense que vos serveurs peuvent ne pas être configurés correctement pour répondre à une demande sur leur adresse IP. Si vous deviez tester cela derrière l'équilibrage de charge, vous pourriez définir le nom de domaine dans le fichier d'hôtes d'un client local, derrière le pare-feu avec le serveur et y accéder avec le nom de domaine et l'IP interne. Vous obtiendrez probablement le même résultat que vous voyez maintenant.
Je suppose que vous avez activé l'hébergement virtuel (pour prendre en charge plusieurs domaines sur un seul serveur) et que le "défaut" ne sert pas les mêmes pages que votre domaine. Vous récupérez une page Web du serveur dans les deux cas. Si vous avez besoin d'aide pour configurer votre serveur Web, vous souhaiterez peut-être essayer ServerFault .
Deuxièmement, pour entrer dans un peu plus de détails. Un équilibreur de charge fonctionne généralement au niveau L7 pour au moins les clusters HTTP et HTTPS. Cela signifie qu'ils ne se contentent pas de regarder l'adresse IP et de la transmettre, ni de "rediriger" la page.
Lorsqu'ils reçoivent une demande, ils analysent réellement la demande et la transmettent à un serveur après avoir traité la demande. Il y a beaucoup de choses qu'ils peuvent faire à ce stade, comme la réécriture des en-têtes dans les deux sens, l'ajout potentiel de cookies (pour la persistance) dans les données retournant au client, la fin des sessions SSL, la correspondance basée sur l'URL, etc.
Je vous recommande de passer du temps à lire entièrement les documents du fournisseur pour mieux comprendre le fonctionnement de l'équilibrage de charge (avec Fortigate, vous pouvez lire les leurs et Coyote Point - une autre société d'équilibrage de charge acquise par Fortigate). Comprendre ce qu'il fait vous aidera dans des cas comme celui-ci et vous permettra de déverrouiller des capacités dont vous ne saviez pas qu'elles existaient.
Le problème était une configuration sur le serveur Web principal Apache. Le nouveau nom DNS devait être ajouté en tant qu'alias.
Yusuf
3
Après avoir lu l' équilibrage de charge basé sur l'hôte HTTP dans le document Fortigate Load Balancing , je peux voir comment vous pouvez avoir une configuration d'équilibrage de charge atypique qui pourrait entraîner ce que vous décrivez. Cependant, sans une partie de votre configuration, nous ne pouvons pas être certains si c'est le cas pour vous.
Fortigate FortiOS permet de créer un serveur virtuel lié à des serveurs réels qui ont chacun une configuration d'en-tête d'hôte différente . Si des demandes correspondent au VIP de votre serveur virtuel, les demandes à charge équilibrée iront uniquement aux serveurs réels qui correspondent à cela host header. La partie la plus importante qui explique bien vos symptômes est que l'un des vrais serveurs peut omettre l'en-tête d'hôte pour qu'il corresponde à n'importe quel en- tête d'hôte.
Le serveur réel sans en-tête d'hôte peut avoir été configuré comme une sorte de «fourre-tout» qui atterrit sur un site qui effectue la redirection.
En utilisant l'exemple ci-dessous, seuls les 1er et 2e rservers gèrent le trafic correspondant à votre nom DNS préféré via l'en-tête d'hôte, mais le 3e rserver prend tout ce qui correspond à tous les autres en-têtes d'hôte, y compris le DNS VIP lui-même et envoie à un site qui pourrait faire une redirection .
config pare-feu vip
modifier "http-host-ldb"
définir le type d'équilibre de charge du serveur
définir extip 192.0.2.1
définir extintf "lan"
définir le type de serveur http
définir l'hôte http de la méthode ldb
set extport 80
config realservers
modifier 1
définir l'hôte http "www.example.com"
définir l'ip 192.168.2.1
définir le port 80
suivant
modifier 2
définir l'hôte http "www.example.com"
définir l'ip 192.168.2.2
définir le port 80
suivant
modifier 3
définir l'ip 192.168.2.3
définir le port 80
suivant
fin
fin
Je suppose que l'équilibrage de charge du pare-feu pourrait effectuer la redirection elle-même, mais nous ne pouvons pas le dire avec les informations limitées fournies.
Dans cette configuration, il est défini sur la correspondance basée sur le nom. Et c'est ça le problème. Si vous allez au VIP par adresse, il ne saura pas quoi en faire. (les règles NAT normales s'appliqueront alors)
Ricky Beam
La principale raison pour laquelle je ne pensais pas que c'était la réponse est qu'aucun FW / équilibreur de charge que je connais ne renverra un 302 avec l'emplacement défini sur le nom d'hôte / domaine de la ressource interne (au moins sans le configurer spécifiquement pour le faire donc, ce qui ne semblait pas être le cas sur la base de la question).
Apprendre
@RickyBeam, seul le premier des rservers fait la correspondance des noms d'hôte. Le dernier rserver correspondrait à l'adresse VIP en tant qu'hôte.
generalnetworkerror
@YLearn, je suis d'accord que ce serait étrange; Je disais que le serveur, pas le LB, aurait fait le 302 et aurait été configuré pour le faire. Je ne connais pas non plus de LB qui l'aurait fait.
Après avoir lu l' équilibrage de charge basé sur l'hôte HTTP dans le document Fortigate Load Balancing , je peux voir comment vous pouvez avoir une configuration d'équilibrage de charge atypique qui pourrait entraîner ce que vous décrivez. Cependant, sans une partie de votre configuration, nous ne pouvons pas être certains si c'est le cas pour vous.
Fortigate FortiOS permet de créer un serveur virtuel lié à des serveurs réels qui ont chacun une configuration d'en-tête d'hôte différente . Si des demandes correspondent au VIP de votre serveur virtuel, les demandes à charge équilibrée iront uniquement aux serveurs réels qui correspondent à cela
host header. La partie la plus importante qui explique bien vos symptômes est que l'un des vrais serveurs peut omettre l'en-tête d'hôte pour qu'il corresponde à n'importe quel en- tête d'hôte.Le serveur réel sans en-tête d'hôte peut avoir été configuré comme une sorte de «fourre-tout» qui atterrit sur un site qui effectue la redirection.
En utilisant l'exemple ci-dessous, seuls les 1er et 2e rservers gèrent le trafic correspondant à votre nom DNS préféré via l'en-tête d'hôte, mais le 3e rserver prend tout ce qui correspond à tous les autres en-têtes d'hôte, y compris le DNS VIP lui-même et envoie à un site qui pourrait faire une redirection .
config pare-feu vip modifier "http-host-ldb" définir le type d'équilibre de charge du serveur définir extip 192.0.2.1 définir extintf "lan" définir le type de serveur http définir l'hôte http de la méthode ldb set extport 80 config realservers modifier 1 définir l'hôte http "www.example.com" définir l'ip 192.168.2.1 définir le port 80 suivant modifier 2 définir l'hôte http "www.example.com" définir l'ip 192.168.2.2 définir le port 80 suivant modifier 3 définir l'ip 192.168.2.3 définir le port 80 suivant fin finJe suppose que l'équilibrage de charge du pare-feu pourrait effectuer la redirection elle-même, mais nous ne pouvons pas le dire avec les informations limitées fournies.
la source