Vous n'êtes pas identifié(e).
L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
utilisateurs:hypathie:tutos:proxy-transparent [18/10/2014 05:26] Hypathie [Introduction] |
utilisateurs:hypathie:tutos:proxy-transparent [18/10/2014 08:18] Hypathie [Vérifications] |
||
---|---|---|---|
Ligne 15: | Ligne 15: | ||
Lorsqu'un serveur mandataire est installé, on configure souvent le routage du réseau pour que l'utilisateur final soit orienté vers le serveur mandataire sans avoir à modifier sa configuration. On parle alors de « proxy transparent ». Cette configuration est obtenue par translation d'adresse IP. | Lorsqu'un serveur mandataire est installé, on configure souvent le routage du réseau pour que l'utilisateur final soit orienté vers le serveur mandataire sans avoir à modifier sa configuration. On parle alors de « proxy transparent ». Cette configuration est obtenue par translation d'adresse IP. | ||
- | ===Prérequis=== | + | ====Prérequis==== |
Un serveur DNS est installé sur la passerelle.\\ | Un serveur DNS est installé sur la passerelle.\\ | ||
Ligne 24: | Ligne 24: | ||
''iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE'' | ''iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE'' | ||
- | Le serveur squid est installé : | + | === Configuration d'iptables (NAT) === |
+ | |||
+ | * Pour faire choses proprement on flush les tables concernées et on ajoute : | ||
+ | |||
+ | <code root> | ||
+ | iptables -t nat -F | ||
+ | iptables -t nat -X | ||
+ | iptables -t mangle -F | ||
+ | iptables -t mangle -X | ||
+ | |||
+ | iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.1 -p tcp --dport 80 -j ACCEPT | ||
+ | |||
+ | iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80\ | ||
+ | -j DNAT --to-destination 192.168.0.1:3128 | ||
+ | |||
+ | iptables -t mangle -A PREROUTING -p tcp --dport 3128 -j DROP | ||
+ | |||
+ | iptables -t nat -A PREROUTING -i eth1 -s 192.168.1.0/24\ | ||
+ | -p tcp --dport 80 -j REDIRECT --to-port 3128 | ||
+ | |||
+ | iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80\ | ||
+ | -j REDIRECT --to-ports 3128 | ||
+ | |||
+ | iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE | ||
+ | </code> | ||
+ | |||
+ | |||
+ | * Ce qui donne : | ||
+ | <code root>iptables -L -t nat</code> | ||
+ | |||
+ | <code>Chain PREROUTING (policy ACCEPT) | ||
+ | target prot opt source destination | ||
+ | ACCEPT tcp -- debian-serveur.mondomaine.hyp anywhere tcp dpt:http | ||
+ | DNAT tcp -- anywhere anywhere tcp dpt:http to:192.168.0.1:3128 | ||
+ | REDIRECT tcp -- 192.168.1.0/24 anywhere tcp dpt:http redir ports 3128 | ||
+ | |||
+ | Chain INPUT (policy ACCEPT) | ||
+ | target prot opt source destination | ||
+ | |||
+ | Chain OUTPUT (policy ACCEPT) | ||
+ | target prot opt source destination | ||
+ | |||
+ | Chain POSTROUTING (policy ACCEPT) | ||
+ | target prot opt source destination | ||
+ | MASQUERADE all -- anywhere anywhere</code> | ||
+ | |||
+ | <code root>iptables -L PREROUTING -t mangle</code> | ||
+ | <code>iptables -L -t mangle | ||
+ | Chain PREROUTING (policy ACCEPT) | ||
+ | target prot opt source destination | ||
+ | DROP tcp -- anywhere anywhere tcp dpt:3128</code> | ||
+ | |||
+ | <note> | ||
+ | **Pour mangle**, une petite citation extrait du [[http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat|site officiel de squid]] : | ||
+ | |||
+ | Due to the NAT security vulnerabilities it is also a very good idea | ||
+ | to block external access to the internal receiving port. | ||
+ | This has to be done in the mangle part of iptables before DNAT happens | ||
+ | so that intercepted traffic does not get dropped. | ||
+ | |||
+ | **Par contre, concernant les deux interfaces, il faut lancer les commandes iptables pour le DNAT sur l'interface côté lan, et sur l'IP du serveur proxy du réseau côté web.** | ||
+ | |||
+ | </note> | ||
+ | ===Configurer /etc/sysctl.conf === | ||
+ | La première ligne est probablement déjà configurer tel que ce-dessous. Modifier aussi la seconde | ||
+ | <code> | ||
+ | # Controls IP packet forwarding | ||
+ | net.ipv4.ip_forward = 1 | ||
+ | |||
+ | # Controls source route verification | ||
+ | net.ipv4.conf.default.rp_filter = 0 | ||
+ | </code> | ||
+ | * Faire rendre en compte une éventuelle modification : | ||
+ | <code root>sysctl -p</code> | ||
+ | |||
+ | |||
+ | ===Installer le serveur squid3=== | ||
<code root>apt-get install squid3</code> | <code root>apt-get install squid3</code> | ||
<code root>apt-get build-dep squid3</code> | <code root>apt-get build-dep squid3</code> | ||
Ligne 36: | Ligne 112: | ||
* contrôle d'accès en fonction des heures. | * contrôle d'accès en fonction des heures. | ||
Néanmoins un proxy transparent permettra de ne rien avoir à configurer dans le navigateur du client qui "ignorera" qu'il passe par un proxy quand il navigue. Cela place donc hors sujet la question l'accès par login et mot de passe... | Néanmoins un proxy transparent permettra de ne rien avoir à configurer dans le navigateur du client qui "ignorera" qu'il passe par un proxy quand il navigue. Cela place donc hors sujet la question l'accès par login et mot de passe... | ||
- | |||
- | <note important> | ||
- | Avant toute modification du fichier /etc/squid3/squid.conf\\ | ||
- | il faut arrêter squid : | ||
- | <code root>/etc/init.d/squid3 stop</code> | ||
- | |||
- | Puis quand on a fait les modifications souhaitées, on le redémarre : | ||
- | <code root>/etc/init.d/squid3 start</code> | ||
- | </note> | ||
===Faire une sauvegarde du fichier de configuration === | ===Faire une sauvegarde du fichier de configuration === | ||
Ligne 270: | Ligne 337: | ||
<note> | <note> | ||
- | Si pour une raison ou pour une autre, il y a besoin de ré-initialiser le cache, par exemple si la taille de mémoire cache ne convient pas, ne pas hésiter à supprimer ces fichiers manuellement :\\ | + | Si pour une raison ou pour une autre, il y a besoin de ré-initialiser le cache, par exemple si la taille de mémoire cache ne convient pas, ne pas hésiter à supprimer ces fichiers manuellement, ou tout simplement si on veut le vider complètement :\\ |
+ | * Il faut arrêter squid : | ||
+ | <code root>/etc/init.d/squid3 stop</code> | ||
+ | |||
+ | * On se déplace dans le répertoire du cache : | ||
(S'il vous plaît servez-vous de l'auto-complétion, surtout ici) | (S'il vous plaît servez-vous de l'auto-complétion, surtout ici) | ||
<code root>cd /var/spool/squid3/</code> | <code root>cd /var/spool/squid3/</code> | ||
+ | |||
+ | * On supprime tous les dossiers | ||
<code root>rm -rv 0*</code> | <code root>rm -rv 0*</code> | ||
- | <code root>rm -rv swap.state*</code> | ||
- | </note> | ||
+ | * On supprime les fichiers | ||
+ | <code root>rm -v swap.state*</code> | ||
+ | * On relance squid3 : | ||
+ | <code root>/etc/init.d/squid3 start</code> | ||
+ | </note> | ||
- | ===== configuration d'iptables (NAT) ===== | ||
- | Nous n'avons pour l'instant que l'IP masquerade mis en place : | ||
- | * Il faut ajouter : | ||
- | <code root> | ||
- | iptables -t nat -A PREROUTING -s 192.168.0.1 -p tcp --dport 80 -j ACCEPT | ||
- | iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT\ | ||
- | --to-destination 192.168.0.1:3128 | ||
- | iptables -t mangle -A PREROUTING -p tcp --dport 3128 -j DROP | ||
- | iptables -t nat -A PREROUTING -i eth1 -s 192.168.1.0/24\ | ||
- | -p tcp --dport 80 -j REDIRECT --to-port 3128 | ||
- | iptables -t nat -I PREROUTING 1 -i eth1 -s 192.168.1.0/24\ | ||
- | -p tcp -m tcp --dport 80 -J ACCEPT | ||
- | </code> | ||
- | * Ce qui donne : | ||
- | <code root>iptables -L -t nat</code> | ||
- | |||
- | <code>Chain PREROUTING (policy ACCEPT) | ||
- | target prot opt source destination | ||
- | ACCEPT tcp -- debian-serveur.mondomaine.hyp anywhere tcp dpt:http | ||
- | DNAT tcp -- anywhere anywhere tcp dpt:http to:192.168.0.1:3128 | ||
- | REDIRECT tcp -- 192.168.1.0/24 anywhere tcp dpt:http redir ports 3128 | ||
- | |||
- | Chain INPUT (policy ACCEPT) | ||
- | target prot opt source destination | ||
- | |||
- | Chain OUTPUT (policy ACCEPT) | ||
- | target prot opt source destination | ||
- | |||
- | Chain POSTROUTING (policy ACCEPT) | ||
- | target prot opt source destination | ||
- | MASQUERADE all -- anywhere anywhere</code> | ||
- | |||
- | <code root>iptables -L PREROUTING -t mangle</code> | ||
- | <code>iptables -L -t mangle | ||
- | Chain PREROUTING (policy ACCEPT) | ||
- | target prot opt source destination | ||
- | DROP tcp -- anywhere anywhere tcp dpt:3128</code> | ||
- | |||
- | <note> | ||
- | **Pour mangle**, une petite citation extrait du [[http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat|site officiel de squid]] : | ||
- | |||
- | Due to the NAT security vulnerabilities it is also a very good idea | ||
- | to block external access to the internal receiving port. | ||
- | This has to be done in the mangle part of iptables before DNAT happens | ||
- | so that intercepted traffic does not get dropped. | ||
- | |||
- | **Par contre, concernant les deux interfaces, il faut lancer les commandes iptables pour le DNAT sur l'interface côté lan, et sur l'IP du serveur proxy du réseau côté web.** | ||
- | |||
- | </note> | ||
- | ===Configurer /etc/sysctl.conf === | ||
- | * Pour masquerade, vérifier que les lignes suivantes comportes ces valeurs : | ||
- | |||
- | <code> | ||
- | # Controls IP packet forwarding | ||
- | net.ipv4.ip_forward = 1 | ||
- | |||
- | # Controls source route verification | ||
- | net.ipv4.conf.default.rp_filter = 0 | ||
- | </code> | ||
- | * Faire rendre en compte une éventuelle modification : | ||
- | <code root>sysctl -p</code> | ||
=====Vérifications==== | =====Vérifications==== | ||
Ligne 371: | Ligne 386: | ||
</code> | </code> | ||
- | <note tip> | + | ====Vérifier la cache ==== |
- | **__Détail sur /var/log/squid3/access.log__ :**\\ | + | Ci-dessus, nous avons observé que les connexions passaient par le proxy.\\ |
- | On y retrouve tous les accès faits au serveur, c’est-à-dire toutes les requêtes HTTP reçues et la façon dont elles ont été traitées. Le format de ce fichier est paramétrable via l’option access_log du fichier squid.conf. Le format natif d’une entrée de log est le suivant :\\ **''time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type''**\\ | + | Pour vérifier que squid sert au client une page de son cache, il faut visiter le même URL plusieurs fois. |
+ | La 1ère fois on a normalement dans /var/log/squid3/access.log, ''TCP_MISS'', mais après on doit obtenir ''TCP_HIT''. | ||
+ | * TCP_MISS : L'objet demandé n'est pas dans le cache. | ||
+ | * TCP_HIT : Une copie valide de l'objet demandé était dans le cache. | ||
- | > **''time''** : le temps UTC (en ms) auquel la requête a été reçue. | + | On peut trouver d'autres indications : |
+ | * TCP_REFRESH_HIT : L'objet demandé a été mis en cache mais obsolète (ICM -> 304). | ||
+ | * TCP_REF_FAIL_HIT : L'objet demandé a été mis en cache mais il obsolète ; la requête IMS a échoué mais l'objet a été livré. | ||
+ | * TCP_REFRESH_MISS : L'objet demandé a été mis en cache mais était obsolète. La requête IMS retourné le nouveau contenu. | ||
+ | * TCP_CLIENT_REFRESH_MISS : Le client a émis une certaine demande de cache en même temps que la demande. Ainsi, le cache doit extraire à nouveau l'objet. | ||
+ | * TCP_IMS_HIT : Le client a émis une demande IMS pour un objet qui est nouvellement dans le cache. | ||
+ | * TCP_NEGATIVE_HIT :Demande d'un objet mis en cache négative, par exemple "404 Not Found" | ||
+ | * TCP_MEM_HIT : Une copie valide de l'objet demandé a été mis dans la mémoire du cache, évitant ainsi les accès disque. | ||
+ | * TCP_DENIED : Accès a été refusé pour cette demande. | ||
+ | * TCP_OFFLINE_HIT : L'objet demandé a été récupéré à partir du cache en mode déconnecté. Voir "offline_mode" dans le fichier squid.conf. | ||
- | >**''elapsed''** : le temps de traitement par le serveur de la requête (en ms). Ce temps de traitement diffère selon le mode utilisé (connecté ou déconnecté) : | + | Se connecter plusieurs fois et tenter la commande : |
- | * Pour TCP, il s’agit du temps écoulé entre le moment où le serveur a reçu la requête et le moment où il a répondu au client. | + | <code root>cat /var/log/squid3/cache.log | grep TCP_HIT</code> |
- | * Pour UDP, il s’agit du temps calculé entre le moment où le serveur prévoit de répondre au client et le moment où il lui répond effectivement. | + | |
- | >**''remotehost''** : l’adresse IP du client. Cette donnée peut être cachée pour rendre les logs anonymes. | ||
- | |||
- | >**''code/status''** : le code résultat de la transaction. Ce champ est composé de deux entrées séparées par un slash : le code de statut de Squid et le code HTTP de la réponse du serveur d’origine. La plupart de ces codes sont détaillés plus bas. | ||
- | |||
- | >**''bytes''** : la taille de la donnée livrée au client. | ||
- | |||
- | >**''method''** : la méthode utilisée pour récupérer la ressource (GET, HEAD, etc.). | ||
- | |||
- | >**''URL''** : l’URL de la ressource demandée. | ||
- | |||
- | >**''rfc931''** : les informations utilisateurs (désactivé par défaut). | ||
- | |||
- | >**''hierarchy code''** : un code permettant de savoir comment la requête a été traitée. Ce code peut être suivi par l’adresse IP vers laquelle la requête a été redirigée. | ||
- | |||
- | >**''type''** : le type de contenu issu du header HTTP de la réponse (Les échanges ICP ne contiennent pas cette information). | ||
- | </note> | ||
====Vérifier le cache==== | ====Vérifier le cache==== | ||
Ligne 421: | Ligne 431: | ||
+ | <note tip> | ||
+ | **__Détail sur /var/log/squid3/access.log__ :**\\ | ||
+ | On y retrouve tous les accès faits au serveur, c’est-à-dire toutes les requêtes HTTP reçues et la façon dont elles ont été traitées. Le format de ce fichier est paramétrable via l’option access_log du fichier squid.conf. Le format natif d’une entrée de log est le suivant :\\ **''time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type''**\\ | ||
+ | |||
+ | > **''time''** : le temps UTC (en ms) auquel la requête a été reçue. | ||
+ | |||
+ | >**''elapsed''** : le temps de traitement par le serveur de la requête (en ms). Ce temps de traitement diffère selon le mode utilisé (connecté ou déconnecté) : | ||
+ | |||
+ | * Pour TCP, il s’agit du temps écoulé entre le moment où le serveur a reçu la requête et le moment où il a répondu au client. | ||
+ | * Pour UDP, il s’agit du temps calculé entre le moment où le serveur prévoit de répondre au client et le moment où il lui répond effectivement. | ||
+ | |||
+ | >**''remotehost''** : l’adresse IP du client. Cette donnée peut être cachée pour rendre les logs anonymes. | ||
+ | |||
+ | >**''code/status''** : le code résultat de la transaction. Ce champ est composé de deux entrées séparées par un slash : le code de statut de Squid et le code HTTP de la réponse du serveur d’origine. La plupart de ces codes sont détaillés plus bas. | ||
+ | |||
+ | >**''bytes''** : la taille de la donnée livrée au client. | ||
+ | |||
+ | >**''method''** : la méthode utilisée pour récupérer la ressource (GET, HEAD, etc.). | ||
+ | |||
+ | >**''URL''** : l’URL de la ressource demandée. | ||
+ | |||
+ | >**''rfc931''** : les informations utilisateurs (désactivé par défaut). | ||
+ | |||
+ | >**''hierarchy code''** : un code permettant de savoir comment la requête a été traitée. Ce code peut être suivi par l’adresse IP vers laquelle la requête a été redirigée. | ||
+ | |||
+ | >**''type''** : le type de contenu issu du header HTTP de la réponse (Les échanges ICP ne contiennent pas cette information). | ||
+ | </note> | ||