Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org
Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.
Este manual cubre los conceptos básicos y la configuración inicial del Servidor Intermediario (proxy) Squid, herramienta fundamental para el control de acceso, filtrado y optimización del tráfico de red en entornos corporativos y educativos.
El término en inglés «Proxy» tiene un significado muy general y al mismo tiempo ambiguo, aunque invariablemente se considera un sinónimo del concepto de «Intermediario». Se suele traducir, en el sentido estricto, como delegado o apoderado ―el que tiene poder sobre otro―.
Un Servidor Intermediario se define como una computadora o dispositivo que ofrece un servicio de red que consiste en permitir a los clientes realizar conexiones de red indirectas hacia otros servicios de red. Durante el proceso ocurre lo siguiente:
Los Servidores Intermediarios generalmente se hacen trabajar simultáneamente como muro cortafuegos operando en el Nivel de Red, actuando como filtro de paquetes, como en el caso de nftables o bien operando en el Nivel de Aplicación, controlando diversos servicios, como es el caso de TCP Wrapper. Dependiendo del contexto, el muro cortafuegos también se conoce como BPD o Border Protection Device o simplemente filtro de paquetes.
Una aplicación común de los Servidores Intermediarios es funcionar como caché de contenido de Red ―principalmente HTTP―, proporcionando en la proximidad de los clientes un caché de páginas y archivos disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable.
Cuando se recibe una petición para un recurso de Red especificado en un URL ―Uniform Resource Locator― el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado estuviera ausente en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes ―hits― ―ejemplos: LRU, LFUDA y GDSF―.
Los Servidores Intermediarios para contenido de Red ―Web Proxies― también pueden actuar como filtros del contenido servido, aplicando políticas de censura de acuerdo a criterios arbitrarios.
Squid es un Servidor Intermediario de alto desempeño que se ha venido desarrollando desde hace varios años y es hoy en día una muy popular solución que es ampliamente utilizada entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU ―GNU/GPL―. Siendo equipamiento lógico libre, está disponible el código fuente para quien así lo requiera.
Entre otras cosas, Squid puede funcionar como Servidor Intermediario y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.
Squid consiste de un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y herramientas para clientes. Al iniciar Squid da origen a un número configurable ―5, de modo predeterminado a través de la opción dns_children― de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS.
🔧 Nota: Squid carece de soporte para ser utilizado como Servidor Intermediario para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT ―Network Address Translation― o bien hacer uso de un servidor SOCKS como Dante → https://www.inet.no/dante.
URL: https://www.squid-cache.org
Para poder llevar al cabo los procedimientos descritos en este y otros documentos relacionados, se requiere instalar al menos lo siguiente:
squid disponible en los almacenes de software de la distribución. Las versiones modernas de RHEL 8, AlmaLinux, Rocky Linux y derivadas incluyen Squid 4.x o superior.Squid sólo se instala de manera predeterminada cuando se instala el grupo de paquetes denominado «Servidor Web». El procedimiento de instalación es exactamente el mismo que con cualquier otro equipamiento lógico.
Si se utiliza ALDOS, que emplea SysVinit y el gestor de paquetes yum, ejecute:
yum -y install squid
Si se utiliza una distribución basada en SystemD y dnf, como AlmaLinux, Rocky Linux o Red Hat Enterprise Linux 8 o superior, ejecute:
dnf -y install squid
Al editar el archivo de configuración squid.conf es fundamental evitar espacios al inicio de una línea ajenos a la parte de una continuidad lógica del parámetro anterior. Squid interpreta un espacio o tabulación inicial como una continuación de la línea previa, lo que genera un error de sintaxis y evita que el servicio se inicie.
El siguiente ejemplo muestra la manera incorrecta de habilitar una opción, donde los espacios iniciales romperán la configuración:
Mal
# Opción **incorrectamente** habilitada.
http_port 8080
El siguiente ejemplo muestra la manera correcta, donde la opción comienza en el primer carácter de la línea:
Bien
# Opción **correctamente** habilitada.
http_port 8080
Squid utiliza el archivo de configuración localizado en /etc/squid/squid.conf y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de opciones, de los cuales recomendamos configurar los siguientes:
http_portcache_direrror_directory, sólo si va a personalizar mensajes de error.El resto de los opciones mencionados en este documento son —valga la redundancia— opcionales.
Edite el archivo /etc/squid/squid.conf:
vim /etc/squid/squid.conf
Para poder controlar el tráfico de los clientes hacia Internet, es necesario establecer Listas de Control de Acceso que definan una red o bien ciertos anfitriones en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid.
De modo predeterminado, Squid habilita el acceso a todas las redes locales, definidas en el RFC1918. Es decir, permite el acceso a 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7 y fe80::/10.
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
Para poner un mínimo de seguridad, todo lo anterior debe ser deshabilitado colocando una almohadilla (#) al inicio de cada línea.
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
# acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
# acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
# acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
# acl localnet src fc00::/7 # RFC 4193 local private network range
# acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
Regularmente una lista de control de acceso se establece con la siguiente sintaxis:
acl [nombre de la lista] [tipo] [lo que compone a la lista]
Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde los anfitriones tienen direcciones del segmento IP 192.168.100.0/24, se puede utilizar lo siguiente:
acl localnet src 192.168.100.0/24
También puede definirse una Lista de Control de Acceso especificando un archivo localizado en cualquier parte del disco duro y la cual contiene una lista de direcciones IP. Ejemplo:
acl permitidos src "/etc/squid/listas/permitidos"
El archivo /etc/squid/listas/permitidos tendría un contenido similar al siguiente:
192.168.100.10
192.168.100.15
192.168.100.20
192.168.100.50
192.168.100.100
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el archivo /etc/squid/listas/permitidos.
🔧 Nota de Depuración: Squid fallará al iniciar si la ruta especificada en una ACL de tipo archivo (ej: src "/ruta/archivo") es incorrecta, si el archivo no existe o si su nombre está mal escrito. Verifique siempre estas rutas al depurar errores de inicio.
Estas definen si se permite o deniega acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
La sintaxis básica de una regla de control de acceso es la siguiente:
http_access [deny o allow] [lista de control de acceso]
Para desactivar la configuración predeterminada y poder utilizar una diferente, localice La línea que incluye http_access allow localnet:
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
Deshabilite esta línea colocando una almohadilla (#) al inicio de ésta:
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
# http_access allow localnet
http_access allow localhost
En el siguiente ejemplo se considera una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:
http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión ! —la cual significa no. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 pero denegando aquello que comprenda lista2:
http_access allow lista1 !lista2
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso y otro grupo dentro de la misma red al que se debe denegar el acceso.
Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, se procede a determinar cuales utilizar para la configuración.
Considerando como ejemplo que se dispone de una red 192.168.100.0/24, si se desea definir toda la red local, se utilizaría la siguiente línea en la sección de Listas de Control de Acceso:
acl localnet src 192.168.100.0/24
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
# Recommended minimum configuration:
acl all src 0.0.0.0/0
acl manager proto cache_object
acl localhost src 127.0.0.1/8
acl localnet src 192.168.100.0/24
A continuación se procede a aplicar la regla de control de acceso:
http_access allow localnet
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
http_access allow localnet
http_access deny all
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada locanet, la cual, en el siguiente ejemplo, está conformada por 192.168.100.0/24. Esto significa que cualquier anfitrión desde 192.168.100.1 hasta 192.168.100.254 podrá acceder a Squid.
Si sólo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un archivo que contenga dicha lista. Genere el archivo /etc/squid/listas/localnet, dentro del cual se incluirán sólo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:
192.168.100.10
192.168.100.15
192.168.100.20
192.168.100.25
192.168.100.30
Denominaremos a esta lista de control de acceso como locanet:
acl localnet src "/etc/squid/listas/localnet"
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:
Listas de Control de Acceso: definición de una red local completa
#
# Recommended minimum configuration:
acl all src 0.0.0.0/0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl localnet src "/etc/squid/listas/localnet"
A continuación se procede a aplicar la regla de control de acceso:
http_access allow localnet
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente:
Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
http_access allow localnet
http_access deny all
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada locanet, la cual está conformada por las direcciones IP especificadas en el archivo */etc/squid/listas/localnet. Esto significa que cualquier anfitrión excluido del archivo /etc/squid/listas/localnet se le denegará el acceso a Squid.
Esta opción es de carácter informativo. De modo predeterminado, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.
cache_mgr admin@midominio.net
Esta opción es utilizado para indicar el puerto a través del cual escuchará peticiones Squid. El valor predeterminado es 3128, es decir, Squid escuchará peticiones a través del puerto 3128/tcp.
http_port 3128
El puerto estándar designado para servidores de caché de Internet ―webcache― es el puerto 8080.
http_port 8080
La opción permite establecer también si se quiere utilizar una dirección IP en particular. Esto añade mayor seguridad al servicio, pues si se tiene dos tarjetas de red, una con una dirección IP pública y otra con una dirección IP privada, se puede establecer que Squid sólo permita conexiones desde la dirección IP privada. En este ejemplo, el servidor Squid tiene la dirección IP 192.168.100.2.
http_port 192.168.100.2:8080
Si se necesita configurar un servidor intermediario en modo transparente, sólo es necesario añadir la opción intercept.
http_port 192.168.100.2:8080 intercept
Esta opción se utiliza para estableceer qué tamaño se desea que utilice Squid para almacenamiento de caché en el disco duro. De modo predeterminado Squid utilizará el formato ufs para crear en el directorio /var/spool/squid un caché de 100 MB, dividido en jerarquías de 16 directorios subordinados, hasta 256 niveles cada uno:
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se consumirá menos el ancho de banda. La siguiente línea establece un caché de 2 GB:
cache_dir ufs /var/spool/squid 2048 16 256
El formato de cache ufs puede llegar a bloquear el proceso principal de Squid en operaciones de entrada/salida sobre el sistema de archivos cuando hay muchos clientes conectados. Para evitar que esto ocurra, se recomienda utilizar aufs, que utiliza el mismo formato de ufs, pero funciona de manera asincrónica, consiguiéndose un mejor desempeño.
cache_dir aufs /var/spool/squid 2048 16 256
🔧 Nota sobre la estructura de directorios: Tanto el guion de instrucciones (script) de inicio para SysVinit como la unidad de servicio para SystemD se encargan de crear automáticamente la estructura de directorios necesaria para el caché en /var/spool/squid al iniciar el servicio por primera vez o bien si así se requiere. Es innecesario crearla manualmente.
Esta opción se utiliza para definir el tamaño máximo de los objetos en el caché. Se recomienda establecerla en escenarios con alta carga de trabajo, puesto que permite evitar desperdiciar recursos de sistema almacenando en el caché objetos de gran tamaño que probablemente sólo sean aprovechados por unos pocos usuarios, optimizando el uso del caché con objetos pequeños que de otro modo generarían una gran cantidad de peticiones hacia las redes públicas. En el siguiente ejemplo se establece un límite de 48 MB para los objetos del caché.
maximum_object_size 48 MB
Es posible realizar una limpieza automática del caché de Squid cuando éste llegue a cierta capacidad. La opción cache_swap_low establece el porcentaje a partir del cual se comenzará a limpiar el cache. La opción cache_swap_high establece el porcentaje a partir del cual se comenzará a limpiar de manera agresiva el cache. En el siguiente ejemplo se establece que el cache se comienza a limpiar cuando alcanza el 90% y se comienza a limpiar de manera agresiva cuando alcanza el 95%.
cache_swap_low 90
cache_swap_high 95
Lo anterior permite tener un caché saludable que se limpia automáticamente. Se recomienda utilizar estas opciones en escenarios con alta carga de trabajo.
A través de esta opción se incluye soporte para los siguientes algoritmos para el caché:
| Algoritmo | Descripción |
|---|---|
| LRU | Acrónimo de Least Recently Used, que traduce como Menos Recientemente Utilizado. En este algoritmo los objetos que fueron accedidos hace mucho tiempo, son eliminados primero y manteniendo siempre en el caché a los objetos más recientemente solicitados. Ésta política es la utilizada por Squid de modo predeterminado. |
| LFUDA | Acrónimo de Least Frequently Used with Dynamic Aging, que se traduce como Menos Frecuentemente Utilizado con Envejecimiento Dinámico. En este algoritmo los objetos más solicitados permanecen en el caché sin importar su tamaño optimizando la eficiencia ―hit rate― por octetos ―Bytes― a expensas de la eficiencia misma, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia. |
| GDSF | Acrónimo de Greedy Dual Size Frequency, que se traduce como Frecuencia de tamaño GreedyDual ―codicioso dual―, que es el algoritmo sobre el cual se basa GDSF. Optimiza la eficiencia ―hit rate― por objeto manteniendo en el caché los objetos pequeños más frecuentemente solicitados de modo que hay mejores posibilidades de lograr respuesta a una solicitud ―hit―. Tiene una eficiencia por octetos ―Bytes― menor que el algoritmo LFUDA debido a que descarta del caché objetos grandes que sean solicitado con frecuencia. |
El algoritmo recomendado y que ha demostrado mejor desempeño en escenarios de alta carga de trabajo es LFUDA.
cache_replacement_policy heap LFUDA
La opción cache_mem establece la cantidad ideal de memoria para lo siguiente:
Los datos de estos objetos se almacenan en bloques de 4 Kb. La opción cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos frecuentemente utilizados ―Hot― y aquellos negativamente almacenados en el caché, podrán utilizar la memoria sin utilizar hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición.
El valor predeterminado de 256 MB es más que suficiente para las necesidades de redes de área local con pocos anfitriones. Puede especificar una cantidad menor para obtener un mejor rendimiento, pues conviene utilizar la memoria disponible para hacer cache en memoria de muchos objetos pequeños que son frecuentemente visitados, que hacer cache de unos pocos objetos grandes que sólo unos pocos usuarios aprovecharán. En el siguiente ejemplo se establecen 48 MB como límite de tamaño para los objetos en tránsito:
cache_mem 48 MB
Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors. Squid detecta el idioma automáticamente a partir del navegador utilizado por el usuario. Es innecesario modificar opción alguno, salvo que se haya personalizado los mensajes, en cuyo caso conviene utilizar una ruta distinta a la del idioma utilizado para evitar se sobre-escriban los archivos después de actualizar el sistema.
Una vez terminada la configuración, para iniciar por primera vez Squid ejecute:
Para sistemas con SystemD (AlmaLinux, Rocky Linux, RHEL 8+):
systemctl start squid
Para sistemas con SysVinit (ALDOS):
service squid start
Si necesita volver a cargar la configuración para probar cambios realizados, sin detener el servicio, ejecute:
service squid reload
Si necesita reiniciar para probar cambios hechos en la configuración, considerando que este proceso puede llegar a demorar algunos minutos, ejecute:
Para sistemas con SystemD:
systemctl restart squid
Para sistemas con SysVinit:
service squid restart
Para que Squid inicie de manera automática junto con el sistema, ejecute:
Para sistemas con SystemD:
systemctl enable squid
Para sistemas con SysVinit:
chkconfig squid on
Lo anterior habilitará el servicio squid en todos los niveles de ejecución.
Cualquier error al inicio de Squid sólo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los archivos de las Listas de Control de Acceso.
Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el archivo /etc/squid/squid.conf.
service squid reload
Cuando se trata de errores graves que impiden iniciar el servicio, puede examinarse el contenido del archivo /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:
tail -80 /var/log/squid/squid.out
FirewallD es la solución predeterminada y recomendada para la gestión del muro cortafuegos en distribuciones modernas como ALDOS, AlmaLinux, Rocky Linux y Red Hat Enterprise Linux 8/9/10.
Si se utiliza un cortafuegos con políticas estrictas, es necesario abrir el puerto donde escucha Squid. El puerto predeterminado es 3128, pero si eligió utilizar el puerto 8080, deberá permitir éste.
Para añadir el puerto de Squid de forma permanente a la zona activa (por ejemplo, public o internal), utilice firewall-cmd :
firewall-cmd --permanent --add-port=3128/tcp
firewall-cmd --reload
FirewallD también incluye una definición de servicio para squid. Puede utilizarla como alternativa a abrir el puerto directamente :
firewall-cmd --permanent --add-service=squid
firewall-cmd --reload
La acción de redireccionamiento de FirewallD permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid, configurado como Servidor Intermediario ―Proxy― transparente.
Para redirigir el tráfico HTTP (puerto 80) hacia el puerto donde escucha Squid (por ejemplo, 8080), en una zona específica (como internal), ejecute:
firewall-cmd --permanent --zone=internal --add-forward-port=port=80:proto=tcp:toport=8080
firewall-cmd --reload
Importante: Esta regla requiere que el enmascaramiento (masquerading) esté activo en la zona. Puede habilitarlo con:
firewall-cmd --permanent --zone=internal --add-masquerade
firewall-cmd --reload
En el caso de sitios que se quiera excluir de ser utilizados con Squid, es decir, sitios problemáticos, se puede configurar en Firewalld que el acceso sea directo, con una configuración que utilice reglas de enriquecimiento (rich rules). Por ejemplo, para excluir las redes 201.144.108.0/24 (IMSS.gob.mx) y 200.33.74.0/24 (SAT.gob.mx) del redireccionamiento y permitir el acceso directo:
firewall-cmd --permanent --zone=internal --add-rich-rule='rule family="ipv4" destination address="201.144.108.0/24" accept'
firewall-cmd --permanent --zone=internal --add-rich-rule='rule family="ipv4" destination address="200.33.74.0/24" accept'
firewall-cmd --reload
Una vez configurado Squid con las opciones básicas, es posible implementar controles de acceso más avanzados. Considere consultar los siguientes manuales para profundizar en el tema:
Estos manuales complementan la configuración básica y permiten crear un entorno de filtrado y control de acceso robusto y adaptado a las necesidades específicas de cada organización.