Forcer connections sur freebox à passer par squid

Support Debian
#1

Bonjour,

cela fait plusieurs jours que j’essaye de comprendre comment forcer les ordinateurs qui accèdent à internet via ma freebox à passer par mon proxy.

Ma config est celle-ci: une freebox v6, sur laquelle j’ai branché un raspberry/serveur web. J’ai installé squid sur le raspberry.

Lorsque je configure Firefox pour que le navigateur utilise le proxy (http://IP_du_RPI:3128), ça marche.

Ce que j’aimerais, c’est que même sans configurer le proxy sur les navigateurs, automatiquement les navigateurs se connectent au proxy.

J’ai cru lire sur internet que c’était pourtant possible. Mais j’ai aussi lu le contraire! Bref, je suis perdu!

Merci de votre aide!

Edit 1: j’ai mis ça ds le fichier de conf de squid:
http_port 3128
http_port 3129 intercept
mais toujours la même chose: si je confire firefox pr utiliser le proxy, c’est bon, sinon, il n’y a rien que se passe…

J’en reviens donc à la même question: est-ce que le problème ne viendrait pas d’iptables? ou de redirection du port 80 sur la Freebox?
J’y connais pas grand chose, mais j’imagine qu’il faut dire à la freebox d’envoyer le trafic sur le rpi, squid l’analyse puis renvoie les données à l’ordi qui a fait la demande, non? En tout cas si c’est bien ça l’idée, je ne capte pas comment le mettre en application!

#2

Je n’ai jamais fait, mais je suppose comme toi que c’est au niveau du routeur qu’il faut rediriger tout le trafic sortant sur ton proxy. Avec ma vieille v4 ça n’est pas possible. À voir si avec la Révolution ça l’est.

#3

Evidemment. Le proxy ne peut rien faire s’il ne reçoit pas les connexions. Mais pas dans le sens ou @meaz l’entend car je doute qu’aucune box soit assez configurable pour faire ce qu’il décrit.

Il faut soit modifier l’adresse de routeur (improprement appelé “passerelle” ) de la route par défaut des postes clients (via la configuration du serveur DHCP ou manuellement sur les postes), soit intercaler le proxy entre la box et les clients (mais c’est mort pour utiliser le wifi de la box).

#4

Merci pour vos réponses.

Je ne suis pas caler infrastructures, donc je pensais que quand je configurais la redirection du port 80 de la freebox vers le serveur raspberry, tout le trafic http entrant et sortant de tout appareil connecté sur la freebox passait par le rasperry. Si je comprends ce que tu dis PascalHambourg, ce n’est pas le cas…

Je ne suis pas sur de comprendre. Sur la Freebox révolution, je peux mettre l’adresse ip de mon choix au matériel connecté sur la Freebox, du genre l’ordi A a 192.168.1.15
Qu’appelles-tu l’adresse du routeur de la route par défaut des postes clients?

Merci!

#5

Non, heureusement. Les redirections configurées sur une box ne concernent que les connexions provenant de l’extérieur et, pour certaines box, les connexions provenant du LAN à destination de l’adresse IP de la box.

Sinon imagine un peu la situation : un utilisateur qui héberge un serveur web et fait une redirection du port 80 vers celui-ci pour qu’il soit accessible de l’extérieur verrait toutes ses propres connexions HTTP sortantes redirigées et ne pourrait accéder qu’à son propre serveur web. Ce n’est probablement pas ce qu’il voulait.

L’adresse affichée en “route par défaut” dans les informations de connexion de NetworkManager, ou l’adresse affichée en tant que routeur dans la route par défaut affichée par ip route ou route -n :

$ ip route
default via 192.168.0.1 dev eth0  proto static 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.240

L’adresse de routeur par défaut est ici 192.168.0.1.
Normalement, c’est l’adresse de la box. Dans ton cas, il faudrait que ce soit l’adresse de la machine qui fait tourner le proxy. Ce n’est évidemment pas suffisant, il faut aussi configuer cette machine en routeur pour router les connexions non HTTP vers la box.

#6

Ok merci, donc si j’ai compris, il faut que mon raspberry sur lequel est mon proxy devienne aussi mon routeur à la place de ma freebox, c’est bien ça?

#7

Oui si tu choisis cette voie. Mais ma première réponse comportait une alternative. Dans le second membre de celle-ci, il y a deux façons d’intercaler le proxy entre le LAN et la box : en routeur ou en pont. En pont, pas besoin de modifier le routage.

#8

Pour cette deuxième solution, je ne maitrise pas du tout: c’est quoi un pont?

#9

C’est comme un switch ethernet, transparent du point de vue de la couche IP.

#10

Ok merci

#11

En complément de la réponse de Pascal Hambourg, je souhaite préciser l point suivant:

Le DHCP “pousse” bien plus qu’une @IP et ce, même avec une réservation sur adresse mac.
Il indique aussi aux clients la passerelle (gateway) pour sortir, les DNS , le masque réseau et, évidemment l’adresse IP.

Sur la Freebox, on ne peut agir que sur la plage d’adresse , sur la réservation et sur la redirection de port.
La solution “élégante” serait:

-) Mettre la freebox en bridge (NAT non activé) mais il faut être conscient que tu exposes ta machine directement sur Internet .
-) Mettre le Raspberry en “routeur” et lui faire assurer les fonctions de la freebox:
- NAT
-PAT
- Acces Point WIFI (hostpad)
- serveur DHCP
- proxy (squid)
Pour cela, il est préférable d’utiliser une distribution dédiée plutôt qu’une généraliste qui va installer, par défaut, des dizaines de paquets absolument inutiles pour cet usage (Openoffice, Gimp, jeux…).
Je pense en particulier à IPcop ou à OpenWRT qui est portée sur Raspberry:
https://wiki.openwrt.org/toh/raspberry_pi_foundation/raspberry_pi

Ceci étant précisé, à titre personnel je ne recommande pas le Raspberry pour cet usage.
Ses performances réseau sont bien trop limitées. En théorie, 100 Mbs mais ces 100 Mbs sont partagés entre tous les périphériques USB et le port Ethernet.
Si c’est pour faire uniquement un routeur fil vers WLAN, il faudra certainement mettre une clef WIFI avec antenne sur un port USB (la portée du WIFI natif, avec sa petite antenne céramique de 0.5 cms sur la carte mère est ridicule.
Si c’est pour faire un routeur fil vers fil, il faut une deuxième carte Ethernet qui sera aussi connectées sur l’USB.
Si c’est pour faire un routeur fil vers (fil+WLAN), il faut mettre les 2 cartes sur l’USB.
Il faut aussi se méfier des écritures répétées sur la carte SD. Je ne pratique pas SQUID mais je suppose que, comme beaucoup de serveur, il doit être très bavard.
Le Raspberry a une réputation méritée de tueur de carte SD .
En tout cas, c’est un beau challenge. Bon courage.

Sylvain

#12

Je ne vois pas l’intérêt de désactiver le NAT de la box puisque le RPi va faire du NAT donc de toute façon le mal est fait (oui, le NAT c’est le mal, même si c’est un mal parfois nécessaire). L’argument disant que le double NAT en cascade est néfaste est sans fondement.

L’installateur Debian n’installe rien de tout cela si on ne sélectionne pas l’environnement de bureau ni les “utilitaires usuels du système”.

Pas forcément. Avec un switch qui supporte les VLAN taggés, on peut faire passer 2 VLAN sur une seule interface réseau.

Ce n’est pas le RPI qui est un tueur de carte SD, c’est l’utilisation qu’on en fait. Une carte SD ou une clé USB ne sont pas un disque dur ni un SSD et n’ont pas la même endurance aux écritures répétées.

1 J'aime
#13

[quote=“spourre, post:11, topic:71645”]
En théorie, 100 Mbs mais ces 100 Mbs sont partagés entre tous les périphériques USB et le port Ethernet.
[/quote]D’autant que je crois bien que le module physique ethernet passe par l’USB sur ces machines, avec la cascade de protocoles USB qui va avec…

c’est vrai que le RPI est un tueur de carte SD pour les mêmes personnes qui nomment dd : Disk Destroyer

#14

Quand je réponds sur un forum, J’ai la regrettable habitude, je le confesse, d’essayer de répondre à la question posée par le PO en m’adaptant, si possibl, à son niveau.
Que nous dit meaz:
- qu’il utilise un Raspberry (lequel ?)
- “qu’il n"y connaît pas grand chose”

Le double NAT n’est pas une mauvaise chose et peut même être utile. C’est une façon élégante de faire une DMZ et d’isoler les serveurs exposés à Internet du LAN. Cela ne fait que de dégrader le “ping” et compliquer la configuration.

Ayant installé Debian Jessie sur ma tour (64 bits) , sur mon portable (32 bits) et sur 2 raspberries B+, je crois pouvoir en parler. L’installation de l’image officielle, mise en ligne par la fondation, est la jessie avec Pixel:


C’est un fichier img qui est ensuite copié sur une carte SD; il n’y a pas d’installateur. Le choix des programmes, ajout ou suppression, se fait après boot. Le SOC Broadcom n’est pas entièrement libre et un gros blob est nécessaire.
Proposer à un débutant une solution à base de VLAN tagués, et donc préconiser l’achat d’un “switch” de niveau 3 (le routage n’est plus du niveau 2), c’est tout simplement du foutage de gueule.

Le Raspberry a, chez ses utilisateurs, une réputation non usurpée de tueur de carte SD. C’est dû aux choix techniques et au compromis de la fondation. Il ne sait booter que sur sa carte SD sauf le P 3 qui peut démarrer sur disque (voire sur LAN), mais ça n’est pas trivial. De plus, mettre un disque dur, en l’absence de port SATA (contrairement au banana pi), réduit le débit disponible. Comme le signale justement MiCP, tout passe par le contrôleur USBB du SOC Broadcom.

Sylvain

#15

Merci pour tous ces éclaircissements! Cela me permet de me rendre compte que je ne suis pas, mais alors pas du tout, au point sur ces sujets! Il va falloir que je creuse! Mais c’est, je trouve, l’avantage du rpi: tester des trucs, apprendre en faisant.

J’ai trouvé une parade qui n’est pas la meilleure, qui n’est pas entièrement satisfaisante mais qui est assez simple. On peut configurer un contrôle parental sur la freebox. Donc je bloque les accès internet sur un matériel reconnu/une ip et du coup ledit matériel doit passer par le proxy pour se connecter.
Le hic, c’est qu’un nouveau matériel qui se connecte peut aller sur internet sans restriction, il faut la mettre manuellement.
Le 2ème hic c’est que le proxy doit être régler à la main sur l’appareil…

Sur cette histoire de carte SD, je croyais que c’était une rumeur… Visiblement non. Y a des solutions pour l’économiser?

Dernière question tant que j’y suis sur squid: j’ai vu qu’on pouvait bloquer des sites. Peut-on bloquer des mots?

En tout cas encore merci pour votre temps!

#16

Pour ma part j’ai le fâcheux travers, je l’avoue, de penser que mes réponses peuvent servir à d’autres lecteurs et de m’efforcer d’être aussi techniquement précis et exhaustif qu’il est raisonnablement possible de l’être.

La dégradation de la latence causée par le NAT de la box est marginale, et si ce n’est pas le cas, c’est que la box est à genoux et que la situation existait déjà avant la mise en place du double NAT.
En quoi cela conplique-il la configuration ?
Au contraire avec certaines box, désactiver le NAT implique de passer la box en pont ethernet et de configurer une connexion PPPoE sur la machine qui va servir de routeur à la place de la configuration statique ou par DHCP.
Si on doit gérer des connexions entrantes, on configure l’adresse du routeur en DMZ dans la box et tout se fait ensuite sur le routeur.

Nul besoin d’un switch de niveau 3 qui fasse du routage : la gestion de VLAN est purement une fonction de commutation (niveau 2).
D’autre part je n’ai rien proposé ni encore moins préconisé. Je me suis borné à énoncer une possibilité pour économiser une interface réseau sur le routeur au cas où on dispose d’un switch qui gère les VLAN.

Booter sur la carte SD n’implique pas de l’user en écrivant dedans.

Ne pas avoir utilisé le RPi ne m’empêche pas de soutenir que si on ne l’utilisait pas avec un système et des applications qui passent leur temps à écrire sur la carte SD comme si c’était un disque dur alors qu’elle n’est pas conçue pour ça, la longévité de celle-ci serait grandement augmentée.

#17

Vouloir être exhaustif part d’un bon sentiment mais on risque de noyer le PO qui n’aura pas une réponse adaptée à son niveau et de faire dévier le fil vers une discussion entre spécialistes. Il me semble même que c’est exactement ce qui est en train de se passer, bien que je ne me considère pas comme un spécialiste du réseau.

Le double NAT impose une double configuration:
-) Sur la box: DHCP avec réservation d’@IP sur la @mac du proxy et avec cette seule adresse.
-) Sur le proxy avec serveur DHCP distribuant les @IP et la passerelle pour les clients du LAN (ou adressage fixe sur ceux-ci).
Je ne vois pas pourquoi tu veux activer PPoE (ou PPoA) sur le proxy. Les box que j’ai utilisées maintenaient toutes la connexion, même en bridge.

Je sais bien que TCP/IP n’est pas " full compliant" avec le modèle OSI mais j’ai la faiblesse de croire que le routage, y compris de VLAN, relève du Layer 3.
D’autres, bien plus qualifiés que moi, ont aussi cette faiblesse:
http://www.supinfo.com/articles/single/733-configuration-routage-inter-vlan-layer-3-switch-cisco
Même en admettant que c’est un switch de niveau 2, pour gérer les VLAN, il doit être administrable et sa configuration, même avec une GUI HTTP, demandera des pré-requis sérieux dans le domaine réseau.

Certes on peut booter sur un système read-only mais cela posera, tôt ou tard, des problèmes lors des mises à jour.
La fondation vante le Raspberry comme étant un ordinateur puissant, à faible coût (" We provide low-cost, high-performance computers" ):


Cette glose est reprise par tous les sites français “Un ordinateur à 35€ …”:

Les utilisateurs veulent faire des serveurs LAMP et comme souvent ils viennent du monde WINTEL, ils ne connaissent pas Linux, n’ont aucune idée du fonctionnement, ne savent pas réduire et/ou déplacer les journaux et quand ça ne fonctionne pas, et bien on réinstalle. Peut-on les blamer pour autant ? je ne le pense pas.

Sylvain

#18

As-tu essayé, au moins sur une machine, de la mettre en IP fixe et de donner l’adresse du Raspberry SQUID comme passerelle ?
Autre possibilité, les navigateurs permettent souvent de définir un proxy .

Je t’invite à venir sur un des rares forums en français consacré au Raspberry:


Il est très convivial et il y a, sur la partie Blog, des articles consacrés au boot sur disque dur (pour le Pi 3).

Pour SQUID, désolé mais je ne l’utilise pas.
Comme il me plaît de le signaler, nous avons tous été un débutant un jour et bien content d’avoir trouvé de l’aide.

Sylvain

#19

Bonjour @spourre ,

Oui j’arrive très bien à faire fonctionner le proxy en configurant chaque ordi manuellement via le navigateur. L’idée, c’était que si quelqu’un venait chez moi et avait besoin d’aller sur le net, il n’avait pas de config à faire et qu’automatiquement il passait par le proxy.
J’ai compris qu’il fallait en fait plutôt utiliser un routeur que je configurerais moi même plutôt que ma freebox comme routeur. Comme c’est pas le but, je laisse tomber. A la place, j’ai mis que dns opendns, comme ça j’ai un filtrage pour tout le monde. C’est pas parfait, mais c’est déjà ça!

Pour le site de framboise314, je le connais mais le forum est moins réactif (car moins nombreux) que debian, donc j’ai privilégié Debian.

Merci bcp à nouveau

#20

Non. Pas besoin de DHCP, on peut configurer l’interface du routeur/proxy reliée à la box en statique.

Il faut le faire de toute façon, que la box fasse du NAT ou pas.

C’est le cas des freebox ADSL qui ne sont pas de vrais ponts ethernet mais quelque chose d’hybride entre un pont et un routeur, mais ce n’est pas le cas de toutes les autres box. Certaines comme la neufbox4 que j’ai eue entre les mains fonctionnent comme un vrai pont transparent lorsqu’on désactive le mode routeur NAT, et compte tenu des choix techniques de collecte des FAI ADSL autres que Free d’utiliser des encapsulations basées sur PPP, dans ce cas il faut utiliser PPPoE.

Peu importe que TCP/IP ne suive pas le modèle OSI. Le VLAN se situe en-dessous de la couche réseau et n’a rien à voir avec TCP/IP.
Je n’ai jamais parlé de faire du routage des VLAN ou de quoi que ce soit d’autre avec le switch, ce n’est pas nécessaire alors pourquoi amener ce sujet sur le tapis ? Le routeur/proxy est parfaitement capable de faire le routage inter-VLAN lui-même.

C’est pénible cette manie de déformer ou mal interpréter mes propos. Je n’ai pas parlé de système read-only mais de périphérique de boot read-only en réponse à ton argument que le RPI ne pouvait booter que sur la carte SD. Le système entier n’a pas à être sur la carte SD, seulement la partie nécessaire au boot. Il y très peu d’écritures dans cette partie, essentiellement lors des mises à jour du noyau, mais ce n’est pas fréquent.

Quand ils affirment que le RPI tue les cartes SD alors que c’est leur utilisation qui les tue, oui. Ils auraient le même problème avec un système stocké sur carte SD tournant sur PC.