Distribution EOLE » Modules » Amon

Je m'aperçoit que la solution que j'ai évoqué ne suffirait pas, en effet il faut avoir la conf spécifique complète actuelle (/etc/nginx/sites-enabled/wpad) pour WPAD.

Apres d'autres tests, il s'agit peut-être d'une fausse alerte. Les erreurs dans les logs de nginx m'ont peut-être conduit vers une mauvaise piste.
Je vais reprendre le cas de l'établissement qui rencontre le problème et renviendrais vers vous pour donner suite.

Apres de nouveaux essais, je confirme le problème suivant:

Lorsqu'une redirection HTTP est configurée dans le reverse proxy, cela provoque un problème dans la récupération du WPAD. Ce qui est étrange est que cela ne se produit qu'avec IE. Je n'ai pas testé tous les navigateurs mais il n'y a pas de problème avec FF et Chrome.

Voici une illustration d'un cas de figure:

Dans la conf de l'Amon, nous avons définit une redirection vers l'IP 172.16.240.1 pour le nom de domaine ent.maket-labo.ac-aix-marseille.fr.

Extrait de /etc/nginx/sites-enabled/default pour le reverse proxy:

# Configuration HTTP ent.maket-labo.ac-aix-marseille.fr
server {
    listen 80;
    server_name ent.maket-labo.ac-aix-marseille.fr;
    access_log  /var/log/nginx/access.log;
    error_page   403 404 502 503 504  /nginx.html;
    location = /guardian.html{
        root /usr/share/nginx/html;
    }
    location = /nginx.html{
        root /usr/share/nginx/html;
    }
    location / {
        proxy_pass              https://172.16.240.1;
        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Destination   $dest;
        set                     $dest  $http_destination;
        #2132
        index  50x.html;
        root /usr/share/nginx/html;
        }
}

Extrait de /etc/nginx/sites-enabled/wpad pour WPAD:

server {
    listen 80;
    server_name wpad.maket-labo.local;
    server_name wpad;
    root /var/www/;
    #for IE
    index wpad.$zone_name;
    #for firefox
    rewrite  ^/wpad.dat  /wpad.$zone_name  break;
    #deny all, so wpad.all too
    location / {
        deny all;
    }
    location /wpad.eth1 {
        default_type application/x-ns-proxy-autoconfig;

        echo_after_body '    return "PROXY 10.4.201.125:3128";';
        echo_after_body '}';

        allow 10.4.201.0/25;
        deny all;
    }

Et voici les logs de /var/log/nginx/access.log pour les 3 navigateurs testés:

10.4.201.122 - - [19/Oct/2016:12:25:40 +0200] "GET /wpad.dat HTTP/1.1" 404 206 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Win32; Trident/4.0)" 
10.4.201.122 - - [19/Oct/2016:12:26:03 +0200] "GET /wpad.dat HTTP/1.1" 200 2992 "-" "Mozilla/5.0 (Windows NT 5.1; rv:49.0) Gecko/20100101 Firefox/49.0" 
10.4.201.122 - - [19/Oct/2016:16:14:45 +0200] "GET /wpad.dat HTTP/1.1" 200 2992 "-" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36" 

On voit bien qu'on a un code de retour 404 dans le cas d'IE et 200 pour les autres.
Dans la pratique, on voit que IE n'a pas le bon script d'autoconfiguration car tous les accès aux sites HTTPS renvoient une erreur de certificat du fait que le navigateur tente de sortir en direct et ne s'adresse pas au proxy.

Peut-on penser qu'il puisse y avoir un conflit du fait que 2 vhosts sur le même port essaient de servir le WPAD en même temps? Il me semble que IE fonctionne différemment car il ne complète pas automatiquement les requêtes avec le nom de domaine local mais je ne vois pas en quoi les réponses sont différentes selon les requêtes WPAD des navigateurs.

Je ne suis pas sûr de la thèse de l'IP avec IE.
En patchant nginx.wpad pour y ajouter la ligne "server_name IP_eth0", le reverse proxy fonctionne et dessert bien le fichier lors d'une requête wget http://IP_eth0/wpad.dat. Mais WPAD ne fonctionne toujours pas avec IE.
Par contre nous avons résolu le problème en ajoutant bien tous les domaines des zones qui doivent utiliser la diffusion WPAD (admin.nom-etab.local, peda.nom-etab.local dans notre cas) en valeur de la variable "Nom de domaine du service WPAD". Jusqu'ici nous avions uniquement "nom-etab.local" et cela fonctionnait car en théorie les navigateurs sont censés essayer tous les sous-domaines du suffixe DNS du poste pour récupérer le fichier (https://blogs.msdn.microsoft.com/asiatech/2012/08/14/insight-wpad-proxy-settings-on-ie/), du coup même si wpad.admin.nom-etab.local ne répondait pas il le trouvait avec wpad.nom-etab.local.
Sauf que depuis que le vhost pour wpad tourne sur le port 80, pour une raison inconnue si le domaine exact du poste client n'est pas en server name du vhost du wpad et s'il y a d'autres vhost définits sur le port 80 dans le fichier de conf default de nginx (activation du reverse proxy pour un service web interne), il semble que ce soit d'abord le premier de la liste qui tente de répondre ce qui provoque un échec (tests effectués avec des fichiers sur un serveur web en proxy pass du 1er vhost de la liste sur le port 80).
Sinon on pourrait aussi peut-être contourner le problème en ajoutant un vhost au début du fichier de conf par défaut de nginx avec l'IP eth0 en server name et toute la conf pour wpad, mais ça ne serait pas tres propre et pourrait porter à confusion.