Phase 4 : Cluster de Proxys Squid avec Keepalived


1. Objectif de ce Document

Ce document détaille la mise en place d’un cluster de 4 serveurs proxy utilisant Squid pour le filtrage web et Keepalived pour assurer la haute disponibilité.

L’objectif est de créer un point de sortie Internet unique, filtré et résilient pour tous les utilisateurs du réseau. Le trafic web sera contrôlé, l’authentification des utilisateurs sera transparente (SSO), et la panne d’un ou plusieurs serveurs proxy n’interrompra pas le service.

2. Le “Pourquoi” : Le Poste de Garde Intelligent du Lycée

Imaginez la sortie du lycée qui mène vers la ville (Internet).

  • Squid, c’est le Garde de Sécurité. Son rôle est multiple :

    1. Vérifier l’identité : Il demande à chaque élève sa carte d’identité pour savoir qui il est. C’est l’authentification Active Directory transparente (Kerberos).
    2. Appliquer le règlement : Il a une liste de lieux interdits (sites de réseaux sociaux, sites pour adultes…). C’est le filtrage web via les blacklists.
    3. Tenir un registre : Il note qui va où et à quelle heure. Ce sont les journaux d’accès (logs).
  • Keepalived, c’est le Système de Relève Automatique. Avoir un seul garde est risqué. S’il tombe malade, la sortie est sans surveillance ou bloquée. Keepalived met en place une équipe de gardes :

    1. Une Adresse Virtuelle : Les élèves ne connaissent que l’emplacement du “Poste de Garde” (10.0.20.254), pas le nom du garde qui s’y trouve. C’est notre IP virtuelle.
    2. Un Garde “Actif” (MASTER) : Un seul garde est au poste à un instant T.
    3. Des Gardes en “Réserve” (BACKUP) : Les autres gardes sont en salle de repos, mais écoutent en permanence la radio.
    4. La Bascule (Failover) : Si le garde actif ne répond plus à la radio, un des gardes en réserve sort immédiatement et prend sa place au poste. Pour l’élève, le changement est invisible, il y a toujours eu un garde au poste.

Ce duo nous offre un filtrage puissant (Squid) et une résilience à toute épreuve (Keepalived).

3. Prérequis

  • Quatre conteneurs LXC Debian 13 ont été créés (ct-deb-proxy-01 à 04).
  • Cinq adresses IP ont été réservées :
    • 10.0.20.31 à 10.0.20.34 pour les conteneurs.
    • 10.0.20.253 pour l’IP virtuelle du cluster, qui sera l’adresse du proxy pour les clients.
  • Un compte de service a été créé dans l’AD pour Squid (squid-reader).

4. Procédure Pas-à-Pas

Étape 1 : Installation et Configuration de Squid

Cette étape doit être réalisée à l’identique sur les quatre conteneurs.

  1. Installation : apt update && apt install squid.
  2. Configuration : Remplacez le contenu du fichier /etc/squid/squid.conf par la configuration que vous avez fournie.
    • Analyse de notre configuration squid.conf :
      • auth_param negotiate et auth_param basic : Configurent une authentification double. Le proxy essaie d’abord une authentification Kerberos transparente (SSO pour les clients Windows du domaine). Si cela échoue, il propose une authentification LDAP de secours (fenêtre de login/mot de passe).
      • acl auth_users proxy_auth REQUIRED : Crée une liste de contrôle d’accès qui ne correspond qu’aux utilisateurs qui ont réussi à s’authentifier.
      • acl ads dstdomain ... etc. : Définit nos listes de blocage en se basant sur des fichiers externes (les blacklists de l’Université de Toulouse).
      • http_access deny ads et autres : Applique les règles de blocage. L’ordre est crucial : les règles de deny sont lues en premier.
      • http_access allow localnet auth_users : C’est la règle principale. Si un utilisateur est bien authentifié et qu’aucune règle de blocage ne s’est appliquée, il est autorisé.
      • http_access deny all : La règle de sécurité finale. Tout ce qui n’a pas été explicitement autorisé est interdit.
  3. Démarrage du service : systemctl start squid.

Étape 2 : Installation et Configuration de Keepalived

La configuration sera légèrement différente entre le nœud MASTER et les nœuds BACKUP.

  1. Installation sur les 4 nœuds : apt install keepalived.
  2. Configuration du nœud MASTER (ct-deb-proxy-01) :
    • Éditez /etc/keepalived/keepalived.conf :
      vrrp_instance VI_1 {
          state MASTER
          interface eth0
          virtual_router_id 51
          priority 150
          advert_int 1
          authentication {
              auth_type PASS
              auth_pass 1111
          }
          virtual_ipaddress {
              10.0.20.253
          }
      }
      
  3. Configuration des nœuds BACKUP (02, 03, 04) :
    • Utilisez la même configuration, mais changez deux lignes :
      • state BACKUP
      • priority 100 (une priorité inférieure à celle du MASTER).
  4. Démarrage du service sur les 4 nœuds : systemctl start keepalived.

Étape 3 : Déploiement de la Configuration par GPO

  1. Créez une nouvelle GPO GPO-Proxy-Settings.
  2. Éditez la GPO. Allez dans : User Configuration > Preferences > Control Panel Settings > Internet Settings.
  3. Faites un clic droit > New > Internet Explorer 10.
  4. Allez dans l’onglet Connections > LAN Settings.
  5. Cochez “Use a proxy server…“.
    • Address : 10.0.20.253 (l’IP virtuelle).
    • Port : 3128.
  6. Liez cette GPO aux OUs contenant vos utilisateurs.

5. Points de Validation

  • Validation du Proxy :
    • Sur un poste client, après un gpupdate /force, ouvrez un navigateur. Essayez d’aller sur un site web.
    • Sur le proxy MASTER (ct-deb-proxy-01), consultez les logs en direct avec tail -f /var/log/squid/access.log. Vous devriez voir les requêtes apparaître avec le nom de l’utilisateur AD qui navigue.
  • Validation du Filtrage : Essayez d’accéder à un site qui devrait être bloqué (ex: facebook.com, si socialnet est dans vos blacklists). Vous devriez obtenir une page d’erreur de Squid.
  • Validation de la Haute Disponibilité :
    1. Lancez un ping -t 10.0.20.253 depuis un poste client.
    2. Sur Proxmox, arrêtez le conteneur ct-deb-proxy-01.
    3. Observez le ping : vous devriez perdre 1 ou 2 paquets au maximum, puis les réponses devraient reprendre.
    4. Sur l’un des nœuds BACKUP (ex: ct-deb-proxy-02), tapez la commande ip a. Vous devriez voir que l’interface eth0 a maintenant récupéré l’adresse IP virtuelle 10.0.20.253.
    5. La navigation Internet sur le poste client doit continuer à fonctionner sans interruption.

La Phase 4 est terminée. Nous disposons maintenant d’une pile de services complète, supervisée, et d’un accès Internet sécurisé et résilient. Nous sommes prêts à aborder la Phase 5 : Sécurité et Continuité d’Activité.