Si algunos de nuestros foros, manuales, ALDOS, paquetería o proyectos te han resultado de ayuda, apreciaremos mucho nos apoyes con un donativo.

Configuración automática de proxy a través de WPAD.

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: http://www.alcancelibre.org/
Jabber ID: darkshram@jabber.org

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2016 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

Este documento requiere haber estudiado y comprendido previamente los documentos titulados «Configuración básica de Shorewall», «Configuración de servidor DHCP» y «Configuración de Squid: Opciones básicas».

¿Qué es WPAD?

WPAD (Web Proxy Auto-Discovery protocol) es un método utilizado por los clientes de servidores Proxy para localizar el URI de un archivo de configuración, valiéndose de métodos de descubrimiento a través de DHCP y DNS.

Los clientes descargan y ejecutan un archivo, que debe denominarse wpad.dat, utilizando el formato de auto-configuración de proxy (PAC, Proxy Auto-Config) diseñado por Netscape en 1996 para Netscape Navigator 2.0.

El borrador del protocolo WPAD, el cual expiró en 1999, fue elaborado por un consorcio de empresas que incluían a Inktomi Corp., Microsoft, Real Networks Inc. y Sun Microsystems Inc. A pesar de tratarse de un borrador que ha expirado, la mayoría de los navegadores modernos incluyen soporte para este protocolo.

El anuncio del archivo wpad.dat hacia la red de área local sólo puede hacerse a través de uno de los dos siguientes métodos:

  1. A través de un servidor DHCP.
  2. A través de un servidor DNS.

Se puede utilizar indistintamente uno u otro método. Jamás combine ambos métodos porque los anuncios serían ignorados por los navegadores. El método más estándar es el anuncio a través de un servidor DHCP. Ambos métodos requieren añadir registros en zonas de reenvío estáticas o dinámicas del servidor de DNS utilizado por la red de área local.

¿Por qué utilizar WPAD?

Gracias a que una gran cantidad de sitios de Internet ahora funcionan a través de HTTPS, resulta poco práctico configurar servidores intermediarios (proxies) en modo transparente, pues éstos solo permiten el modo transparente para el protocolo HTTP (puerto 80/TCP), obligando a los administradores de redes de área local a configurar la salida del protocolo HTTPS (puerto 443/TCP) a través de NAT en el muro cortafuegos.

Una forma de enfrentar el problema y poder controlar y filtrar la actividad de los usuarios a través de HTTPS, es olvidarse del modo transparente de Squid y utilizar una configuración manual del servidor proxy. Sin embargo, ésto representaría una enorme cantidad de trabajo para los administradores de redes de área local, quienes tendrían que pasar anfitrión por anfitrión a realizar la configuración. Ésta, sin embargo, se puede automatizar anunciando ésta a través de servidores DHCP y servidores DNS, utilizando WPAD.

Eliminar la configuración de proxy en modo trasparente y utilizar en su lugar el método descrito en este documento, combinado con una configuración del proxy-cache que permita el acceso hacia Internet utilizando sólo a una lista blanca y el cierre de la salida por NAT hacia el puerto 443, además de permitir bloquear servicios como Facebook, permite también bloquear de manera eficiente programas como Ultrasurf y Your Freedom. Si además se cierra la salida hacia el puerto 22/TCP y la salida hacia los puertos 53/UDP y 53/TCP, también se puede bloquear con éxito a programas como Tor Browser.

Equipamiento lógico necesario.

Instale Apache en el servidor que utilice como muro cortafuegos/proxy.

yum -y install httpd

Inicie el servicio httpd.

service httpd start

Para que el servicio httpd inicie junto con el sistema, ejecute lo siguiente:

chkconfig httpd on

Ajustes en el muro cortafuegos.

Es necesario abrir en el muro cortafuegos el puerto 80 por TCP (HTTP) para la red de área local. Se asume que ya están abiertos los puertos correspondientes al resto de los servicios involucrados, es decir los puertos 67 (bootps), 68 (bootpc) y 53 (domain) por TCP y UDP.

Firewalld.

Firewalld es muy limitado en el aspecto de control de enmascaramiento de IP. Es un todo o nada. Sin embargo permite utilizar reglas de lenguaje enriquecido para configuraciones más específicas. Ejecute las siguientes 5 líneas.

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.16.1.0/28 destination address=0.0.0.0/0 port port=80 protocol=tcp reject'

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.16.1.0/28 destination address=0.0.0.0/0 port port=20-21 protocol=tcp reject'

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.16.1.0/28 destination address=0.0.0.0/0 port port=442 protocol=tcp reject'

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.16.1.0/28 destination address=0.0.0.0/0 port port=53 protocol=tcp reject'

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.16.1.0/28 destination address=0.0.0.0/0 port port=53 protocol=udp reject'

Ejecute lo siguiente para aplicar los cambios:

firewall-cmd --reload

Debo hacer énfasis en que Shorewall es una solución más precisa, sencilla y robusta. Firewalld puede hacer muy complejo operaciones que con otras alternativas son más simples.

Shorewall.

Edite el archivo el archivo /etc/shorewall/rules:

vim /etc/shorewall/rules

Elimine la configuración de proxy transparente deshabilitando las reglas correspondientes a la salida desde la zona correspondiente a la red de área local hacia los puertos 20/TCP (ftp-data), 22/TCP (ssh), 21/TCP (ftp), 53/TCP (dns), 53/UDP (dns) y 443/TCP (https) en la zona correspondiente a la red pública y la regla que redirige hacia el puerto 8080/TCP (webcache) las peticiones desde la red de área local hacia el puerto 80/TCP (http):

#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
#ACCEPT	loc	net	tcp	20,21,443
#ACCEPT	loc	net	tcp	22
#ACCEPT	loc	net	tcp	53
#ACCEPT	loc	net	udp	53
#REDIRECT	loc	8080	tcp	80
#

Si necesita acceder hacia servidores SSH legítimos que utilicen el puerto 22/TCP, añada una regla similar a la mostrada en el siguiente ejemplo, en la cual se asume que el servidor SSH involucrado tiene dirección IP hipotética equivalente a 200.1.2.3:

#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
#ACCEPT	loc	net	tcp	20,21,443
#ACCEPT	loc	net	tcp	22
#ACCEPT	loc	net	tcp	53
#ACCEPT	loc	net	udp	53
#REDIRECT	loc	8080	tcp	80
#
ACCEPT	loc	net:200.1.2.3	tcp	22

Si necesita acceder hacia servidores DNS legítimos, añada un par de reglas similares a las mostradas en el siguiente ejemplo, en la cual se asume que el servidor DNS involucrado tiene dirección IP hipotética equivalente a 8.8.8.8:

#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
#ACCEPT	loc	net	tcp	20,21,443
#ACCEPT	loc	net	tcp	22
#ACCEPT	loc	net	tcp	53
#ACCEPT	loc	net	udp	53
#REDIRECT	loc	8080	tcp	80
#
ACCEPT	loc	net:200.1.2.3	tcp	22
ACCEPT	loc	net:8.8.8.8	tcp	53
ACCEPT	loc	net:8.8.8.8	udp	53

Otra solución sería configurar un servidor DNS dentro de la red de área local para poder prescindir de abrir la salida hacia los puertos 53/TCP y 53/UDP.

Asumiendo que Squid escucha peticiones en el puerto 8080 y que sólo se permitirán conexiones desde la red de área local, la regla que habilita el acceso desde la red de área local hacia los puertos 8080 (webcache) y 80 (http) del muro cortafuegos correspondería a algo similar a lo siguiente:

#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
#ACCEPT	loc	net	tcp	20,21,80,443
#ACCEPT	loc	net	tcp	22
#REDIRECT	loc	8080	tcp	80
#
ACCEPT	loc	net:200.1.2.3	tcp	22
ACCEPT	loc	net:8.8.8.8	tcp	53
ACCEPT	loc	net:8.8.8.8	udp	53
ACCEPT	loc	net:8.8.4.4	tcp	53
ACCEPT	loc	net:8.8.4.4	udp	53
ACCEPT	loc	fw	tcp	80,8080

Ejecute lo siguiente para aplicar los cambios:

service shorewall restart

Servicio iptables.

Asumiendo que Squid escucha peticiones en la puerto 8080 y que la red de área local corresponde a 172.16.1.0/28, ejecute lo siguiente para abrir los puertos 80/TCP (http) y 8080/TCP (webcache) del servidor y cerrar la salida desde la red de área local hacia los puertos 20 (ftp-data), 21 (ftp), 22 (ssh) y 443 (https) en el exterior:

iptables -A INPUT -s 172.16.1.0/28 -m state --state NEW \
    -m tcp -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -s 172.16.1.0/28 -m state --state NEW \
    -m tcp -p tcp --dport 8080 -j ACCEPT
iptables -A FORWARD -p tcp --dport 20:21 -j DROP
iptables -A FORWARD -p tcp --dport 22 -j DROP
iptables -A FORWARD -p tcp --dport 443 -j DROP
iptables -A FORWARD -p tcp --dport 53 -j DROP
iptables -A FORWARD -p udp --dport 53 -j DROP

Ejecute lo siguiente para guardar los cambios:

service iptables save

O bien edite el archivo /etc/sysconfig/iptables:

vim /etc/sysconfig/iptables

Y añada lo siguiente:

-A INPUT -s 172.16.1.0/28 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -s 172.16.1.0/28 -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A FORWARD -p tcp --dport 20:21 -j DROP
-A FORWARD -p tcp --dport 22 -j DROP
-A FORWARD -p tcp --dport 443 -j DROP
-A FORWARD -p tcp --dport 53 -j DROP
-A FORWARD -p udp --dport 53 -j DROP

Y reinicie el servicio iptables:

service iptables restart

Procedimientos.

Este documento asume que se tiene configurado un servidor proxy-cache con Squid, un servidor DHCP y un servidor DNS. Por favor, cambie todos los valores resaltados en el procedimiento por aquellos que correspondan al escenario de su red de área local.

Resolución del nombre de anfitrión en el anfitrión local.

Es importante que el nombre de anfitrión que utilizarán los clientes para acceder al archivo wpad.dat esté resuelto en el anfitrión local del servidor.

Edite el archivo /etc/hosts:

vim /etc/hosts

Asumiendo que la dirección IP del anfitrión es 172.16.1.1 y que el dominio de la red de área local es red-local.net, añada la siguiente línea resaltada en negrita y respetando el resto del contenido existente en este archivo:

127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6 localhost6
192.168.70.20	m20.alcancelibre.org.mx	m20
172.16.1.1	servidor.red-local.net	servidor
172.16.1.1	wpad.red-local.net	wpad

Modifique lo que sea necesario para que ajuste a la configuración utilizada en su red de área local.

Resolución del nombre de anfitrión en servidor DNS.

A fin de que la red de área local también pueda resolver este nombre, se requiere también añadir un registro tipo A en la zona de DNS correspondiente a la zona de reenvío utilizada para resolver los nombres de la red de área local.

Identifique primero si utiliza una zona de reenvío dinámica o estática. Para este fin, edite el archivo /etc/named.conf:

vim /etc/named.conf

Localice la zona de reenvío que corresponda a la red de área local.

Una zona dinámica almacena sus archivos de zona dentro del sub-directorio /var/named/dynamic y permite realizar actualizaciones de los registros de la zona a través de una firma digital. Ejemplo:

	zone "red-local.net" {
		type master;
		file "dynamic/red-local.net.zone";
		allow-update { key "rndc-key"; };
	}

Una zona estática almacena sus archivos de zona dentro de una ruta relativa al directorio /var/named o bien el sub-directorio /var/named/data y prohibe realizar actualizaciones de los registros de la zona. Ejemplo:

	zone "red-local.net" {
		type master;
		file "red-local.net.zone";
		allow-update { none; };
	}

Resolver nombre de anfitrión en servidor DNS con zona dinámica.

Si se trata de una zona dinámica, ejecute nsupdate para conectarse al servidor DNS:

nsupdate -k /etc/rndc.key

Desde el intérprete de mandatos de nsupdate, ejecute lo siguiente para añadir el registro necesario:

server 127.0.0.1
update add wpad.red-local.net. 86400 A 172.16.1.1
send
quit

Utilizando este procedimiento, es innecesario reiniciar el servicio named.

Resolver nombre de anfitrión en servidor DNS con zona estática.

Se requiere configurar primero el servidor DNS para que incluya un registro que resuelva el nombre wpad.red-local.net el cual será utilizado para hacer el anuncio del URI del archivo wpad.dat a través del servidor DHCP.

Asumiendo que tiene configurado y funcionando un servidor DNS con una zona estática que resuelve los nombres de anfitrión y direcciones IP de la red de área local, edite el archivo de zona correspondiente:

vim /var/named/red-local.net.zone

Cambie el número de serie de la zona y añada sólo el siguiente registro en la zona de reenvío en el DNS utilizado por la red de área local. En el ejemplo se asume que el servidor HTTP que hospeda al archivo wpad.dat corresponde a la dirección IP 172.16.1.1:

wpad	IN	A	172.16.1.1

Reinicie el servicio named.

service named restart

Generar archivo wpad.dat.

Genere el directorio /var/www/wpad con permisos de acceso y escritura para usuario y de acceso para grupo y otros (rwxr-xr-x):

mkdir -m 0755 /var/www/wpad

Cualquier error en la sintaxis hará que el archivo sea imposible de utilizar. Puede descargar un archivo plantilla desde AlcanceLibre.org ejecutando lo siguiente:

wget http://www.alcancelibre.org/linux/secrets/wpad.dat \
    -O /var/www/wpad/wpad.dat

Es indispensable que el archivo /var/www/wpad/wpad.dat tenga permisos de lectura para todos, de otro modo será imposible compartirlo a través del servicio httpd.

chmod a+r /var/www/wpad/wpad.dat

Personalizar el archivo wpad.dat.

Edite el archivo /var/www/wpad/wpad.dat y modifique lo que sea necesario para que ajuste a la configuración utilizada en su red de área local.

vim /var/www/wpad/wpad.dat

Asumiendo que la red de área local corresponde a 172.16.1.0/28 (172.16.1.0/255.255.255.240) y que Squid está funcionando en el anfitrión denimonado servidor.red-local.net, escuchando peticiones en el puerto 8080, añada el siguiente contenido:

function FindProxyForURL(url, host)
{ 
        if (
            isInNet(host, "172.16.1.0",  "255.255.255.240")
        ||  isInNet(host, "127.0.0.0", "255.0.0.0")
        ||  shExpMatch(host, "172.16.1.*")
        ||  shExpMatch(host, "127.*" )
        ||  shExpMatch(host, "localhost")
        ||  shExpMatch(host, "*.red-local.net")
        ||  isPlainHostName(host)
        ||  dnsDomainIs(host, ".red-local.net")
        ) {
            return "DIRECT"; 
          }
        else 
          {
            return "PROXY servidor.red-local.net:8080";
          }
}

Guarde el archivo y cierre el editor de texto.

Configuración de Apache.

Genere el archivo /etc/httpd/conf.d/wpad.conf:

vim /etc/httpd/conf.d/wpad.conf

Añada el siguiente contenido:

NameVirtualHost *:80
<VirtualHost *:80>
	ServerName wpad.red-local.net
	ServerAlias wpad
	DocumentRoot /var/www/wpad
	ErrorLog logs/wpad-error_log
	CustomLog logs/wpad-access_log combined
	<Directory "/var/www/wpad">
		AddType application/x-ns-proxy-autoconfig .dat
		DirectoryIndex wpad.dat
    <IfModule mod_authz_core.c>
		# Apache 2.4
		Require local
		Require ip 172.16.1.0/28
    </IfModule>
    <IfModule !mod_authz_core.c>
		# Apache 2.2
		Order Deny,Allow
		Deny from all
		Allow from 127.0.0.0/8 172.16.1.0/28
    </IfModule>
   </Directory>
</VirtualHost>

Modifique lo que sea necesario para que ajuste a la configuración utilizada en su red de área local.

A fin de evitar problemas con algunos navegadores, se recomienda que éste sea el único anfitrión virtual en el servidor o bien que cuando menos sea el anfitrión virtual predeterminado.

Recargue o reinicie el servicio httpd.

service httpd reload

Anuncio del archivo wpad.dat a través de DHCP.

Configuración de servidor DHCP.

Asumiendo que tiene configurado y funcionando un servidor DHCP para gestionar la asignación de las direcciones IP utilizadas por la red de área local —como se describe en el documento titulado «Configuración de servidor DHCP», edite el archivo /etc/dhcp/dhcpd.conf:

vim /etc/dhcp/dhcpd.conf

Añada en la configuración del servidor DHCP, las dos siguientes opciones, justo debajo de la configuración de los servidores NTP:

option ip-forwarding off;
option domain-name "red-local.net";
option ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org;
option wpad-url code 252 = text;
option wpad-url "http://wpad.red-local.net/wpad.dat\n";

include "/etc/rndc.key";

zone localdomain. {
	primary 127.0.0.1;
	key rndc-key;
}

Reinicie el servicio dhcpd.

service dhcpd restart

Recuerde que este método jamás debe combinarse con el del anuncio del archivo wpad.dat a través de servidor DNS.

Anuncio del archivo wpad.dat a través de servidor DNS con zona estática.

Se requiere configurar el servidor DNS para que incluya dos registros, uno que resuelva el nombre wpad.red-local.net y el otro que indique el URI del archivo wpad.dat.

Asumiendo que tiene configurado y funcionando un servidor DNS con una zona estática que resuelve los nombres de anfitrión y direcciones IP de la red de área local, edite el archivo de zona correspondiente:

vim /var/named/red-local.net.zone

Cambie el número de serie de la zona y añada los siguientes dos registros en la zona de reenvío en el DNS utilizado por la red de área local. En el ejemplo se asume que el servidor HTTP que hospeda al archivo wpad.dat corresponde a la dirección IP 172.16.1.1:

wpad	IN	A	172.16.1.1
@	IN      TXT     "service: wpad:!http://wpad.red-local.net:80/wpad.dat"

Reinicie el servicio named.

service named restart

Recuerde que este método jamás debe combinarse con el del anuncio del archivo wpad.dat a través de servidor DHCP.

Anuncio del archivo wpad.dat a través de servidor DNS con zona dinámica.

Si se trata de una zona de reenvío dinámica, ejecute nsupdate para conectarse al servidor DNS:

nsupdate -k /etc/rndc.key

Desde el intérprete de mandatos de nsupdate, ejecute lo siguiente para añadir los registros necesarios:

server 127.0.0.1
update add wpad.red-local.net. 86400 A 172.16.1.1
update add red-local.net. 86400 TXT "service: wpad:!http://wpad.red-local.net:80/wpad.dat"
send
quit

Utilizando este último procedimiento, es innecesario reiniciar el servicio named.

Recuerde que este método jamás debe combinarse con el del anuncio del archivo wpad.dat a través de servidor DHCP.

Comprobaciones.

Si todo lo anterior concluyó sin errores, sólo resta verificar que la configuración de los anfitriones con Windows. Vaya a Opciones de InternetConexionesConfiguración LAN y verifique que esté habilitada la casilla Autodetectar configuración de proxy. En algunos casos es posible que se tenga que definir también el URI del archivo de configuración (http://wpad.red-local.net/wpad.dat).

Opciones de Internet - Configuración de Proxy
Opciones de Internet - Configuración de Proxy.

Para los anfitriones con GNU/Linux con GNOME 2 como escritorio sólo hay que establecer Configuración automática del Proxy en las Preferencias de Proxy de la red. Deje vacío el campo de URL de configuración automática para forzar la detección del archivo wpad.dat anunciado.

Configuración de Proxy de la red en GNOME 2
Configuración de Proxy de la red en GNOME 2.

También pude configurar las opciones de cada navegador que lo requiera para que auto-detecte la configuración del servidor proxy.

Opciones de Firefox - autodetectar configuración del proxy
Opciones de Firefox - autodetectar configuración del proxy.

Si algunos de nuestros foros, manuales, ALDOS, paquetería o proyectos te han resultado de ayuda, apreciaremos mucho nos apoyes con un donativo.

Última Edición: 19/09/2016, 22:37|Hits: 62,784 Ver la versión para imprimir