[Lista ArNOG] Mikrotik con hotspot
Mariano Absatz - gmail
el.baby en gmail.com
Vie Mayo 5 11:24:00 ART 2017
On 05/05/17 07:36, Marco Appendino wrote:
>
>
>
>
> Hola buen día, tengo un problema que hace unos meses no puedo resolver.
>
> Trabajo con mikrotik, en el cual tengo configurado un hotspot con un
> disclaimer, el mismo tiene cargado un certificado ssl verificado por
> COMODO CA.
>
> El problema se genera cuando los usuarios se conectan a la red
> mediante dispositivos móviles, los cuales trabajan con google chrome y
> la pagina por defecto https://google.com <https://google.com/>.
>
> Antes de acceder a google se redirecciona al hotspot y es aquí donde
> se produce el error. No se muestra la página con el disclaimer.
>
> Si alguien puede ayudarme agradezco su voluntad.
>
Hola Marco.
A priori, tu problema no tiene solución y, salvo que aparezca y se
difunda algún mecanismo de autorización de conexión a una red
inalámbrica mejor que el dichoso "portal cautivo", sospecho que no la
tendrá.
El problema es que el certificado que vos le compraste a COMODO debe ser
para un nombre de dominio tuyo (portalcautivo.epec.com.ar,
wifi.epec.com.ar, ap.epec.com.ar, o lo que sea). Obviamente, ni COMODO,
ni nadie en su sano juicio te daría a vos un certificado para
www.google.com (e igualmente, no te serviría del todo). El asunto es que
vos configuraste un portal cautivo (no importa si con mikrotik, cisco o
lo que sea) que hace que cualquiera que se conecte a tu red e intente
una conexión web caiga en ese portal.
Eso lo logra el mikrotik mintiéndole al cliente con el DNS o con el
ruteo. Es decir, se detecta una conexión nueva en el AP, cualquier
consulta DNS que se reciba a través de esa conexión se le contesta con
la IP del portal cautivo. Alternativamente, cualquier conexión al puerto
80 o 443 a cualquier IP, se la captura y se la rutea al portal cautivo
que contesta como si fuera esa IP (no sé cuál de las dos estrategias usa
mikrotik, pero no importa).
El asunto es que el dispositivo conectado (no importa si es una PC, un
teléfono o una tostadora) cree estar estableciendo una conexión web con
un sitio y en realidad está conectado a tu portal cautivo.
Si no hubiese SSL involucrado, no habría ningún problema. El tipo pone
www.googe.com, el portal cautivo hace de cuenta que es www.google.com y
manda una redirección a la IP (o el nombre) del portal y desde ahí
sigue. El problema cuando usás SSL es que el teléfono (o la PC o la
tostadora) al intentar establecer una conexión segura con www.google.com
(o cualquier otro sitio con https), durante el /handshake/ le pide al
servidor el certificado, cuando tu servidor le manda el certificado que
tiene, el teléfono compara y ve que en el campo CN en lugar de decir
www.google.com dice portalcautivo.epec.com.ar por lo cual supone (y
tiene razón) que el teléfono /no obtuvo/ la página de un servidor
autorizado por Google y lo que hace es informarle eso al usuario.
Eso /debe/ funcionar así.
La única solución es convencer a los usuarios que vayan por las opciones
avanzadas y le "crean" al certificado (no recomendable) o decirles que
visiten una página que NO tenga SSL (cada vez son menos) o, quizás la
mejor opción, decirle que vayan a una página tuya propia (como ser
www.epec.com.ar) de la que, o bien tengas el nombre en el certificado, o
bien vos sepas que no usa SSL.
--
Mariano Absatz
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20170505/9f423efa/attachment-0001.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: no disponible
Type: image/jpeg
Size: 26808 bytes
Desc: no disponible
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20170505/9f423efa/attachment-0001.jpe>
Más información sobre la lista de distribución Lista