Diferencia entre revisiones de «Squid autentificándose contra squid»
De Guifi.net - Wiki Hispano
m (Tonic movió la página Tinyproxy autentificándose contra squid a Squid autentificándose contra squid: cambio de acercamiento para conseguir el objetivo: aplicaciones que no soportan proxy, reducir tiempos de configuración, etc) |
m (→Sobre tinyproxy y AddHeader) |
||
| (No se muestran 9 ediciones intermedias realizadas por un usuario) | |||
| Línea 1: | Línea 1: | ||
| − | = | + | =¿Por qué?= |
| − | + | ||
| − | + | Si alguna vez te has visto en casa con que quieres conectar varios dispositivos a tu nodo de guifi.net, habrás pensado en un switch o un router. | |
| − | + | Sin embargo, siempre queda el «pequeño» detalle del proxy: | |
| + | * configurarlo | ||
| + | * autentificación cada X tiempo (generalmente cada hora) | ||
| − | = | + | =Cómo= |
| − | + | Un proxy local que se identifica contra un proxy remoto. | |
| + | El proxy local será el que instalemos en nuestro router (OpenWRT) y el proxy remoto será nuestro proxy más cercano de guifi.net. | ||
| − | + | =Más detalles= | |
| − | + | ==squid.conf== | |
| − | + | El fichero squid.conf de nuestro squid local debe contener: | |
| − | + | http_port <en qué puerto queremos que escuche nuestro squid local> | |
| + | cache_peer <ip del proxy de guifi> parent <puerto del proxy de guifi (generalmente 3128)> 0 no-query default proxy-only login=<usuario>:<contraseña> | ||
| + | |||
| + | acl manager proto cache_object | ||
| + | acl localhost src 127.0.0.1/255.255.255.255 | ||
| + | acl all src 0.0.0.0/0.0.0.0 | ||
| + | http_access allow all | ||
| + | never_direct allow all | ||
| + | icp_access deny all | ||
| + | |||
| + | cache_effective_user squid | ||
| + | cache_effective_group wheel | ||
| − | + | '''Atención''': Hay que sustituir el texto encerrado entre <> (y eliminar <>). | |
| − | + | ||
| − | + | Nota: Es posible que en OpenWRT el usuario y el grupo (últimas dos líneas) sean diferentes de los que se especifican aquí. | |
| − | + | Queda por explicar todo el proceso pero la idea y los detalles específicos están en la primera referencia. | |
| − | ( | + | =Sobre tinyproxy y AddHeader= |
| + | |||
| + | Mejor no utilizarlo ya que implica que enviaremos las cabeceras (con los datos de usuario y contraseña) con cada petición del proxy, lo que constituye un riesgo de seguridad, ya que la página que carguemos los recibirá. Por otro lado, es un método un tanto chapucero. | ||
| + | |||
| + | =Referencias= | ||
| + | * [http://hints.macworld.com/article.php?story=20030226161459306 Use squid to perform upstream web proxy authentication] | ||
| + | * [http://www.squid-cache.org/Doc/config/cache_peer/ squid : cache_peer configuration directive] | ||
Última revisión de 16:45 27 jul 2015
Contenido
¿Por qué?
Si alguna vez te has visto en casa con que quieres conectar varios dispositivos a tu nodo de guifi.net, habrás pensado en un switch o un router. Sin embargo, siempre queda el «pequeño» detalle del proxy:
- configurarlo
- autentificación cada X tiempo (generalmente cada hora)
Cómo
Un proxy local que se identifica contra un proxy remoto. El proxy local será el que instalemos en nuestro router (OpenWRT) y el proxy remoto será nuestro proxy más cercano de guifi.net.
Más detalles
squid.conf
El fichero squid.conf de nuestro squid local debe contener:
http_port <en qué puerto queremos que escuche nuestro squid local> cache_peer <ip del proxy de guifi> parent <puerto del proxy de guifi (generalmente 3128)> 0 no-query default proxy-only login=<usuario>:<contraseña> acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl all src 0.0.0.0/0.0.0.0 http_access allow all never_direct allow all icp_access deny all cache_effective_user squid cache_effective_group wheel
Atención: Hay que sustituir el texto encerrado entre <> (y eliminar <>).
Nota: Es posible que en OpenWRT el usuario y el grupo (últimas dos líneas) sean diferentes de los que se especifican aquí.
Queda por explicar todo el proceso pero la idea y los detalles específicos están en la primera referencia.
Sobre tinyproxy y AddHeader
Mejor no utilizarlo ya que implica que enviaremos las cabeceras (con los datos de usuario y contraseña) con cada petición del proxy, lo que constituye un riesgo de seguridad, ya que la página que carguemos los recibirá. Por otro lado, es un método un tanto chapucero.
