Buenas @JoanRomeroRueda
En el escenario de la ONT, no tiene ningún sentido sacar más de un cable de ella, por el primero ya va todo el tráfico, tanto IPTV, Internet como VoIP. Por eso no funciona, tanto la ONT como el Router tienen un Switch, no un Hub, el tráfico que llega no se replica a todos los puertos, el UDM ya está recibiendo TODO por el mismo puerto al que esté conectado. Quizás el problema es que usamos mal (yo el primero) el término WAN, y a veces nos referimos a él como el puerto que está "de cara" a Internet, otras veces como el puerto ascendente, otras veces Interfaz de X... Es bastante más simple que todo ello... y perdón por el tocho.
El Router tiene una serie de puertos físicos Ethernet que podemos ver, que sean usados para dispositivos LAN o como puertos para conectar a una (o varias) WAN es indiferente, depende de la configuración de cada Router por el fabricante, pero a fin de cuenta lo que hay dentro es un Switch conectado al SoC del Router. Internamente por otro lado los Router, por lo general crea un bridge entre todos los puertos Ethernet LAN y también si hay WIFI pone en el mismo bridge las redes WIFI. De este modo todos los dispositivos conectados al Router pueden "verse" e interaccionar. Ojo que los Router pueden tener otros puertos o interfaces físicas reales internos que no podemos ver, pero están ahí.
Pero podemos crear interfaces virtuales, sujetas o no a otras interfaces a su vez. Y entre ellas pues están las interfaces etiquetadas, o incluso las propias conexiones PPPoE. Los HGU simplemente crean al menos 3 interfaces virtuales adicionales, una por cada servicio, y configura cada una pues para cada servicio. Si te das cuenta nadie ha hablado aun de puerto o interfaz WAN. ¿Que pasa? Que algunas interfaces están asociadas a otras o a otros puertos físicos. Cuando levantamos una sesión PPPoE la levantamos sobre un puerto concreto, por ejemplo en el HGU Mitrastar es el puerto interno que conecta la fibra con el Router, gpon0. En el caso del HGU no lo vemos porque posee una ONT integrada, pero podemos imaginar que es similar a una ONT independiente conectada al puerto WAN de tu Router. que en el tuyo a lo mejor es el puerto Eth0... en mi Router propio es por ejemplo Eth4. Pero realmente no estamos usando directamente ese puerto, sino la interfaz PPPoE que se ha creado levantada en dicho puerto/interface, en el caso de este HGU pues sería ppp0.1.
La cuestión importante es que NO ETIQUETAMOS el puerto gpon0/eth0/eth4... , lo que etiquetamos es la interfaz virtual creada, que a la vez usa dicho puerto. Y esta es la madre del cordero, porque nosotros podemos seguir usando el puerto WAN para comunicarnos con lo que esté más arriba, el tráfico que pasamos directamente por él no se etiqueta, ni viene etiquetado, se etiqueta y viene etiquetado lo que pasa por las interfaces virtuales creadas, con independencia de que usen el mismo puerto para ello.
Esto hace posible realmente que podamos hacer lo que queramos.
Por ejemplo, queremos gestionar todas las VLAN? Da igual no estamos limitados por puertos físicos, podemos crear las interfaces virtuales que queramos, aunque todas ellas usen el mismo puerto. Otra cosa diferente es que el software del Router que uses tenga dicha posibilidad, ya sea por interfaz Web o Shell. Esto nos permite que, si gestionamos todas las VLAN nosotros, como te digo, podemos conectar lo que queramos a cualquier puerto físico, por WIFI... no hay limitación, todo funciona correctamente, porque las rutas se encargan de enviar el tráfico a una interfaz o a otra.
Esto también permite por ejemplo el modo monopuesto de los HGU. No es un bridge real, es más bien un "medio-bidge". Si fuese un bridge real, el HGU pondría en el bridge principal igualmente el puerto gpon0... o si lo quieres ver como si fuese tu propio Router, sería como poner en bridge tu puerto WAN... es decir, tratar WAN como si fuese otro puerto más LAN. Eso es un bridge real. En monopuesto no se hace eso. Lo que se hace es simplemente eliminar la conexión PPPoE, pero se deja igualmente la interfaz virtual etiquetada con 6, y es sólo esa interfaz virtual la que se pone en el bridge principal, en la que están pues el resto de puertos LAN y WIFI. De nuevo aquí no hay intervención alguna de WAN, El HGU sigue teniendo las otras dos interfaces virtuales para IPTV y VoIP configuradas, pero estas NO ESTÁN en el bridge principal... pero ojo, el bridge principal PUEDE ACCEDER A DICHOS SERVICIOS. Es un modo realmente inteligente por parte de Movistar para facilitar la tarea y evitar tener que lidiar con VLAN.
Y todo este chorizo que tiene que ver? Simple.
Si usamos una ONT e inyectamos TODO a nuestro Router, aunque se pueden hacer malabares para intentar sortear problemas del Router que tengamos o limitaciones que el fabricante nos imponga, el modo a operar es ese, crear las interfaces necesarias, obviamente asociadas estas al puerto WAN al que está conectada la ONT (repito no se etiqueta el puerto WAN, se etiquetan las interfaces virtuales creadas (aka interfaces WAN). Quizás el problema aquí es que UDM no permite crear por interfaz Web ( no sé si lo permitirá por Shell) interfaces virtuales arbitrarias, etiquetadas y levantadas a su vez al puerto WAN que se quiera. Esto ya no te lo puedo decir, repito no tengo un UDM.
Y si usamos el HGU en monopuesto, con todo lo explicado anteriormente se entiende también todo. No se trata de ir tirando diferentes cables. En este escenario el Router propio no tiene que lidiar con VLAN, puesto que el HGU tiene en bridge el tráfico de Internet sin etiquetar. Pero repito que en realidad es lo mismo que si hubiese estado etiquetado, tenemos tráfico que entra por un puerto físico WAN, y en nuestro Router creamos una interfaz virtual PPPoE que se levanta sobre ese puerto físico WAN, imaginemos por ejemplo que el puerto WAN es eth4. Pero en este caso pues no se etiqueta. Pero exactamente igual que pasaba con el puerto interno gpon0 del HGU, que usemos para conectarnos a Internet la interfaz PPPoE en el Router no significa que eso nos niegue el poder usar directamente el puerto eth4 del Router para acceder al HGU.
Una cosa es una interfaz virtual que hace uso obviamente de un puerto físico. Otra cosa es que el propio puerto físico también se puede usar. Del mismo modo que también puede existir otra interfaz virtual haciendo uso también del mismo puerto físico. Y todo ello es complementario, no excluyente. Así pues, no necesitamos conectar más cables de un lado para otro, si tenemos ya un cable que va del HGU al Router propio, tenemos más que de sobra para tener acceso a todo, a fin de cuentas nuestro Router está conectado ya al HGU, ¿para que volverlo a conectar? Es buscarse más problemas, producir bucles...
Si usamos el HGU en monopuesto y queremos acceder a otros servicios desde nuestro Router, simplemente se requieren algunas rutas para que el Router sepa que no lo tiene que enviar por PPPoE, sino pro nuestra física Eth4 (que henos puesto de ejemplo) y que se enmascare el tráfico que sube a la otra red, nada más. Es cierto que las peculiaridades de la IPTV de Movistar pues requieren algunos pasos adicionales, como es un servidor DNS específico y por supuesto una correcta configuración de IGMP, puesto que hay que lidiar con tráfico Multicast (IMPORTANTE). Pero todo esto es secundario, no tiene nada que ver con lo que es la configuración de las diferentes redes/interfaces.
En tu caso particular, si he entendido bien, haces una ñapa para el deco, dedicar un puerto para ello crear una VLAN... pues seguramente lo que has hecho ha sido ni más ni menos que aislar al propio Deco, y por ende hay muchas cosas en el Deco que no funcionan... que el tráfico Multicast fluya es sencillo, por lo general con IGMP Proxy y rutas es suficiente, pero el tráfico unicast es otro cantar, y si encima has aislado el Deco, pues más problemas.
Enmascarar el tráfico es algo así como hacer un SNAT, pero no es lo mismo. Cuando un Router hace SNAT lo que hace es modificar al vuelo la IP de origen de un paquete, cuando hace DNAT lo que modifica es la dirección de destino. Cando una interfaz enmascara el tráfico lo que hace es modificar al vuelo la IP de origen del paquete por la IP de la propia interfaz que está enmascarando, tiene alguna peculiaridad más que SNAT, pero no viene ahora a cuento. Así simplemente se envía el tráfico a la red del HGU a través de la interfaz física WAN, no va por PPPoE ni hace falta otro cable ni historias raras.
Con la configuración del servidor DHCP me refiero a que todos los dispositivos de la red por lo general hacen uso de un servidor DHCP en el Router para configurarse en la red. El Deco también, solo que en este caso particular requiere un servidor DNS específico que es sólo alcanzable desde la interfaz IPTV, ese servidor DNS no puede usarse desde Internet. Volvemos a lo mismo, ñapas que cada cual puede aventurarse. Para poder resolver algunas DNS, el Deco requiere de este servidor DNS. El modo correcto de hacerlo es configurar el servidor DHCP del Router, el que usa para todos los dispositivos conectados a él, para que lo tenga en cuenta. El Servidor DHCP del Rotuer es el que asigna los datos IP, máscara de red, puerta de enlace, dns, y otros. Algunos usuarios en sus Router, ya sean por limitaciones o por la razón que sean hacen cosas raras de estas, como configurar el deco manualmente. Cuando de nuevo es mucho más simple que todo eso, no hay que hacer distinción de nada, para tu red local un Deco no debería de ser en absoluto diferente a un PC o a un Móvil, ni tener asignado un puerto concreto. El mismo servidor DHCP del Router se encarga en este caso simplemente de asignar un servidor DNS diferente si detecta que es un Deco, tal como suena.
Por desgracia, y esto lo hemos hablado aquí muchas veces, el problema tiene muchas vertientes. La teoría es muy sencilla, de verdad, la práctica no... pero no porque sea "complejo", sino porque ponerlo en práctica depende fundamentalmente del hardware que cada uno haya adquirido, del software que cada fabricante le haya metido dentro, de si el fabricante permite o no permite ciertas cuestiones por Interfaz Web o por Shell, y para rematar si el usuario entiende realmente, o al menos más o menos, que es lo que tiene que hacer y como funcionan las cosas. Y cuando pones todo eso en un sacos, pues te das cuenta que lo que tienes es un foro lleno de problemas similares.
Existe una infinidad de Router/Firewall que los usuarios quieren usar, no puedes jamás asegurar que un dispositivo concreto, marca X modelo Y y firmware versión Z, va a poder hacerlo funcionar de forma correcta con total seguridad a menos que uno lo haya tenido previamente y ajustado correctamente para ello. Yo no te puedo asegurar que con el UDM que tienes pueda dejarlo perfectamente como se debería de dejar, ni siquiera te puedo asegurar que se pueda de alguna manera. Y ojo, que a lo mejor se puede configurar perfectamente y de la forma correcta y óptima!! Pero es imposible saberlo, como mucho alguno que tenga uno y lo haya podido hacer funcionar, te podrá decir como lo ha hecho funcionar él, que tampoco significará a lo mejor que sea del modo correcto.
Y digo modo correcto por lo que te he dicho antes, hay muchas formas de intentar solventar las limitaciones que el fabricante te impone, ya sea por el hardware o por el software. El problema es que generalmente son rodeos o "parches" que implican a la larga otros problemas, o estructuras de red que no son eficientes o propensas a fallar. Y esto es el pan nuestro de cada día aquí. Por ejemplo mira lo que dices que te estás peleando de tal modo de conectar el HGU o la ONT con dos cables diferente a tu propio Router. Recuerdo hace unas semanas a un usuario que para dar Internet al HGU en monopuesto también lió una buena retroalimentando al HGU con su propio Router, pero siempre para lo mismo, es decir, solventar problemas o limitaciones que uno tiene (por software, hardware, conocimientos) de forma bastante cogida con pinzas.
Y es un asunto que al final uno termina quemado, porque si dices que el problema es que el usuario en particular no tiene los conocimientos necesarios y se está metiendo en un asunto que no controla, te pueden prender fuego, y es más, te acusan de que es que no quieres ayudar... O si dices que a lo mejor el hardware usado no es el más adecuado para dicho usuario te pueden prender fuego de nuevo, y es obvio, quien es uno para decir que es adecuado o no... sobre todo cuando son dispositivos que no son algunos nada baratos. No sé que móvil tienes, pero puedes hacer la prueba... dile a un usuario de iPhone o Samsung S2X+ que se han gastado más de 1000€ que casi con total seguridad con una probabilidad del 99% (a quien sea) se han comprado el terminal equivocado, es decir, el dispositivo que mejor se adaptaba a sus necesidades reales. Pues esto es igual... vas a la hoguera... y sí, me suelen quemar de vez en cuando por eso de no ser políticamente correcto 😉
-------------------
El problema de base como ya te he dicho es que se parte ya sea de una idea equivocada o que simplemente el equipo que se tiene no permite configurarse de dicho modo. En tu configuración o idea basas todo en que el deco es diferente a un PC, y no es así. En una configuración adecuada todo está conectado del mismo modo al Router. Lo único que dictamina una cosa u otra son unas pocas rutas, nada más. Existe un sólo servidor DHCP que asigna como cualquier servidor DHCP las IPs y datos de configuración al resto de equipos, incluyendo por supuesto cualquier deco que se conecte, sea uno, dos o los que se quieran.
Si se está en monopuesto, en el Router propio tampoco hay VLAN en ningún lado, solo hay una interfaz PPPoE que obviamente hay que levantar para tener Internet, una ruta por defecto que da servicio a Internet obviamente, 5-6 rutas para VoIP/IPTV , el bridge principal del Router donde están los puertos Ethernet LAN y WIFI (por lo general) y bueno... como he dicho pues sí, hay que configurar correctamente IGMP porque el tráfico Multicast es problemático y te puede dejar KO la red entera. Claro que se puede complicar todo lo que uno quiera, pero eso solo te lleva a más problemas que tendrás que ir solucionando de otros modos también poco recomendados que a su vez darán otros problemas... y que además ante cualquier cambio de Movistar también todo se puede venir abajo.
Y repito, que puede ser tanto que sea imposible de hacerlo de otro modo porque el fabricante lo ha hecho así, puede ser que se pueda hacer de forma correcta simplemente tocando aquí o allí o creando un simple script de inicialización... pero ya hemos hablado de eso, y dado que eso es harina de otro costal pues...
Saludos.
Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
