Red con portal cautivo y squi
-
Muy buenas tardes a todos. Hace un tiempo que vengo probando pfSense para montar un portal cautivo en una red de un colegio. Ahora que más o menos lo tengo dominado, hay una cosa que no me acaba de salir bien. Os hago un esquema de la red:
Internet –- eth0 Servidor (Squid) eth1 |--- Red (aulas y despachos)
192.168.2.10 |--- eth0 Servidor pfSense eth1 --- Puntos acceso wifiLa idea es que el servidor con pfSense esté en la misma red que la de los ordenadores de las aulas y despachos (supongamos la red 192.168.2.0 y que eth0 de pfsense tiene 192.168.2.20) entonces, meterle una segunda tarjeta al pfSense con ip 192.168.1.3 que vaya a un switch donde solo hayan puntos de acceso wifi y así entrar a la red a traves del portal cautivo de pfSense. El DHCP lo haria en el mismo pfSense pero solo para la red 192.168.3.0 que seria la del wifi (la 192.168.2.0 ya tiene DHCP). Mi problema viene cuando entra en juego el proxy que está en 192.168.2.10. Y no sé como convinar el proxy con pfSense. El proxy no es transparente y está en el puerto 3128. Entonces, si yo en un pc le desactivo lo de usar proxy (en el Internet explorer por ejemplo) me entra vien en 192.168.3.1:8000 (o algo así era) para meter el nombre de usuario y password, y en cuanto me autentica, logicamente no sigue porqué no hay proxy (si luego lo activo a mano, ya está, pero es cutre esta solución, para eso se queda como lo tenemos con una contraseña WEP y ya está). En cambio, si no desactivo lo del proxy en un cliente, nunca me entra en 192.168.3.1:8000 (también es obvio, porqué está buscando a 192.168.2.10 en la red 192.168.3.0 y no existe). Entonces, cual seria la solución? Un ruteo? Alguna regla de firewall? En el pfSense o en el servidor donde corre squid?
Muchas gracias por todo! Un saludo a todos!
Edgard
-
Tengo una estructura similar y, efectivamente, existe el problema.
Y es un poco aquello de qué fue primero, el huevo o la gallina.
Lo que tenemos es:
1. Proxy definido como http://miservidorweb.com/proxy.pac
2. Navegador puesto a http://miservidorweb.comCon esto se intenta ir a la misma IP y el portal cautivo sí aparece. La pega sobreviene cuando el usuario cambia la página por defecto del navegador, pero ya sabe que para validarse tiene que indicar la página web del centro.
Además hacemos que proxy.pac sólo sea accesible desde dentro del Centro, con lo que resulta inocuo cuando los usuarios están fuera de él.
Se me ocurre que igual se podría probar a publicar el proxy para la interfase del portal cautivo, es decir, en 192.168.3.1:3128. Esto se podría hacer con NAT pero la pega es que entonces todos los equipos se verían como 192.168.3.1 en el proxy. No me gusta, mala idea…
-
Gracias bellera. Esta opción la tenia más o menos pensada: hacer que la página de inicio sea la del portal cautivo y luego establecer el proxy automáticamente pero entonces seguiríamos con el problema de que los profesores, si o si tendrian que tocar algo de configuración en sus ordenadores, y eso no es lo que se busca. El poner el wifi (con portal cautivo) es para que los profesores se puedan autenticar sin necesidad de configurar nada, solamente conectando a una red y luego autenticándose con su nombre de usuario y contraseña que les ha dado el colegio. He ido leyendo por internet y he visto algo parecido a lo que comentas del NAT, pero me lo puedes explicar mejor? Porqué dices que no te gusta? Y no seria posible hacer que el proxy sea transparente en la red 192.168.3.0 desviando todo el tráfico del puerto 80 al 3128?
Gracias por todo!
Edgard
-
¡Hola de nuevo!
Aclaro lo del NAT.
NAT significa que un PC detrás de una interfase se ve con la IP de dicha interfase y un puerto dinámico.
O sea que pierdes la traza de la IP real del equipo y del puerto dinámico que esté empleando. Esto es lo que se hace cuando se accede a Internet.
Pero en una red privada, propia, no resulta demasiado conveniente.
Si pones al proxy en modo transparente no tendrás control sobre las URL que sean https. Es decir, perderás todo posible filtro (squidGuard, DansGuardian) de los accesos por https. Esto es porque el navegador inicia la encriptación sin saber que tiene un proxy detrás y no da la URL (puesto que está encriptada). Nada recomendable.
A parte de esto si (en el futuro) deseas implantar usuario/contraseña en la navegación un proxy transparente tampoco lo admite. La explicación es la misma que antes: el navegador no sabe que tiene proxy.
Saludos,
Josep Pujadas
-
Hola bellera. Sería algo como lo que aquí pone?
http://forum.pfsense.org/index.php/topic,15571.0.htmlUn saludo!
edgard
-
Sí, es un tema discutido varias veces y referenciado en Documentación (arriba del todo):
Forzar el uso de squid externo a pfSense
http://forum.pfsense.org/index.php?topic=15571.0
http://forum.pfsense.org/index.php?topic=21083.0 -
bellera, muchas gracias por todo. Una última cosa sobre lo del NAT. Que todos los que esten en la interface de la red 192.168.3.0 se vean como 192.168.3.1, solo tendria como inconveniente que, en caso de que haya mucho tráfico, y que sea de esa red, no saber que equipo es? Es asi? Y me imagino que un equipo de 192.168.3.0 puede acceder a otro equipo de 192.168.2.0 (por ejemplo). Al reves se podria? Por último, no se muy bien como va, pero con el comando route (o el ruteo que traiga pfSense) no seria possible unir las dos redes?
Gracias y un saludo!
Edgard
-
un equipo de 192.168.3.0 puede acceder a otro equipo de 192.168.2.0
Esto depende de las reglas que haya en 192.168.3.0 hacia 192.168.2.0. Si no hay reglas específicas no se ven. Son dos redes privadas y sin reglas no se ven entre ellas.
¿Al reves se podria?
Aplica el mismo razonamiento. Tiene que haber reglas. De lo contrario el tráfico intentará ir siempre por la puerta de enlace. Y si ésta sale a Internet (red pública), el tráfico (con destino red privada) no irá a ningún sitio.
pero con el comando route (o el ruteo que traiga pfSense) no seria possible unir las dos redes?
Si repasas el tutorial que hay en Documentación verás que los principios básicos son: cada interfase tiene su rango de IPs y jamás hay que indicar rutas entre éllas.
La respuesta es pues No. Las redes quedan unidas cuando das permisos de ir de una a la otra. Esto es una gran ventaja porque eres tú quien decide qué puede pasar de una a otra. Repasa el tutorial, es de hace 4 años pero sigue siendo lo mismo. Y es un centro educativo con varias LAN y WAN.