Introduction #
Un serveur proxy peut être décrit comme un dispositif serveur ou une application qui sert d'intermédiaire pour les requêtes de clients cherchant à accéder aux ressources de différents serveurs. Autrement dit, un serveur proxy agit pour le compte du client lors de la demande de service, masquant potentiellement l'origine réelle de la requête auprès du serveur principal.
Le processus consiste pour le client à adresser directement sa requête au serveur proxy, au lieu de se connecter uniquement à un serveur spécifique capable de fournir la ressource demandée (fichiers, pages web, etc.). Le serveur proxy évalue ensuite cette requête et effectue les transactions réseau appropriées. Cette approche permet de simplifier et de mieux contrôler la complexité de la requête, tout en offrant d'autres avantages tels que la sécurité, l'accélération du chargement du contenu et la protection de la vie privée. Les proxys sont conçus pour encapsuler et structurer les systèmes distribués existants. Parmi les proxys de navigation web les plus utilisés, on trouve Squid , Privoxy et SwiperProxy.
Parfois, un serveur proxy ne suffit pas à gérer le nombre d'utilisateurs simultanés, ou le proxy lui-même constitue un point de défaillance unique qui doit être corrigé ; c'est alors qu'un ADC est absolument nécessaire.
L'article suivant décrit un moyen de créer une haute disponibilité et une évolutivité pour un service proxy de navigation. En cas de panne de l'un des serveurs proxy, l'équilibreur de charge, implémenté avec Reliianoid Application Delivery Controller, détectera la panne et le proxy sera désactivé du pool disponible, de plus, le client sera redirigé vers un autre proxy de navigation disponible sans affecter les connexions de trafic.
Architecture de réseau proxy #
Dans l'idée de mieux faire comprendre au lecteur la configuration, nous souhaitons atteindre le schéma suivant qui décrit l'architecture.
Les différents clients (ordinateurs portables, ordinateurs de bureau, téléphones mobiles et tablettes) configurent leur navigateur de navigation pour pointer vers le proxy d'entreprise, par exemple https://proxy.company.com:3128 . Toutes les connexions des clients vers le proxy de navigation web, en HTTP simple ou SSL, seront basées sur TCP ; ce protocole servira donc à la mise en place de notre système d'équilibrage de charge.
La résolution IP pour proxy.company.com est une adresse IP virtuelle déjà configurée dans l'équilibreur de charge. Dans le contrôleur de distribution d'applications Relianoid, une ferme de serveurs est configurée sur cette adresse IP virtuelle, par exemple 192.168.103.34 , et le port virtuel 3128 est en mode NAT pour le protocole TCP.
La ferme est configurée avec tous les serveurs backend qui constituent le pool de proxys de navigation, dans notre exemple 192.168.103.253 et 192.168.103.254 via le port TCP 3128. Dès qu'un client tente de se connecter au proxy configuré, l'ADC reçoit la connexion et la redirige vers l'un des proxys de navigation disponibles dans le pool, répartissant ainsi les utilisateurs entre tous les serveurs proxy backend disponibles.
Configuration de la haute disponibilité du proxy de navigation Web #
La section suivante décrit la procédure de configuration afin de créer une configuration appropriée pour les proxys de navigation d'équilibrage de charge dans l'équilibreur de charge Reliianoid.
Vérification de l'état du proxy de navigation Web #
Tout d'abord, créez une vérification de l'état pour être utilisée dans la batterie d'équilibrage de charge que nous allons créer dans les lignes suivantes. L'objectif de cette nouvelle vérification de l'état est de vérifier que le port TCP dans les proxys backend est activé.
Accédez à la section SURVEILLANCE > Farmguard , créez un nouveau Farmguardian nommé check_tcp_navigation_proxy et copiez-y les paramètres de check_tcp , puis effectuez quelques modifications mineures au niveau des délais d'attente, comme indiqué ci-dessous :
Dans le champ Commande , ajoutez l'option `-t 5` . Ce paramètre correspond au délai d'attente par serveur dorsal pour répondre à la connexion TCP provenant de l'équilibreur de charge. Le champ Intervalle est configuré à 11,5 secondes par serveur dorsal, plus 1 seconde supplémentaire pour éviter les appels récursifs. Nous vous recommandons d'utiliser la formule suivante pour définir la valeur optimale de l'intervalle .
(nombre de backends * secondes d'expiration par backend (-t)) + 1
Service virtuel de proxy de navigation Web #
Créez ensuite une ferme LSLB > L4xNAT , par exemple nommée navigation_proxy , en incluant l' adresse IP virtuelle et le port virtuel comme indiqué dans le schéma précédent. Une fois créée, passez en mode avancé pour l'édition et vérifiez que le type de protocole est configuré sur TCP et le type NAT sur NAT.
Pour configurer le comportement du service virtuel, accédez à l'onglet Services et configurez l'algorithme d'équilibrage de charge dans le champ Poids (par défaut). Veuillez adapter cette valeur à votre environnement et au comportement souhaité.
Ensuite, dans la même section, accédez au tableau Backends et ajoutez les serveurs proxy de navigation Web réels qui géreront les connexions des utilisateurs.
Enfin, sélectionnez le contrôle d'intégrité déjà créé à l'étape précédente et nommé check_tcp_navigation_proxy afin de vérifier que le port backend TCP est déjà ouvert.
Désormais, le service virtuel à charge équilibrée peut être testé avant de configurer les clients.
Configuration des clients #
La dernière étape consiste à configurer les paramètres de proxy dans le navigateur Web du client en les faisant pointer vers l' adresse IP virtuelle et le port virtuel utilisés dans l'équilibreur de charge, ou à introduire l' adresse IP virtuelle dans le DNS coopératif et à utiliser un nom à la place dans les clients (dans notre exemple, proxy.example.com pointe vers l'adresse IP virtuelle 192.168.103.34 ).
Enfin, profitez de votre proxy de navigation Web à charge équilibrée avec une haute disponibilité!
