[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