[Lista ArNOG] Mikrotik con hotspot

Maximiliano Fortuna maximiliano_fortuna en antina.com.ar
Vie Mayo 5 16:31:01 ART 2017


 

Gente, en teoría entiendo que a futuro esto podría quedar totalmente solucionado si se empieza a utilizar el RFC 7710.  Para los que les interese:

 

https://tools.ietf.org/html/rfc7710

 

Slds

 

 

De: lista-bounces en arnog.com.ar [mailto:lista-bounces en arnog.com.ar] En nombre de Mariano Absatz - gmail
Enviado el: viernes, 05 de mayo de 2017 04:07 p.m.
Para: lista en arnog.com.ar
Asunto: Re: [Lista ArNOG] Mikrotik con hotspot

 

¿Eduardo vengo a ser yo? :-P

 

-- 
Mariano Absatz

 

On 05/05/17 15:26, Marco Appendino wrote:

​Gracias a todos por las respuestas, la solución de incluir en Walled Garden IP List ya la había planteado pero buscaba una solución mas radical al problema, y por la forma de trabajar de ssl me temía que no lo había y reafirmo mi postura con la explicación de Eduardo.​


 

¡Error! Nombre de archivo no especificado. 

Ing. Appendino Marco

Centro Operación de Red - NOC

Div. Gestión e Implantación Servicios de Datos

Subgerencia de Infraestructura de Comunicaciones

Empresa Provincial de Energía de Córdoba

Av. Richeri 3850 - X5000EVX - Tel. 54 351 4296492/93


  _____  


De: lista-bounces en arnog.com.ar  <mailto:lista-bounces en arnog.com.ar> <lista-bounces en arnog.com.ar> en nombre de Jose Luque  <mailto:jluque en telered.net.ar> <jluque en telered.net.ar>
Enviado: viernes, 5 de mayo de 2017 12:45
Para: lista en arnog.com.ar
Asunto: Re: [Lista ArNOG] Mikrotik con hotspot 

 

permitile en el "Walled Garden IP List" del Hotspot...

permitile el acceso sin autenticar a "www.google.com.ar <http://www.google.com.ar/> " o la pagina que quieras... (como para no recibir quejas de que el HotSpot esta fucnionando mal) y cuando quieran ingresar a otro portal... salta la solicitud de autenticacion... si en definitiva google solo lo usan para buscar e ingresar a alguna otra pagina...

no se, digo, así lo puse yo... y problema resuelto...

Saludos!





 

--

Jose Luque
Tecnologia y Nuevos Servicios

Imagen quitada por el remitente.
 

 

Email: jluque en telered.net.ar
Tel. +54 (011) 4469.7450 int. 2406
Directo +54 (011) 5171.5153
Av Pte Peron 1783 - San Miguel
Buenos Aires - ARGENTINA
 <http://www.telered.com.ar/> www.telered.com.ar

 

El 5 de mayo de 2017, 11:58, Eduardo Tealdi Saad <eduardots en amc.com.ar> escribió:

Mas clara la explicacion imposible.


 

Un posible parche seria agregar www.google.com <http://www.google.com/>  al wallen-garden y rogar que la segunda pagina que visiten tus usuarios no sea https.

Saludos Eduardo


 


 


  _____  


 


Eduardo Tealdi Saad
Administrador de Red
  
+54 (220) 499-8100 Int.120
+549 (221) 643-4291
eduardots en amc.com.ar

CooperativaMariano Acosta

Cooperativa Mariano Acosta
  
Superi 660 - C.P.: 1723
Mariano Acosta, Bs.As.
+54 (220) 499-8100
www.marianoacosta.coop <http://www.marianoacosta.coop/>  

 

El 5/5/2017 a las 11:24 a. m., Mariano Absatz - gmail escribió:


 

 

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 <http://portalcautivo.epec.com.ar/> , wifi.epec.com.ar <http://wifi.epec.com.ar/> , ap.epec.com.ar <http://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 <http://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 <http://www.googe.com/> , el portal cautivo hace de cuenta que es www.google.com <http://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 <http://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 <http://www.google.com/>  dice portalcautivo.epec.com.ar <http://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 <http://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/c28dd2c0/attachment-0001.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: no disponible
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20170505/c28dd2c0/attachment-0002.jpg>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9193 bytes
Desc: no disponible
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20170505/c28dd2c0/attachment-0001.png>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 26808 bytes
Desc: no disponible
URL: <http://mailmancabase.interdotnet.com.ar/pipermail/lista/attachments/20170505/c28dd2c0/attachment-0003.jpg>


Más información sobre la lista de distribución Lista