En esta ocasión les voy a intentar explicar como configurar un bypass al proxy transparente de IPCop 2 para que las peticiones a ciertos dominios salgan directamente a Internet sin pasar por Squid.
El problema
Como les había comentado en días anteriores cambié mi servidor de de IPCop a IPCop 2. El cambio ocurrió prácticamente sin problemas, pero al poco tiempo me encontré con uno que no fue sencillo de solucionar.
Con el rollo de la facturación electrónica tuve un problema con mi PAC[^1], al momento de intentar timbrar una factura con el programa Microsip me arroja el siguiente error:
Ocurrió la siguiente excepción: Connection lost (error code is 10058)
Durante varios días le estuve dando varias vueltas al asunto. A manera de solución rápida desactivé el proxy y se pudo timbrar sin problemas, primera pista Squid.
Llevo usando Squid durante más de 8 años y es la primera vez que tengo un problema de este tipo, vamos, ni con los horripilantes sistemas del gobierno mexicano desarrollados en Java he tenido tantos problemas por algo tan sencillo.
Investigué en varios foros el origen del problema, al parecer existe una mala combinación entre SOAP,IIS7 y Squid en sus ultimas versiones (actualmente IPCop usa la versión 3.4.4), simplemente no se llevan bien y eso provoca el error de conexión.
En un principio quise agregar una opción a Squid para que se llevaran bien, me refiero a ignore_expect_100 on pero no funcionó, siguió apareciendo exactamente el mismo problema.
Como de momento no se iban a llevar bien mi proxy y el servidor de timbrado y apagar el proxy cada vez que se iba a timbrar una factura no era para nada una solución práctica decidí cambiar el enfoque.
Bypass al proxy.
Sabía lo que tenía que hacer. De alguna forma tenía que configurar IPCop para que al momento de que llegara una petición al dominio del servidor de timbrado, en lugar de que se fuera por la ruta normal (Squid como proxy transparente) saliera directamente a internet sin la intermediación del proxy. Creo que ni yo me entendí… en fin, la idea es esa.
Decirlo es más fácil que hacerlo, al igual que en otras ocasiones supuse que la solución la iba a encontrar con iptables y así fue.
Encontré un artículo que explicaba como hacer esto en IPCop 1.4.12 así que sólo lo tuve que adaptar ligeramente para que funcionara en IPCop 2.
Para lograrlo hay que editar el archivo /etc/rc.d/rc.firewall.local y agregar algunas reglas de iptables.
El archivo esta dividido en 3 secciones, start, stop y reload. Sólo vamos a modificar las dos primeras.
A manera de ejemplo, si el dominio problemático es xyz.com entonces en la sección de start agrego la siguiente línea:
/sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d xyz.com -j ACCEPT
En la sección de stop:
/sbin/iptables -t nat -F CUSTOMPREROUTING
Y la sección reload la dejo tal y como esta.
Al final el archivo completo queda muy similar a este:
#!/bin/sh # Used for private firewall rules # # $Id: rc.firewall.local 1912 2008-09-16 20:11:47Z owes $ # # read variables eval $(/usr/local/bin/readhash /var/ipcop/ethernet/settings) if [ -f /var/ipcop/red/iface ]; then REAL_RED=`cat /var/ipcop/red/iface` fi # See how we were called. case "$1" in start) ## add your 'start' rules here /sbin/iptables -t nat -A CUSTOMPREROUTING -p tcp --dport 80 -d xyz.com -j ACCEPT ;; stop) ## add your 'stop' rules here /sbin/iptables -t nat -F CUSTOMPREROUTING ;; reload) $0 stop $0 start ## add your 'reload' rules here ;; *) echo "Usage: $0 {start|stop|reload}" ;; esac
Guarden el archivo. Para aplicar los cambios, pueden reiniciar el servidor o mediante una conexión ssh ejecutar el script con /etc/rc.d/rc.firewall.local reload
La comprobación
Para averiguar que todo esta funcionando pueden activar los registros del proxy Menú Servicios – Proxy – Configuración de Registros – Registro Activado y luego revisar los registros en el menú Logs – Registros del proxy.
Visite unas tres o cuatro veces el sitio, no deben de aparecer en el registro porque en teoría nunca pasaron por ahí.
Este consejo se puede aplicar tanto en IPCop 1.x como en IPCop 2.x .Espero que este artículo les sea de utilidad.
Referencias
- [^1]:Proveedores Autorizados de Certificación.
- Un problema similar a este soap header authentication fails squid proxy
- IPcop bypass squid for one problem site
amigo muy interesante su solucion, pero la mayoria usa proxy no-transparente. En fin, creo que es mejor crear una ACL y meter ahi las direcciones macs que no van a pasar por el proxy y al principio de iptables antes de cualquier cosa, darle privilegios a esta ACL y santo remedio. Por este tipo de cosas (y otras incompatibilidades) deje de usar IPcop y Zentyal y me pase para Gateproxy
Bueno mi estimado horjuela, cada quien hace lo que puede con lo que tiene, yo no iba a cambiar una configuración que funciona perfectamente por un detallito de Microsoft.
Saludos 🙂
tengo un problema similar pero con squid + shorewall, crees que esto aplique?? saludos
Muy probablemente si.. ya que son proyectos similares, pero no te lo puedo asegurar al 100%.
No pierdes nada con intentarlo.