Proxy transparant sans DNS

Support Debian
#1

Bonjour,

Je souhaite que les personnes se connectant sur mon réseau bénéficient automatiquement de mon proxy.

Mon réseau est très simple :

  • réseau : 192.168.1.0/24
  • Passerelle (freebox avec dhcp désactivé) en 192.168.1.254
  • Serveur dhcp / squid en 192.168.1.92 / debian stable up to date
  • Mon serveur proxy est dans sa configuration la plus simple

J’ai lu quelques tutos et ce qui me déplait, c’est qu’il semble falloir obligatoirement passer par un serveur DNS pour renseigner l’adresse du .pac. Je n’aime pas cette solution, sachant que ça alourdi ma conf, par le fait, j’aimerais plutôt diffuser ça via mon serveur dhcp et avec un peu de routage à côté.

Comme me conseillez vous de procéder ?

Par ailleurs, est-ce que les pac sont compréhensibles par iOS ou Android ?

Merci !

#2

Dans ce cas, le plus simple est probablement de mettre en place une configuration de proxy “transparent” je pense.

#3

Le proxy transparent a deux inconvénients :

  • il faut un serveur DNS pour résoudre les noms des sites,
  • ça ne marche pas pour HTTPS.

Concernant la config proxy par DHCP, je doute que tous les OS la prennent en compte.

#4

Merci pour vos réponses.

Mais je ne suis pas sûre de comprendre : Selon cette documentation liée à WPAD, en utilisant la méthode DHCP-WPAD, je transmets toutes les infos via le protocoles DHCP, je n’ai, sauf erreur et en toute logique, donc pas besoin de serveur DHCP propre.

Tel que je visualise la chose, j’aurais donc ceci :

  • un serveur DHCP configuré pour distribuer l’url où le PAC est disponible
  • un serveur apache pour distribuer ce PAC
  • des navigateurs sur le réseau configurés pour détecter automatiquement le proxy et utiliser ce dernier, sans intervention de ma part.

J’ai du mal à bien discerner la différence le déploiement PAC et le déploiement WPAD (toujours selon la doc que je vous ai donné).

/update :

Si j’en crois cette page :

Deployment Advantages Disadvantages
Explicit

Simple to deploy, does not require additional infrastructure.
Doesn’t require JavaScript knowledge.
Supported in all major browsers.



No fail-over functionality.
Proxy bypass lists are literal, browsers do not resolve host to IP and vice versa. Both the IP and host may need to be specified in the bypass list.

PAC

Proxy fail-over support.
Supported in all major browsers.
Ability to bypass proxy for specific hosts or IP addresses seamlessly.



Most deployments will require web server infrastructure.
Requires JavaScript knowledge.
Some browsers may fail closed if the PAC file is unavailable (e.g. when off-network).

WPAD

Includes all PAC advantages.
Deployment only requires a check box be selected.
Browser fails open if WPAD cannot locate a PAC file (e.g. when off-network).



Includes all PAC disadvantages.
Requires DNS or DHCP infrastructure changes.

Notez le dernier désavantage de WPAD, je cite : “Requires DNS or DHCP infrastructure changes.”

/update2 :

J’ai l’explication de l’existence des deux options possibles, par DNS et/ou par DHCP. Selon le tableau trouvé à cette adresse, tous les browsers ne supportent pas de la même façon de la WPAD et en fait, quand l’annonce par DHCP ne fonctionne pas, c’est visiblement l’annonce par DNS qui prend le relais.
D’après le tableau, l’annonce par DNS est supporté partout, y compris sur Safari dans IOS…

Je vais bricoler un lab et tester ça.

#5

Je ne vois pas comment un navigateur peut envoyer une requête DHCP. Le port source côté client est le port 68, c’est donc un port privilégié qui n’est pas utilisable par un processus lancé en tant que simple utilisateur.

#6

Non, je n’ai pas dis que le navigateur envoyait une requête DHCP, ce qui n’a effectivement aucun sens. Pour moi, cela fonctionne ainsi :

  1. requête DHCP qui renseigne le client avec :
  • IP
  • serveur DNS
  • adresse où trouver le wad.dat (c’est là que le DNS est utile, car il nous faudra un virtual host apache délivrant le wad.dat à l’adresse wad.localdomaine)

  1. résolution du wad.localdomaine

  2. récupération du wad.dat

  3. lecture du wad.dat et chargement des infos du proxy en variable d’environnement (spéculation, mais je suppose que ça fonctionne ainsi) comprises par nos navigateurs

  4. navigation à travers le proxy.

Est-ce que j’ai bien compris la chose ?

Par contre, stricto sensu, la définition de proxy transparent, ce n’est pas ça, n’est pas ? Un proxy transparent fonctionne par routage, si je dis juste, c’est au niveau d’u routeur que l’on envoie toutes les requêtes au proxy, et ce, totalement indépendamment d’une quelconque configuration côté client ?

#7

Ça suppose que le système d’exploitation, et plus particulièrement le client DHCP utilisé, supporte lui-même le WPAD et rende disponible les informations par un mécanisme standardisé.
Si c’est bien le cas, je doute que l’OS lui-même lise le contenu du fichier PAC. A mon avis il se contente de récupérer l’URL et de la mettre à disposition des clients web compatibles qui se chargeront de le télécharger.

En effet. C’est une interception du flux HTTP par un routeur ou un pont “transparent”, sans la coopération du client.