[carles65]

Bonjour,


Je suis en stage en entreprise pour 2 mois, et mon objectif est d'installer un serveur proxy « Squid » sous RedHat et de faire un script pour la configuration automatique du proxy pour chacun des postes des membres de l'entreprise.


Dans un premier temps, j'effectuerais mes tests sur machine virtuelle (VMWARE) puis une fois validé, j'installerais Red Hat sur la machine réelle.


Donc, j'ai créer une machine virtuelle Linux avec la version de Debian installé et trois machine XP virtuelles.


Donc, je voudrais que ma machine Debian, ou sera installé le proxy Squid, soit connecté à Internet et qu'elle puisse communiqué avec les trois autres machines.


Je voudrais savoir quelles sont les réglages à mettre pour mes cartes Ethernet afin que la machine Debian communique avec Internet et que la machine XP passe passe par la machine Debian (proxy) pour accéder au WEB.


Faut-il 2 cartes pour la machine Debian et 1 seule pour la XP?


Je vous donne la configuration de mes machines atuellement :


PC réel :
IP : 192.168.1.171 255.255.255.0 192.168.1.1 DNS :194.2.0.20 194.2.0.50


Debian :
eth0 (Bridged): 192.168.1.186 255.255.255.0 (broadcast) 192.168.1.255 (passerelle) 192.168.1.1 DNS : 194.2.0.20
eth1 (Vmnet2) : 192.168.2.186 255.255.255.0 (broadcast) 192.168.2.255 (passerelle) 192.168.2.1 DNS : 194.2.0.20
lo : 127.0.0.1 255.0.0.0


XP1 (Vmnet2) :
IP : 192.168.2.179 255.255.255.0 (passerelle) 192.168.2.1
DNS : 194.2.0.20

Avec cette configuration, Debian ping bien XP1 et le PC réel, et résout www.google.fr.
XP1 ping bien Debian mais pas le PC réel et il ne trouve pas www.google.fr ni son adresse IP 216.239.59.99


Une fois cela résolu, il faut que j'installe Squid afin que XP1 passe par la machine Debian pour accéder à Internet.


Donc, quelqu'un pourrait me dire pourquoi la communication entre XP1 et l'Internet ne fonctionne pas svp.


Ps: Avec les deux machines avec 1 seul carte chacune sur Bridged, la connexion au WEB fonctionne aussi bien pour la Debian que pour la XP.


Merci d'avance.

Edit::
XP1 (Vmnet2) :
IP : 192.168.2.179 au lieu IP : 192.168.1.179

[Matt]

La carte virtuelle de ta VM XP1 est bridgée vers ton réseau réel, donc sur le réseau 192.168.1
Par contre, tu l'as configurée avec 192.168.2.1 comme passerelle, qui est une IP du réseau Vmnet2, auquel ta VM XP1 n'est pas raccordée.
Il faut donc que tu changes la conf de la carte réseau de XP1 dans VMWare pour la connecter au réseau Vmnet2 plutôt qu'au réseau réel.
Ensuite, tu attribues une adresse en 192.168.2 à ta VM dans la conf réseau de XP (sauf si ta Debian fait aussi DHCP) et si ta Debian est configurée correctement pour faire passerelle (si c'est pas fait, tu peux trouver les explications ici : http://lurl.eu/4O), tout devrait fonctionner.

[carles65]

Ma carte virtuelle VM XP1 est VMNET2 deja.

J'ai remis 192.168.1.1 comme passerelle a XP1.

192.168.2.1 n'existe pas comme paserelle

Donc, en faite j'ia pas besoin d'une deuxieme carte sur ma Debian?
Une seule interface eth0 192.168.1.186, pas de 192.168.2.186?

[Matt]

Si ta machine XP est déjà sur VMnet2, y a un problème d'IP, car elle a une IP en 192.168.1 du réseau réel, il lui en faudrait une en 192.168.2 du réseau virtuel.

Il faut donc que tu mettes ta Debian en 192.168.1.x sur son eth0, bridgée avec le réseau réel (ce qui lui donne donc accès au net via cette interface) et avec 192.168.1.1 comme passerelle sur cette interface.
Sur le réseau VMnet2, tu met ta Debian en 192.168.2.1 et ton XP en 192.168.2.x avec 192.168.2.1 comme passerelle.

Ensuite tu actives le partage de connexion sur la Debian (voir lien plus haut).

Pour les DNS, soit tu met 194.2.0.20 partout, soit tu configures aussi ta Debian comme passerelle DNS, et tu met donc 192.168.2.1 comme DNS sur la machine XP (sur Debian, tu laisses le 194.2.0.20).


Au niveau des ping, dans cette configuration, tu pourras faire :
Debian <-> réel
Debian <-> XP
XP -> réel (il passera par Debian)

réel->XP ne fonctionnera pas, mais c'est tout a fait normal.

[carles65]

Avec une carte cela marche.
Maintenant mon probleme est de gerer 3 groupes avec des sites autorises different! Donc comment faire des groupes ACL pour autoriser certain site par groupe?

Je vous fournis en piece jointe le réseau que je devrais faire au final.
Mon but est de lors de l'authentification sur le vpn, le proxy reconnaisse à quel groupe appartient l'user.

Cela marche jai mis squid norman au lieu de squid3.

Explication du projet
La situation est telle:
Chaque agence a un modem (livebox) ou autres et se connecte au web sans restriction.
Ils ont acces à l'intranet par l'adresse srvcompta/..... .
Un poste en agence a un parametrage VPN pour pouvoir acceder au serveur et il y a aussi un compte user sur le serveur compta avec acces à distance.
Le serveur DHCP sur serveurcompta fournit des adresse leur de connexion a distance au VPN.
Le projet demandé est donc de :
-d'installer un proxy squid afin de filtrer les sorties web de chaque agence vers le proxy pour qu'il accorde que les sites définis dans sa base.
-il y a 3 groupes distinct : direction (tous sites), exploitation(limite sites) et compta (limité sites mais different d'exploitation).
-l'authentification devrait se faire par rapport au login du vpn rentré afin d'éviter une nouvelle authentificaiton sur le proxy.
Donc, le proxy sert de sortie au web sans lui pâs d'internet!

pour distinguer un utilisateur de nice d'un utilisateur de marseille, au niveau du proxy, tu ne peux le faire que via login/pass ou via adresse IP

Comment le parametre dans Squid?
Merci pour votre réponses.

[carles65]

Voici le mail de mon tuteur ma fourni apres que je lui est demandé comment il voulait exactement se passe la connexion.

Pour un poste en agence il faut :
· Un paramétrage VPN : (pour permettre l'accès au réseau de Corbas)
adresse 81.80.XXX.XXX
· un compte user sur le serveur SRCOMPTA (192.168.XXX.XXX) avec accès distant autorisé

Il sera surement nécessaire de revoir le plan d'adressage (sur le serveur )de Corbas pour agrandir la plage d'adresses réservées aux postes distants pour que DHCP puisse leur accorder une adresse lors de l'accès VPN.

Ensuite, je suppose que Squid permet de cataloguer des noms d'utilisateurs (pas forcément le noms des stations connectées ?? généralement différents des personnes qui les utilisent) et ainsi connaître le groupe auquel appartient l'utilisateur demandant une page Web. Je ne vois le serveur compta utile que pour l'accès VPN et l'intranet.

Nous pourrons tester si je me connecte à distance (vpn existant) et m'attribuer à chaque fois sur un groupe différent pour savoir si Squid reconnaît bien l'utilisateur distant et le groupe d'appartenance.

[carles65]

J'ai redemandé une explication claire du projet voici la réponse :

Les "Box" présentes en agences ne seront utiles qu'au logiciel d'exploitation transport qui utilise TCP/IP pour accéder à un serveur SQL situé en Belgique, et à Outlook (passerelle) pour émettre les mails.

Les navigateurs des postes agences ne doivent plus accéder au Web par leur "Box" mais obligatoirement par le réseau de Corbas via le VPN et le proxy.

Le rôle de SRVCOMPTA est :
· Permettre l'identification de la station distante (VPN) et donner une adresse IP (dhcp) à la station sur le réseau de Corbas
· mettre à disposition l'intranet IIS (//srvcompte/gwarning). C'est une application pas une interface de connexion.

Le serveur n'a aucun rôle dans les accès au Web des postes locaux ou distants.

le serveur Squid est sur le réseau et tous les navigateurs doivent lui faire appel lors d'une demande de site Web
(logiquement même le navigateur du serveur compta devra passer par Squid pour accéder au Web)
Squi n'est qu'un contrôleur d'accès au Web et SRVCOMPTA n'est qu'un serveur DHCP pour le réseau de Corbas.

Bien se renseigner sur le Web pour :
Gestion proxy sur IE6 et IE7 (options internet onglet Connexion) limitations, permissions,...
Blocage au niveau du registre de l'installation des accessoires Windows (jeux, ...) et le mieux désisntaller ces éléments et bloquer leur réinstallation par script.