Cambiar router HGU por neutro
Buenas tardes, Desde hace un tiempo estoy experimentando en mi HGU cortes en la red que solo se resuelven reiniciando el router para volver a la normalidad. En vista de que si reclamo a Movistar ...
Foro
Hola aleph20
gracias por los comentarios, son siempre bien recibidos. Te respondo a cada una de las cosas que comentas:
1) Ese valor de la OPCH me da que lo tiene preestablecido el deco porque ya me lo tiene fijado así.
2) El deco efectivamente me funciona conectado al ASUS directamente. A mi también me extrañó que no tuviera que hacerle nada, no se si como dices el IGMP proxy ya lo resuelve. En cualquier caso gracias por el comentario porque me servirá para la configuración con OpenWRT que aún no la tengo funcionando.
3) Tienes toda la razón está mal, pero efectivamente fue una errata. La configuración que tengo es 255.255.128.0 en efecto.
Hola de nuevo,
después de tener todo funcionando con el ASUS procedí a migrar el setup a un tp-link que tengo con OpenWRT. Replicar la configuración fue bastante sencillo y cosas que en el ASUS no podía hacer, como DNS condicional son sencillas en OpenWRT.
El caso es que aún cuando el setup es en principio el mismo, la TV no me funcionaba. Revisé lo típico de hacer MASQUERADE, los DNS, las rutas 172.x.x.x etc.. pero todo parecía estar en regla. Las tablas de enrutamiento son idénticas en el ASUS y el OpenWRT. Podría haber temas de firewall ya que ahí es dificil de comparar, no se decirlo. Ya desesperado traté de descartar algún tema en el deco. Lo que hice fue lo siguiente:
- montar el ASUS de nuevo y conectar el Deco, todo va perfectamente.
- el ASUS y el otro router tienen configurada la misma LAN y el deco una IP estatica de esa LAN (para esta prueba, no es el setup definitivo)
- "en caliente" cambio los cables del HGU y del deco del ASUS al router con OpenWRT
Entonces para mi sorpresa todo funciona. Luego si reinicio todos los equipos vuelve a fallar, pero el caso es que si me conecto incialmente con el ASUS y luego cambio al OpenWRT de alguna manera funcionan las cosas.
Ideas que se me ocurren:
- El DNS está mal en OpenWRT y no resuelve bien. El deco ya hizo la resolución mientras estaba conectado al ASUS y luego simplemente usa la cache con lo cual no importa que no tenga acceso a los DNS internos. Suena plausible, pero comandos como dig @172.26.23.3 google.com funcionan perfectamente para cualquier equipo conectado al OpenWRT.
- Algún tema de seguridad. En concreto lo que hice fue inspeccionar el trafico del deco mientras estaba conectado al OpenWRT con wireshark y cuando se intenta conectar a main.acs.telefonica.net obtengo un error de TLS1.2 de certificado inválido. Se me ocurren dos cosas, una que el OpenWRT tiene CAs antiguos (improbable estoy usando una version reciente) o 2 el ASUS es más laxo con las comprobaciones y admite el certificado como valido. De todas maneras no se si la conexion a ese equipo es importante.
- Alguna otra mala configuración y que el deco sea capaz de mantener las conexiones abiertas a pesar del cambio de cables?
Hola,
al final ya lo tengo todo funcionando (no perfectamente eso si) en OpenWRT. Ahora entiendo porque Theliel o aleph20 repiten las mismas cosas una y otra vez 😀, si es que en un A-B-C: DNS, rutas, masquerade
Digo no perfectamente, porque me ocurre una cosa extraña. Algunos poquísimos canales, #Vamos por ejemplo no se llegan a ver bien, demasiado pixeleado y con cortes, como pasa cuando no tienes ancho de banda suficiente. También he visto que otros canales no se cortan pero la calidad no es la que debería ser. Los mismos contenidos en la app de Movistar+ de mi TV se ven mucho mejor (conectada al mismo router). Supongo que tendré algún tema raro en la configuración como un doble NAT o algo del estilo que pueda afectar al rendimiento.
Por cierto, por si sirve de referencia a alguien, tenía dos cosas mal:
- El proxy IGMP. Lo tenía configurado, pero de forma errónea. Hay que seleccionar un tráfico upstream y un downstream. El dowstream es la lan y era correcto pero en el upstream tenia seleccionada la interfaz PPoE y ahí estaba el error. Cambiado por la interfaz al HGU y todo bien.
- Luego está el tema archicomentado de hacer masquerade del tráfico que va al HGU. No lo tenía bien configurado con iptables. Que por cierto en OpenWRT se puede hacer en el interfaz gráfico en Firewall->NAT rules.
Por si a alguien le vale, es muy interesante este post que aunque ya viejo, es muy interesante sobre todo la parte de Resolución de problemas. Por ejemplo, no se me había occurido lanzar el demonio IGMP en primer plano, al hacerlo me di cuenta enseguida que estaba mal configurado (no actualizaba rutas), en cuanto lo cambié ya vi como me iba añadiendo más rutas inmediatamente.
Buenas svillar
-En lo relativo a las resoluciones DNS, si resuelve, resuelve
-En lo relativo al host main.acs.telefonica.net, hay diferentes "conexiones" que realiza un deco hacia Movistar, pero no significa que todos ellos sean necesario. En cualquier caso creo que estás confundiendo lo que estás viendo ahí. OpenWRT no es el que conecta a dicho dominio, sino el Deco. Las conexiones son punto a punto, con lo que a menos que OpenWRT esté interceptando las conexiones SSL/TLS, da exactamente igual los certificados que tenga o no tenga, es una cuestión exclusiva del Deco con el servidor remoto. La misma analogía sucede cuando un equipo de tu red local accede a cualquier web https, tu Router no tiene nada que decir ahí, a menos que repito esté actuando interceptando el tráfico, que no es el caso. Por otro lado y para cerrar aun más el asunto, el dominio en cuestión no impediría ver la tele, dicho servicio se usa para la gestión remota del Deco. El motivo por el cual la conexión se rechaza es por una de estas dos razones, o las dos:
1º. Efectivamente el Router está interceptando las conexiones e inyectando su propio certificado.
2º. El host en cuestión usa un certificado propio no reconocido universalmente, con lo que si el cliente TR069 del deco aplica una regla estricta sobre ello y no posee internamente el CA que emitió el certificado, abortará la conexión.
-----------
Sin tener el dispositivo delante y poder acceder internamente a él, es imposible saber que pueda estar pasando. Si el Router permite un control adecuado, en principio da igual el que sea, se puede configurar sin problema siempre que cuente con las utilidades/demonios necesarios. Hace ya algún tiempo la verdad que no toco OpenWRT, pero no veo ningún tipo de motivo por el cual no pueda funcionar.
Partiendo de que la conexión PPPoE la establece correctamente, el resto es lo mismo, los tres pasos básicos:
1º. Asignar datos IP a la interfaz WAN a la que se conecta, que sean coincidentes como es natural dentro de la red del HGU, no a la interfaz PPPoE. Esto es necesario para que el tráfico que entra en el HGU, una vez enmascarado, para el HGU vendrá de su propia red local, y el Router propio sabrá también hacia donde enviarlo.
2º. Enmascarar el tráfico que sube, para que el HGU lo vea como tráfico de su propia red
3º. Rutas pertinentes, servidor DNS condicional.
-----------------------------------
Pasos dependiendo de internamente como esté preconfigurado el Router, pero que son habituales causar problemas. Me temo que para poder verificarlos es necesario como he dicho ver y comprobar internamente algunos ajustes y parámetros. Algunas de estas cuestiones pueden ser "automáticas" en el Router que sea o no, y requieren ser especificadas de forma concreta:
4º. Asegurarse de tener habilitado no solo IGMP Snooping, sino IGMP Proxy, sin él, el tráfico Multicast es más que probable que no baje
5º. En la misma línea que lo anterior, el tráfico IGMP debe de tener permitido alcanzar al Router, por defecto el tráfico entrante al Router es filtrado, con lo que se hace necesario asegurarse que fluya bien. Ya sea creando una regla para permitir específicamente IGMP, o incluso para permitir todo el tráfico que venga del HGU
6º. Tener cuidado con el TTL, es otro problema habitual que la mayoría toma como "imposible de diagnosticar". Si un paquete de datos, el que sea, al decrementarlo el dispositivo de red llega a cero, el paquete se descarta. Dependiendo de como nos envíe el servidor de arriba los paquetes de datos, puede ser necesario modificar el TTL. Es algo habitual que suceda, porque de base no está planteado que exista algún salto adicional en la red, y llegan ya con TTL 1, al entrar en el siguiente...
Pues vaya, svillar . La verdad es que nunca he trasteado con OpenWRT así que poco puedo decirte sobre su configuración. De todas formas supongo que será lo de siempre, dnsmasq, iptables, route o ip route..., muy similar a lo que has hecho en el ASUS. Solo me atrevo a sugerir a bote pronto (y a ciegas) algunas minucias que podrías volver a comprobar, por si suena la flauta.
Por lo que cuentas parece claro que el ASUS hace "algo" que la configuración de OpenWRT no replica. (Esto es lo fácil; lo difícil es saber qué ;-). Por si acaso tuviera algún efecto raro decirte que sospecho que la ruta 172.26.0.0/17 no abarca todas las rutas para IPTV que tiene el HGU. En mi Mitrastar quedan fuera dos: 10.128.0.0/9 y 172.23.96.0/21, máscaras 255.128.0.0 y 255.255.248.0 ("Device Info --> Route"). No sé si esto es muy importante y además es raro que el ASUS funcione sin ellas y el OWRT no, pero nunca se sabe y podría arreglar problemas que se presenten más adelante.
Yo comprobaría también la configuración DNS de OWRT, no vaya a ser que haga cosas "avanzadas" y le de por filtrar las conexiones al puerto 53 y reemplazarlas por sus propios DNS (Asus-Merlin tiene una opción llamada DNSFilter que hace precisamente eso y que en tiempos me causo problemas con el servidor DNS condicional de IPTV). Ya que estamos no me queda claro si tienes activo dicho servidor condicional (¿dnsmasq.conf?); en tal caso puedes probar que el deco lo reciba, junto con la opción 240, por DHCP.
También repasaría la tabla "nat" de iptables, en particular la cadena POSTROUTING, y las cadenas INPUT y FORWARD de la tabla "filter". Algo así como:
iptables -t nat -L POSTROUTING -vY algo "Off Topic" para terminar. Tenías razón, en el ASUS (no sé si con OWRT) no hace falta crear manualmente una regla que enmascare el tráfico que sube por wan_iface para que el deco funcione, ¡ya lo hace el propio ASUS!, cosa que yo no había comprobado hasta que tú lo mencionaste.
Y ya sabes: siempre nos quedará Theliel .
Suerte con los bichos
