[Need help] Ping LAN vers OPT1 failed

jdh

C'est peu clair … Un schéma de principe serait utile ...

Quels sont les masques de réseau ?
Un réseau interne en /16 fait combien de host possibles ?
Pourquoi OPT1 ? Ne serait ce pas mieux de renommer en DMZ ?
Connaissez vous WPAD ?
Pourquoi le proxy a 2 adresses ? Pourquoi est-il relié à 2 zones (TRES GRAVE erreur de conception) ?
Pourquoi le proxy serait une "gateway" ? Est ce ainsi que vous espérer une translation de flux ?

Mythix

Bonjour JDH,

Désolé pour la réponse tardive mais en vacance… Ce qui m'a permis de réfléchir de d'effectivement voir qu'une seule pâte était nécessaire pour le proxy...

Voici un schéma afin de mieux comprendre ce que je souhaiterais faire :

En quelques mots, je souhaite que les requêtes HTTP et HTTPS venant du LAN passent par le proxy. Les autres types de connexions devant être directes (sans proxy). Je souhaite mettre en place cette architecture dans le but d’accueillir environ 250 postes sur mon LAN lors d’événement type LAN Party.

Pouvez-vous m'indiquer si ce type d'architecture tiens la route ?
Est-ce que si le proxy n'a qu'une seule et uniquement pâte cela ne va pas créer un goulot d'étranglement pour la connexion internet de tout les poste client sur le LAN ?

Je préférerais utiliser une redirection de flux (port forwarding) pour le proxy au lieu de mettre en place un wpad ou un proxy.pac.

Merci d'avance pour votre aide !

ccnet

Pas de problème pour l'architecture, c'est du classique.

je souhaite que les requêtes HTTP et HTTPS venant du LAN passent par le proxy.

Non pour https, pour des raisons techniques et juridiques.

Est-ce que si le proxy n'a qu'une seule et uniquement pâte cela ne va pas créer un goulot d'étranglement

Si toutes les interfaces sont en Gigabits, je doute que la connexion à internet fournisse un tel débit. Si goulot d'étranglement il y a ce ne sera pas sur votre infrastructure.

Mythix

Ok, merci pour cette info CCNET.

Par contre, au niveau de l'architecture, est-elle "bonne" ? En terme de sécurité et "best-practices" ?

ccnet

Pour moi l'architecture est cohérente avec le besoin et suffisamment sûre. C'est tout à fait ce que l'on pratique aujourd'hui.

Mythix

Je vais tâché de mettre en place cette archi et je vous tiens au courant.

Par contre j'ai une petite question, pour le port forwarding, il faut faire la redirection suivante ?
SRC : LAN subnet
DST : any
Port dest : 80
Port src : any
gateway : IP du proxy

C'est bien ça qu'il faut faire ?

Est-ce qu'en plus je dois ouvrir les ports 80 et 443 sur l'interface DMZ ?
Est-ce qu'en plus du port forwarding (LAN port 80 et 443 vers 3128 d'un serveur en DMZ) je dois ouvrir le port 3128 (squid) sur l'interface LAN vers la DMZ où se trouve le proxy ?

Merci d'avance

jdh

Le "port forwarding" est une vision "proxy transparent".
En apparence seulement, cela semble une bonne solution … mais en apparence seulement !

Je préconise la mise en place de WPAD pour accéder explicitement et automatiquement au proxy.
C'est un peu plus difficile mais cela fonctionne pour http et https !

Mythix

Effectivement, j'ai vu sur le net que le HTTPS n'était pas bien géré si on faisait du port forwarding.

J'ai tenté de mettre en place la redirection vers le proxy avec WPAD en suivant ce tuto : http://doc.pfsense.org/index.php/WPAD_Autoconfigure_for_Squid Malheureusement, je n'arrive pas à faire en sorte que ça fonctionne.

Voici les soucis que je rencontre :

En utilisant le navigateur IceWeasel (Debian 7) , si je configure le proxy en automatique et que je tente de me connecter sur un site web en http alors j'ai un Timeout et rien dans les logs de Squid. –> Cela me fait supposé que la redirection n'a pas fonctionné.
Si je configure le proxy en manuel dans les paramètre réseaude Debian pour le http et https, j'ai aussi un timeout sauf que j'ai ce message qui apparait dans les logs de squid : TCP_MISS/504 1571 GET http://halo.fr - DIRECT/halo.fr text/html
C'est toujours TCP_MISS/504 qui revient…
Notez que si je suis en proxy automatique et que je tente d'accéder à http://wpad.ludusnetwork.com/wpad.dat j'arrive bien à récupérer mon ficher wpad.dat qui contient ceci :

function FindProxyForURL(url,host)
{
return "PROXY 192.168.10.2:3128";
}

EDIT : Correction, je n'arrive pas à récupérer le fichier WPAD.dat avec Chromium alors qu'avec Iceweasel c'est OK… Je ne comprend pas. :(

Voici les configurations appliquées sur PFSense :

Configuration du DNS forwarder :

Configuration des règles FW sur l'interface LAN :

Configuration des règles FW sur l'interface DMZ :

Notez que le ping vers halo.fr depuis le serveur proxy est OK.
Que le ping de mon LAN vers le proxy est OK.

Avez-vous une idée d'où peut provenir le problème ?

jdh

Le lien indiqué sur WPAD me semble assez correct sauf sur un point important (voire essentiel) !

Le principe de WPAD sur DNS :

pour le domaine "par défaut" (des clients DHCP), il faut créer une définition (A) wpad.domaine.com qui va pointer sur un serveur web,
le serveur web doit fournir des fichiers (wpad.dat, proxy.pac au minimum et selon le type de navigateur !),
ces fichiers contiennent un petit script Javascript qui va fournir l'adresse du proxy,
le navigateur déduit donc l'adresse du proxy et fait sa requête au proxy.

Mais le serveur web doit fournir les fichiers en indiquant un type MIME peu habituel, comme indiqué dans
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/web-browser-auto-proxy-configuration.html (section ""Publishing PAC scripts for web browsers to download ).

En tout étant de cause, il faut d'abord tester en proxy explicitement indiqué avant d'activer le WPAD.
Par exemple, autoriser le traffic vers la DMZ du traffic tcp/3128.

Autre lien, moins pfsense, ! http://www.majorxtrem.be/2009/10/16/wpad-auto-configuration-dun-serveur-proxy/
ou le très classique http://irp.nain-t.net/doku.php/220squid:050_wpad

Mythix

Première victoire, si je configure l'adresse du proxy manuellement sur le poste client je vois bien que je passe par le proxy dans le fichier access.log de Squid ! :D (Et hop, une petite bière pour tout le monde car il faut savoir fêter les victoires :p).

Maintenant, mise en place du WPAD.
En lisant les différents liens que vous m'avez fournie, j'ai l'impression qu'il ne me manque juste qu'à rajouter quelques petites configurations dans la configuration du serveur web de PFSense mais je ne sais pas si c'est apache ou autre. Vous me confirmez que c'est bien apache le serveur web par défaut de PFSense ? Si tel est le cas, je ne trouve pas le fichier httpd.conf pour ajouter les lignes suivantes :

Redirect permanent /wpad.dat /proxy.pac
et,
AddType application/x-ns-proxy-autoconfig .dat

@jdh:

pour le domaine "par défaut" (des clients DHCP), il faut créer une définition (A) wpad.domaine.com qui va pointer sur un serveur web,

Tu parles bien du Host Overrides ici dans la rubrique DNS forward de PFSense que j'ai créé ?

Cf image suivante :

@jdh:

le serveur web doit fournir des fichiers (wpad.dat, proxy.pac au minimum et selon le type de navigateur !),

Ok pour cette partie, j'ai fait wpad.dat, wpad.daet proxy.pac.

@jdh:

ces fichiers contiennent un petit script Javascript qui va fournir l'adresse du proxy,

Mes 3 fichiers contiennent le même code JS. (Redirection vers proxy).