CONFIGURACIÓN DEL ROUTER LINUX

Paso 1:

Configurar las placas de red, eth0 (192.168.0.7/24), es la que nos dará la salida a internet (ethX).

Configurar eth1 como red local (192.168.10.1/24), será nuestra red local (ethY).

Configurar las iptables para que trabaje como router.

#iptables –F

#iptables –t nat –F

#modprobe iptable_nat

#echo 1 > /proc/sys/net/ip_forward

CentOS 6

#iptables –t nat –A POSTROUTING –o ethX –j SNAT --to M.Y.Z.W

CentOS 5

#iptables –A POSTROUTING –t nat –s W.Z.Y.M –o ethX –j MASQUERADE

o probar con la siguiente línea que es la que me funciono

#iptables –t nat –A POSTROUTING –o ethX –j MASQUERADE

Siendo X la interfase conectada a internet y M.Y.Z.W la dirección IP de la interfaz, y W.Z.Y.M la red local que está conectada a la ethY local

Paso 2:

Configurar las iptables para que el proxy funcione de manera transparente.

Debemos redireccionar todo nuestro tráfico LAN que ingresa por la interfaz al proxy:

#iptables –t nat –A PREROUTING –i ethY –p tcp --dport 80 –j DNAT --to-destination M.Y.Z.W:3128

#iptables –t nat –A PREROUTING –i ethY –p tcp --dport 80 –j DNAT --to-destination M.Y.Z.W:8080

Siendo Y el número de interfaz de nuestra red local.

Paso 3:

SELinux y el servicio Squid, implementar una política para que SELinux le permita al Squid aceptar conexiones de los clientes desde cualquier IP

En CentOS 5:

#setsebool –P squid_connect_any 1

En Centos 6:

#setsebool –P squid_use_tproxy 1

Paso 4:

Instalar squid y configurar el archivo squid.conf (ya lo tengo configurado)

Errores de Squid con los que nos podemos encontrar:

#init_cache_dir /var/spool/squid… Iniciando squid: [FALLÓ]

Problema: Este error se debe a la creación de la estructura de directorios dentro de /var/spool/squid.

Solución:

- Borrar el contenido de la ruta /var/spool/squid:#rm –rf /var/spool/squid/*

- Parar squid, si es que está funcionando:#service squid stop

- Crear la estructura de directorios:#squid –z

- Reiniciamos el squid:#service squid restart

CONFIGURACIÓN DE PROXY A TRAVÉS DE WPAD

Muchos sitios de internet, funcionan a través del protocolo HTTPS , por lo que resulta poco práctico configurar servidores intermediarios (proxies) en modo transparente, ya que solo permiten 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 manera de filtrar la actividad de los usuarios a través de HTTPS, es olvidarse del modo transparente del Squid y utilizar una configuración manual del servidor proxy. Sin embargo, esto representaría como administrador de red una enorme cantidad de trabajo, ya que se debería pasar anfitrión por anfitrión a realizar la configuración. Una manera de automatizar la configuración es mediante servidores DHCP y servidores DNS, utilizando WPAD.

WPAD nos permite eliminar la configuración del proxy en modo transparente y utilizar otro tipo de configuración, con una configuración de proxy-caché que permita el acceso hacia Internet utilizando sólo una lista blanca y el cierre de la salida por NAT hacia el puerto 443, además de permitir bloquear servicios como Facebook, y de bloquear de manera eficiente programas que no queremos que saturen el tráfico de nuestra red. Si además cerramos la salida hacia el puerto 22/TCO y la salida hacia los puertos 53/UDP y 53/TCP, también se puede bloquear con éxito programas como (Ver los que funcionan en ese puerto, ver si se puede bloquear Spotify).

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.2.

El borrador del protocolo WPAD, expiró en 1999, pero a pesar de haber 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 siguientes métodos:

a. Mediante un servidor DHCP.b. Mediante un servidor DNS.

Se pueden utilizar el que se prefiera, yo opto por utilizar un servidor DHCP. Se recomienda no utilizar de manera simultánea ambos métodos ya que los anuncios serían ignorados por los navegadores. Utilizar un servidor DHCP es el método estándar. 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.

Instalaciones Necesarias

Servidor Apache

Debemos instalar un servidor apache en el servidor que utilizamos como cortafuegos (firewall)/ proxy

yum –y install httpd

Iniciamos el servidor Apache

service httpd start

Para que el servidor Apache inicie junto con el sistema

chkconfig httpd on

Ajustes en el Firewall

Es necesario abrir el muro cortafuegos el puerto 80 por TCP (HTTP) para la red de área local. Asumiremos 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.

Shorwewall

Editaremos el archivo /etc/shorewall/rules:

gedit /etc/shorewall/rules

Eliminamos 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) 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 accedes hacia servidores SSH legítimos que utilicen el puerto 22/TCP, debemos añadir 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 necesitamos acceder hacia servidores DNS legítimos, añadimos un par de reglas similares a las mostradas en el siguiente ejemplo, en el cual asumimos que el servidor DNS involucrado tiene la 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 22ACCEPT loc net:8.8.8.8 tcp 53ACCEPT 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, acá es donde se encuentra el squid) 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 22ACCEPT loc net:8.8.8.8 tcp 53ACCEPT loc net:8.8.8.8 udp 53ACCEPT loc net:8.8.4.4 tcp 53ACCEPT loc net:8.8.4.4 udp 53ACCEPT loc fw tcp 80,8080

Y finalmente reiniciamos el shorewall:

service shorewall restart

Servicio iptables

Asumiendo que Squid escucha peticiones en el puerto 8080 y que la red de área local corresponde a 172.16.1.0/28, ejecutaremos 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 ACCEPTiptables -A INPUT -s 172.16.1.0/28 -m state --state NEW \    -m tcp -p tcp --dport 8080 -j ACCEPTiptables -A FORWARD -p tcp --dport 20:21 -j DROPiptables -A FORWARD -p tcp --dport 22 -j DROPiptables -A FORWARD -p tcp --dport 443 -j DROPiptables -A FORWARD -p tcp --dport 53 -j DROPiptables -A FORWARD -p udp --dport 53 -j DROP

Ejecutamos el siguiente comando para guardar las iptables

service iptables save

O bien debemos editar el archivo /etc/sysconfig/iptables y añadir las siguientes líneas:

-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 nuevamente reiniciamos el servicio de iptables:

service iptables restart

Procedimientos

Asumiremos que ya tenemos configurado el servidor proxy-caché con Squid, un servidor DHCP y un servidor DNS. Debemos tener en cuenta de reemplazar los valores de este ejemplo por los valores que correspondan a nuestra red de área local.

Resolución del nombre de anfitrión

Editamos el archivo /etc/hosts:

gedit /etc/hosts

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

127.0.0.1 localhost.localdomain localhost::1 localhost6.localdomain6 localhost6192.168.70.20 m20.alcancelibre.org.mx m20172.16.1.1 servidor.red-local.net servidor172.16.1.1 wpad.red-local.net wpad

Modifiquemos lo que sea necesario para que el ajuste a la configuración utilizada en nuestra red local.

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 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, editamos el archivo /etc/named.conf

gedit /etc/named.conf

Debemos localizar 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. Por 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 prohíbe realizar actualizaciones de los registros de la zona. Por ejemplo:

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

}

Resolver nombre de anfitrión en el Servidor DNS con zona dinámica

Si se trata de una zona dinámica, ejecutamos el nsupdate para conectar al servidor DNS:

nsupdate –k /etc/rndc.key

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

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

Utilizando este procedimiento, es necesario reiniciar el servidor named.

Resolver nombre de anfitrión en el Servidor DNS con zona estática

Se requiere configurar primero el servidor DNS para que incluya un registro que resuelva el nombre de wpad.red-local.net el cual será utilizado para hacer el anuncio 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 nombres de anfitrión y direcciones IP de la red de área local, editamos el archivo de zona correspondiente:

gedit /var/named/data/red-local.net.zone

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

wpad IN A 172.16.1.1

Reiniciamos el servicio named.

service named restart

Generaremos el archivo wpad.dat

Generaremos 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. Podemos 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

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

gedit /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 denominado servidor.red-local.net, escuchando peticiones en el puerto 8080, añadiremos 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"; }}

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

Configuración de Apache

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

gedit /etc/httpd/conf.d/wpad.conf

Y añadiremos el siguiente contenido:

NameVirtualHost *:80<VirtualHost *:80>

ServerName wpad.red-local.netServerAlias wpadDocumentRoot /var/www/wpadErrorLog logs/wpad-error_logCustomLog logs/wpad-access_log combined<Directory "/var/www/wpad">

AddType application/x-ns-proxy-autoconfig .datDirectoryIndex wpad.dat

<IfModule mod_authz_core.c># Apache 2.4Require localRequire ip 172.16.1.0/28

</IfModule> <IfModule !mod_authz_core.c>

# Apache 2.2Order Deny,AllowDeny from allAllow from 127.0.0.0/8 172.16.1.0/28

</IfModule> </Directory></VirtualHost>

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

A fin de evitar problemas con algunos navegadores, es recomendable que este sea el único anfitrión virtual en el servidor o bien que al menos sea el anfitrión virtual predeterminado.

Reiniciamos o recargamos el servicio httpd

service httpd reload

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

Configuración del servidor DHCP

Asumiendo que tenemos configurado y funcionando el servidor DHCP (para nuestro caso nuestro servidor DHCP es Mikrotik) para gestionar la asignación de las direcciones IP utilizadas por la red de área local. En este ejemplo lo hace el mismo Linux, editamos el archivo /etc/dhcp/dhcpd.conf:

gedit /etc/dhcp/dhcpd.conf

Añadiremos en la configuración del servidor DHCP, las siguientes opciones:

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;

}

Reiniciamos el servicio dhcpd

service dhcpd restart

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

Anuncio del archivo wpad.dat a través del 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, editamos el archivo de la zona correspondiente:

gedit /var/named/data/red-local.net.zone

Cambiamos el número de serie de la zona y añadimos los siguientes dos registros en la zona de reenvío en el DNS utilizando por la red de área local. En el ejemplo asumiremos que el servidor HTTP que hospeda el 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"

Reiniciamos el servidor named

service named restart

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

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

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

nsupdate –k /etc/rndc.key

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

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

Utilizando este ultimo procedimiento, es innecesario reiniciar el servicio named.

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

Comprobaciones

Si todo lo anterior concluyó sin errores, sólo resta verificar que la configuración de los anfitriones con Windows.

En internet explorer ingresamos a Opciones de Internet -> Conexiones -> Configuraciones LAN y verificamos 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 – Config del WPAD

Para los anfitriones con GNU/Linux con GNOME 2 como escritorio (en nuestro caso solo tenemos clientes Windows, y por políticas no se dan contraseñas de wifi, por lo tanto ningún smathphone tiene acceso a nuestro wpad, ver como se regularía en un celular).

CONFIGURAR EL MIKROTIK PARA QUE ACCEDA AL WPAD