Estoy intentando configurar un sistema de autenticación para WiFi doméstico que sea independiente del punto de acceso/enrutador que se esté utilizando. Este sistema de autenticación seguirá de cerca el modelo del portal cautivo, pero no creo que los detalles del portal cautivo (personalizado) sean importantes.
Para lograr esto, me gustaría alojar el portal cautivo y la autenticación en un dispositivo económico (como una Raspberry Pi). Sin embargo, después de autenticarse, me gustaría que los usuarios se volvieran a conectar a un punto de acceso diferente. Es decir, la Raspberry Pisolorealizar el paso de autenticación, pero no actuaría como punto de acceso de uso normal para usuarios autenticados. Nuevamente, de manera óptima esto funcionaría con cualquier punto de acceso/enrutador que tenga una red WiFi normal protegida con contraseña.
Aquí está el flujo de inicio de sesión deseado para este proyecto:
- El usuario se conecta a la Raspberry Pi habilitada para WiFi
- El usuario es dirigido a un sitio de portal cautivo alojado en Pi e inicia sesión
- (Suponiendo que la autenticación sea exitosa) El usuario está desconectado de Pi y conectado al punto de acceso principal
- El usuario ahora puede navegar por la web con normalidad.
¿Existe algún método para lograr este tipo de cosas? Sé cómo configurar una Raspberry Pi para que actúe comoambosel punto de acceso y el portal cautivo, pero no solo como el portal cautivo.
Respuesta1
Realmente no es factible hacerlo de forma segura, aunque puede ser posible utilizando una disposición tipo 'Rube Goldberg'.
Supongo que se podría hacer, de manera tosca, personalizando un enrutador DHCP en el PI y proporcionando un breve tiempo de concesión hasta su lanzamiento, y modificando la dirección IP entregada (y no habilitando DHCP en el enrutador), pero entonces tendrías una enorme batalla para garantizar que esto no se pueda evitar con un simple direccionamiento estático.
Es posible que pueda lograr en gran medida algo similar con la cooperación del enrutador para no permitir el puerto DNS (solicitudes de puerto 53) en la WAN desde cualquier dispositivo que no sea el portal cautivo, y entregar el DNS del portal cautivo con DHCP, y tener el portal cautivo proporciona respuestas DNS por sí mismo hasta que se libera al usuario. Sin embargo, esto podría subvertirse con una simple VPN o túnel.
Es mucho más difícil de lo que parece (algo con lo que juego en mi tiempo libre, ¡así que no mucho!), pero dependiendo de tu enrutador, sería algo así como "Wild Dog", que está integrado en las versiones modernas de DD-WRT. - funciona para usted: parece que el enrutador realiza la captura subyacente y transfiere el trabajo del portal a otro dispositivo.
Respuesta2
Dado que OpenBSD se ejecuta en Raspberry Pi, puede usar authpf para permitir que cada usuario autentique su sesión con clave pública/contraseña, y permitir que dichos clientes autenticados pasen a través del firewall; sin embargo, realmente funciona mejor directamente en el enrutador responsable del filtrado. Verhttps://www.openbsd.org/faq/pf/authpf.htmly google para ver ejemplos de implementaciones.
Una opción más fácil de usar es algo comohttps://coova.github.io/CoovaChilli/ Parece recibir mantenimiento activo y cuenta con soporte RADIUS.
Respuesta3
Nuevamente, de manera óptima esto funcionaría con cualquier punto de acceso/enrutador.
Los puntos de acceso manejan Wi-Fi (capa de enlace), los enrutadores manejan IP (capa de red). Aunque a menudo se combinan en una sola caja de plástico, siguen realizando dos funciones distintas.
Entonces, la idea de los portales cautivos es que un dispositivo a lo largo de la ruta normal de los paquetes los intercepte y genere una respuesta de "redireccionamiento" falsa, que le dice al usuario que debe visitar la página de inicio de sesión. La redirección podría realizarse mediante:
- la puerta de enlace predeterminada (enrutador), interceptando toda la conexión TCP utilizando iptables (el método más común);
- el servidor DNS, al devolver respuestas de búsqueda de DNS falsas que apuntan al servidor "cautivo" (poco confiable y muy fácil de eludir);
- el punto de acceso o conmutador, reescribiendo los encabezados de los paquetes para que el paquete llegue a una puerta de enlace diferente (muy raropero técnicamente posible)…
En cualquier caso, su "portal cautivo" Raspberrytienepara ser insertado en el camino regular. Incluso si lo construye utilizando el método del "servidor DNS falso" (que maneja muy poco tráfico, pero también es muy fácil de evitar),como mínimonecesitarás reconfigurar el enrutador principal para proporcionar la dirección IP de tu Raspberry a través de DHCP.
(Y muchos enrutadores inalámbricos baratos en realidad no le permitenconfigurareso: supongo que tendrías que desactivar el servicio DHCP normal y servir DHCP completamente desde Raspberry también).
En resumen, no, no creo que sea posible implementar un dispositivo de portal cautivo "plug and play" de esta manera.
De hecho, tiene problemas importantes desde el punto de vista de la seguridad. Si seeranEs posible que una Raspberry Pi simplemente se conecte y de alguna manera intercepte el tráfico de todos, sin configuración de enrutador... entonces también sería posible que cualquier cliente fraudulento con malware simplemente se conectara e interceptara el tráfico de todos.