martes, 2 de diciembre de 2014

proxy automático

Mozilla Firefox
Todo el que halla configurado un navegador con proxy; o sea, todo cubano que halla configurado un navegador, quizás halla visto que una de las tantas opciones dice “configuración automática”. Seguro se preguntarán que carajo es eso.

Pues esa un javascript que le dice al navegador como debe serla configuración del proxy; obviamente.

Resulta que hay dos maneras de hacerlo, vía DHCP o vía DNS. Algunos navegadores lo cogen por DHCP mientras que otros lo hacen por DNS.

Para evitar problemas, configuramos las dos…

Primero y principioso. Creamos el fichero wpad.dat, el nombre debe respetarse. Dicho fichero los servimos, así que por definición los podremos en /var/www. Este fichero contendrá las instrucciones que un navegador necesita para pinchar.
“/var/www/wpad.dat”
1
2
3
4
5
6
7
8
9
10
11
12
function FindProxyForURL(url, host) {

        // los host locales NO pasan a través del proxy
        if(shExpMatch(url,"*.hcg.sld.cu:*")) { return "DIRECT"; }
        if(shExpMatch(url,"*.hcg.sld.cu:*/*")) { return "DIRECT"; }

        // la red local, tampoco
        if(isInNet(host, "10.1.1.0", "255.255.255.0")) { return "DIRECT"; }

        // lo demás sale por el proxy
        return "PROXY 10.1.1.1:3128";
};
Como ve, es javascript puro, osea que las opciones se podrían hacer más creativas. Por ejemplo, si la ip de la máquina es tal, configuralo así o asao.

Los criticones de código diran que se pudo usar un swith en vez de 3 “if”. Pero eso correrá en un momento y entorno casi imposible de debugar. Lo intenté con swith y no me pinchó. Ahora el problema es que hay que declarar un nuevo contenido mime para este dato. En mi caso uso nginx y en el fichero de configuración de mime, le aclaramos el nuevo; a mi me quedó así:
mime.conf
1
2
3
4
5
6
7
types {

    application/x-ns-proxy-autoconfig     dat;
    text/html                             html htm shtml;
    text/css                              css;
    (muchas lineas más aqui)
}

Bueno ahora, vamos pal DHCP. Por supuesto, nada menos que el mismísimo dnsmasq:

Primero el método DHCP, declaramos una option cuyo código sea 252

option=252,http://10.1.1.1/wpad.dat
También declaramos un puntero DNS, que apunte a wpad.hcg.sld.cu y que sea el servidor donde está el wpad. Le recuerdo que “hcg.sld.cu” es el nombre del dominio. Al reiniciar nginx y dnsmasq, todo debe estar listo…

martes, 9 de septiembre de 2014

proxy padre de infomed

Un sitio donde toda la comunicación más allá del mar, sale a través del  llamado “proxy padre”. Siempre había oído hablar de casos como estos, pero nunca lo había vivido.

Toda la navegacion detrás de infomed, se realiza atreves de un SIN… simpatico proxy padre, que escucha por el puerto 3128.

Drama descomunal! Si en tu proxy local, declaras un proxy padre (en squid: “cache peer”) desembocará directamente en un nuevo problema; y es que entonces las páginas de infomed, NO se ven. Los del nodo no dejan acceder a infomed desde afuera porque eso seria jamarse el ancho de vianda por gusto. Simplemente te sale un html sato, diciendo que debes configurar debidamente tu proxy; haciendo una excepción para las direcciones “*.sld.cu”. Pero por suerte, squid tiene un mecanismo para usar multiples proxies. En este caso, con uno solo basta. Veamos de cerca la configuración.

/etc/squid/squid.conf
1
2
3
4
5
6
7
8
# el proxy padre de infomed
cache_peer 201.220.211.7 parent 3128 0 default
cache_peer_domain 201.220.211.7 !.sld.cu

# infomed no sale a travez del proxy
acl sitios_salud dstdomain .sld.cu
always_direct allow sitios_salud
never_direct allow all
Dividido en silabas pa los mentequita, linea por linea.
2 - declaramos el proxy
3 - decimos que atraves de ese proxy, se usara todo lo que NO sea .sld.cu
6 - los sitios de salud, son aquellos que digan “.sld.cu”
7 - los sitios de salud, van directo (sin proxy)
8 - el resto, no se permite directo (van via proxy)

Problema “resolvido”