Hola.
Lo siento, no conozco ninguna forma de configurar un portal cautivo sin algún hardware requerido. Además, debo advertirle que han pasado 13 años desde que hice esto. Mi jefe se acercó a mí y me describió la funcionalidad que vio en una conferencia tecnológica y jugué con ella hasta que la puse a trabajar. Aquí es, a lo mejor de mi recuerdo, lo que se me ocurrió.
Tenía un servidor Linux con BIND y Apache instalados, dos NIC e IPtables habilitados. (Creo que también activé la opción syscntrl IPv4_forw, no estoy 100% seguro) La NIC “interna” se conectó mediante un cable cruzado al punto de acceso inalámbrico. La NIC “externa” se conectó a la red de Internet no confiable. La puerta de enlace predeterminada del servidor se configuró para el enrutador de Internet no confiable. DHCPD se configuró para servir un rango de IP 192.168.0.2-7.253 / 21 a la red interna con el servidor DNS y Gateway como la IP interna del servidor Linux. El tiempo de arrendamiento se estableció en 8 horas.
- ¿Cuáles son algunas de las ventajas de Li-Fi sobre Wi-Fi?
- Soporte técnico: cuando el Internet de mi casa deja de funcionar, ¿por qué ayuda cambiar el puerto Ethernet?
- Cómo encontrar su red WiFi doméstica y SSID
- Cómo arreglar 'La conexión no es privada
- Cada vez que permito que Ubuntu instale actualizaciones, tengo que reinstalar mis controladores de GPU para que CUDA funcione, y tengo que reparar de manera similar mis controladores WiFi. Hay alguna manera de evitar esto?
Bind se configuró para resolución recursiva a través de sugerencias de raíz solo para la red interna y para escuchar solo a la red interna.
Apache se configuró para responder a una solicitud de 192.168.0.1/eula.php para mostrar un mensaje de EULA y un botón de aceptar. Al hacer clic en el botón Aceptar, se PUBLICÓ la IP del usuario a 192.168.0.1/accept.php. accept.php envió la IP del usuario como el nombre de un archivo vacío en un directorio específico, agradeció al usuario, hizo una pausa durante cinco segundos y lo redirigió a la página que había solicitado originalmente. La pieza final de la configuración de apache fue una redirección 302 mod-rewrite para todo el tráfico http y https que no coincide con 192.168.0.1/eula.php.
Reglas de Iptables: Esta es la parte de la que estaba particularmente orgulloso. Tomé prestada esta idea de un proxy transparente de calamar.
En la cadena de enrutamiento previo, cualquier tráfico con una fuente del servidor Linux se permitía a la cadena ACCEPT.
(¡Aquí está la magia!)
Cualquier tráfico de una IP en la lista de archivos vacíos fue permitido a la cadena ACEPTAR.
Cualquier tráfico al puerto 80 no a la IP 192.168.0.1 fue –REDIRECTO a 192.168.0.1
Cualquier tráfico al puerto 443 no a la IP 192.168.0.1 era –REDIRECTO a 192.168.0.1
Cualquier tráfico al puerto 53 no a la IP 192.168.0.1 fue –REDIRECTO a 192.168.0.1
En la cadena de postrouting
Cualquier tráfico de la IP externa de la caja de Linux se envió a ACEPTAR
Cualquier otro tráfico fue enmascarado.
Crear dinámicamente las reglas de IPtables.
Escribí un script de shell que se repitió continuamente. En cada bucle, tomó la lista de archivos en el directorio de salida de eula y usó sed para crear las reglas de iptables como un archivo en / tmp llamado iptables.new. Difundí este archivo contra /tmp/iptables.old y si no coincidía, apliqué las nuevas reglas (sin –flush!) Y mv iptables.new iptables.old.
La última pieza aquí fue un trabajo cron que se ejecutaba cada 5 minutos para eliminar los archivos vacíos de más de 8 horas.
No recuerdo el comando exacto que usé, pero esto debería estar bastante cerca.
find / tmp / iplist -maxdepth 1 -mmin +480 -type f | xargs rm -f
Estoy seguro de que esta tecnología ha evolucionado significativamente en los últimos 10 años y ahora tiene que haber una manera más fácil. Así es como lo puse a trabajar a principios de la década de 2000, una época de cuchillos de piedra tecnológicos y garras de oso.
Aclamaciones.
