Teamviewer y HGU

Jesmo
Yo probé el VDSL
Teamviewer y HGU
Hola Después de mirar por el foro a ver si existe un problema parecido al que  tengo y no localizar nada, escribo este tema. El problema viene desde que cambié de linea de cobre a fibra; antes usaba un router Zyxel y ahora uno de Movistar, un HGU fibra de Mistrastar. No puedo usar Teamviewer  con este router de fibra desde el exterior, solo desde dentro de la red, incluso a través de wifi. Supongo que habría que abrir algún puerto, algo que no entiendo con este programa, pero después de intentarlo con varios no consigo acceder desde fuera. ¿Hay que realizaren el router alguna configuración para usar Teamviewer?. Saludos
Mensaje 1 de 56
4.599 Visitas
55 RESPUESTAS 55
Jesmo
Yo probé el VDSL

Hola

 

No, No esta resuelto el problema.

 

Las pruebas son penosas, tengo que aprovechar "alejarme" del ordenador, para hacer pruebas, tanto desde otro ordenador con linea fija, como por 3G, es por eso que no comento mas a menudo.

 

Saludos

Mensaje 26 de 56
2.724 Visitas
JulioC-Movistar
Antiguo Moderador

Ok, lo dejo abierto, aunque tras verificar que no hay ningún problema en el uso del team viewer con ese modelo de router ya no veo como ayudarte.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 27 de 56
2.714 Visitas
FerreXevi
Yo probé el VDSL

Yo estoy usando Teamviewer  desde que salio y nunca e tenido un solo problema, no e tenido que abrir puertos ni hacer nada, tan simple como instalar, iniciar sesión y añadir el PC en cuestión (para guardar contraseñas de acceso y demás). Y me conecto desde un iphone, PC iPad.... o cualquier dispositivo que disponga de teamviewer sin ningún problema.

 

Si que entra en mis planes sustituir el router a corto plazo para poder hacer unas configuraciones, que por lo que estoy leyendo, movistar capa, dado que por el momento no e conseguido confirmarlo voy en busca de respuestas.

 

Actualmente tienes la versión de pago? o es no comercial? ya que teamviewer puede cortarte el acceso si haces uso de él desde una organización o detectan un uso intensivo.

 

Salu2

Mensaje 28 de 56
2.700 Visitas
Theliel
Yo probé el VDSL

Buenas @FerreXevi

 

Ante un uso excesivo, lo que hacen los amigos de TV es mostrar un cartel de supuesto uso comercial, que aceptas y listo. Su problema no es de "corte", me temo, ojalá fuese eso y se podría solventar de forma sencilla (aunque fuese pagando). El problema aquí es que ha tenido la mala fortuna de toparse tanto en la red de origen como en la red de destino con dispositivos NAT simétricos. Lo que no sé es si llegó a probar configurar el equipo como DMZ



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 29 de 56
2.689 Visitas
JulioC-Movistar
Antiguo Moderador

@FerreXevi No sé a que le llamas "Capar..."  pero si es limitar puertos o conexiones de algún tipo ya te digo que ninguno de nuestros routers está "Capado"  tranquilo por eso. Y Team Viewer funciona sin problemas en los HGU, es un problema particular de @Jesmo algo en su configuración o sistema operativo.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 30 de 56
2.669 Visitas
FerreXevi
Yo probé el VDSL

@JulioC-Movistar no me preocupa el tema de puertos y demas, sino el control y gestion que haceis vosotros desde la central, como es posible que youtube, netflix o servicios de streaming funcionen mejor en un ADSL de 20MB con un ping 10 veces por encima de la fibra con 15 veces mas de velocidad y ademas simetricos?.

 

A eso me refiero cuando digo "capar" mucha velocidad, ping bajo pero para que? al final se gestiona la red a vuestro gusto. Todo ruter ofrecido por operadora dispone de un protocolo de telegestion, mas conocido como "TR069" es una de las cosas entre otras que me empuja a sustituir el router.

 

Salu2

Mensaje 31 de 56
2.645 Visitas
Theliel
Yo probé el VDSL

Buenas @FerreXevi

 

Lo que dices es falso en gran parte.

 

Es totalmente cierto que los equipos se configuran/gestionan de forma remota a través de TR069, algo por cierto común en la mayoría de todos los ISP, y aun así si quieres lo puedes deshabilitar. Pero es verdad que lo hacen. Es más, no sólo se gestiona por TR069, sino que la propia ONT (o HGU) se puede gestionar/controlar a través de OMCI. De todos modos el control que se hace por TR069, al menos en el caso de Movistar, es bastante limitado

 

Respecto a lo de Netflix y otros serviciso de Streaming, es totalmente falso, se ha hablado y explicado cientos de veces, que cada cual lo quiera creer o no, es otra cuestión. Los servicios de Streaming funcionan perfectamente, para mi el visionado 4K es habitual y nunca he tenido un solo problemas. Otra cosa muy diferente es lo de Netflix, que va "mal" por la sencilla razón de que, al menos hasta la fecha, no ha querido pagar a Movistar por hacer peering, y si no hace Peering se saturan los nodos de entrada a la red de Netflix, nodos que son de Netflix por cierto. Esto se puede igualmente extrapolar a otros servicios. Un ISP puede cuidar su red, pero lo que pase fuera de ella no puede hacer nada. Si quieres un tráfico rápido y de baja latencia necesitas un Peer, y eso implica pasar por caja, si Netflix no quiere pagar por conectarse directamente a la red de Movistar, pues pasa lo que pasa.

 

No tiene absolutamente nada que ver con velocidad, son saturaciones que hay en puntos específicos, que además se pueden ver también, y no están en la red de Movistar.

 

Capar o restringir cualquier tipo de servicio o tráfico, para mas inri, es totalmente ilegal, Movistar no podría aunque quisiese, tiene obligacion!! si, repito, OBLIGACION a tratar absolutamente todo el tráfico que pasa por su red del mismo modo, sin importar de donde viene, a donde va, el contenido... Eso no significa que no se hagan cazicadas de cuando en cuando ni que sean una hermanita de la caridad, y por descontando que podrían mejorar mil cosas, pero respecto a este hilo en cuestión (TeamViewer), respecto a lo de Netflix y otros servicios de Streaming, no hay ni existe ninguna mano negra ni conspiración.

 

Sobre TR069 y otros?? Es cierto que se usan, pero aun así Movistar, y es para mi ahora mismo de las mejores cosas que tiene como ISP, te sigue permitiendo un control relativamente extenso del equipo que te instalan. No es el mejor hardware del mercado, claro que tienen "puertas" traseras para acceder a ellos, pero a fin de cuenta el equipo es de ellos, puedes instalar el tuyo propio si lo prefieres ojo, en otros ISP lo tienes mucho más complicado, aquí no hay mucho problema.

 

Saludos.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 32 de 56
2.636 Visitas
Jesmo
Yo probé el VDSL

Entramos en temas "yo lo niego", pero algo pasa...

 

El tema, mio, de este hilo, es que sigo sin pover "ver" mi ordenador usando un simple Teamviewer. Por ADSL si podía, por Fibra no, manda narices.

 

 

Saludos

Etiquetas (1)
Mensaje 33 de 56
2.621 Visitas
JulioC-Movistar
Antiguo Moderador

Ni el router ni la central distingue tráfico de team viewer de ningún otro tipo de tráfico, también he comprobado que en un router igual no hay ningún problema para entrar por team viewer a un PC, el problema no es de nuestros equipos tienes que preguntar en los foros de team viewer por si pueden solucionarlo.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 34 de 56
2.621 Visitas
Jesmo
Yo probé el VDSL

No opino lo mismo.

 

Si antes con ADSL y otro router, linea cobre, (usé varios), nunca tuve problemas y ahora nada mas cambiar a fibra, NO FUNCIONA, esta claro que algo tiene que ver, es por sentido común y lógica.

 

En los foros de Team me indican que funciona perfectamente, que debe ser el router o la conexión, es que no hay otra, no se ha modificado absolutamente nada.

 he podido hacer otra prueba, y no son los puertos.

 

 

Saludos

Hoy

Mensaje 35 de 56
2.599 Visitas
Jesmo
Yo probé el VDSL

El mensaje de error que me indica Teamviewer, después introducir la ID e intentar conectar, en todos los equipos es el mismo:

"No se ha podido establecer la conexión. No ha podido establecerse una conexión. O su asociado no está conectado a Internet o el Teamviewer de su asociado todavía no se ha iniciado. Solicite a su asociado que compruebe su conexión a Internet o que inicie Teamviewer."

 

Nunca llega a pedirme la contraseña.

 

Saludos

Mensaje 36 de 56
2.590 Visitas
Theliel
Yo probé el VDSL

Buenas @Jesmo

 

Creo que lo he explicado perfectamente en los mensajes anteriores, que se quiera creer o no es otra cuestión, pero si quieres te lo repito:

 

TeamViewer = Hole Punching

Hole Punching con NAT Simétrico en ambos extremos = PROBLEMAS

 

Es así de simple. Si el Router que tenías DSL usaba NAT restrictivo a puerto en vez de NAT simétrico, no tendrías problemas porque tu extremo no usaba NAT simétrico, usase el otro extremo NAT simétrico o no. La inmensa mayoría de todos los equipos actuales, no solo los de Movistar, usan NAT Simétrico por ser más seguro y más sencillo de implementar. Es más, si no puedes conectar es porque el otro extremo, también está usando NAT Simétrico.

 

No hay más, chimpón, así de simple. Si no lo quieres creer o tienes dudas al respecto, te invito a buscar información al respecto sobre todo ello, o si es algo en concreto con gusto te lo explico también, si te es laboriosa la jerga o te pierdes con alguna cosilla.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 37 de 56
2.580 Visitas
FerreXevi
Yo probé el VDSL

@Theliel Seguiré realizando pruebas, de todos modos, este router esta muy limitado, anteriormente tenia Jazztel y sustituí el router por un cisco, sin ningún tipo de problema, la operadora me facilito todos los parámetros de configuración sin tenerle que pedir dos veces, es ese aspecto, chapo. Referente a lo demás, como dije seguiremos investigando.

 

Sin mucho mas que añadir, gracias por tu explicación.

 

@Jesmo A ver, si es un putadon, pero si eso que dicen es cierto, poco puedes hacer, simplemente as tenido mala suerte, en tu lugar haría una prueba, pero es un tanto compleja, aun que yo a día de hoy lo tengo operativo y funcionando, se trata de lo siguiente:

 

Crea una red VPN con ZeroTier (hay tutoriales muy buenos y si se sigue al pie de la letra es muy fácil). Una vez tengas la red VPN operativa, es tan simple como conectarte y usar la app remote descktop de windows (bien APP, como desde otro ordenador), o si lo prefieres VNC server, yo me decante por la propia de windows por su sencillez .

 

Es un problema explicarte por aquí los pasos a seguir, lo mejor es que por tu cuenta busques un video explicativo de como configurar todo eso, lo que si te aconsejo es que: 1-dispongas de un win 10 version PRO, y 2-tengas habilitada la opción permitir conexiones de escritorio remoto.

 

SI, es un engorro, pero  por probar no pierdes nada, y estoy 100% seguro que te va a funcionar.

 

Salu2

Mensaje 38 de 56
2.570 Visitas
Theliel
Yo probé el VDSL

Buenas @FerreXevi

 

Aquí muchos usamos nuestro propio Router, en los que me incluyo por cierto, no hay que pedirle los datos a Movistar, son todos bien conocidos y cuasi universales, excluyendo los parámetros para TV, el resto son los mismos para todos.

 

Los HGU, en comparación con otros equipos instalados por los ISP, son los menos limitados en cuanto a funciones y configuración. Obviamente, en comparación con equipos comerciales que puedes adquirir, no llegan de ningún modo, razón como digo que muchos usemos nuestros propios equipos.

 

En cualquier caso hay que tener en cuenta, siempre lo digo, que el equipamiento que instalará un ISP siempre será "simple", son equipos domésticos para cubrir las necesidades de más del 90% de la población, los cuales no necesitan prácticamente nada, funciones simples y sencillas. En lo personal estoy totalmente en contra a esta filosofía, y prefiero aplicar la de: Dame el equipo "completo" y das opciones tanto a los que no los necesitan como a los que sí. Pero no es algo que abunde, me temo, en España al menos, el software/firmware que llevan los Routers que instalan los ISP dan auténtica pena, y los de Movistar aun se salvan algo, lo que instalan otros dan auténtico pavor. Pero.. mientras permitan al menos y puedan facilitar usar hardware propio, personalmente, me parece perfecto.

 

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 39 de 56
2.562 Visitas
Dracot
Yo probé el VDSL
Y volviendo al tema del hilo, ¿Se llegó a realizar la prueba en DMZ? Si es así, igual se podría mirar por otro lado....no sé, por eliminar posibilidades.

Que no es que a estas alturas vaya yo a pensar que @Theliel se equivoca, pero quién sabe, alguna vez le tiene que ocurrir al hombre jejejeje
Mensaje 40 de 56
2.559 Visitas
Theliel
Yo probé el VDSL

Buenas @Dracot

 

DMZ en teoría podría funcionar, a fin de cuentas redirige todo el tráfico directamente al equipo en DMZ que no haya sido anteriormente mapeado, así que... es un tanto radical, pero...



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 41 de 56
2.536 Visitas
Dracot
Yo probé el VDSL

Por eso lo digo. Al ser una medida radical, siempre lo desaconsejo como solución permanente (salvo casos específicos, muy controlados y de bajo riesgo), pero es una de las medidas que siempre aconsejo tomar para acotar el problema. Si así funciona, lo quito y a rebuscar soluciones en forwarding de puertos, tipo de NAT, etc, si no funciona, pues llevo el diagnóstico a otro plano.

 

Es decir, a pesar de reiterarme en que no debería ser la solución, si que veo importante hacer esa prueba.

 

Mensaje 42 de 56
2.528 Visitas
JulioC-Movistar
Antiguo Moderador

@Jesmo  Puedes hacer otra prueba sencilla para descartar problemas en el router y en la línea, intenta conseguir otro PC, instala en ese PC un Team viewer nuevo, nueva cuenta, prueba en esas condiciones  a acceder desde otro equipo, no el equipo con el que intentas acceder ahora, para descartar problemas de cuentas, de bloqueos de aparatos no seguros -team viewer te pide confirmación de cada equipo que se conecta- etc...



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 43 de 56
2.498 Visitas
Jesmo
Yo probé el VDSL

Hola

 

Gracias a todos por las aportaciones.

 

Las pruebas propuestas son complejas para mi, al menos sin saber lo que estoy tocando y con seguridad.

 

La última que hice es cambiar equipos, (por si acaso), me lleve el equipo que no funciona con fibra a una linea con ADSL, y si funciona.

 

También cambié el equipo que si funcionaba con ADSL a la linea de fibra de marras y ya no funciona.

Teamviewer lo he probado con cuenta y en modo "invitado" ID y contraseña, el resultado y error es el mismo, como si no estuviera conectado.

 

Voy a intentar buscar alguien que tenga fibra de otro ISP a ver si desde allí cambia algo.

 

Esta clarísimo que no es del equipo, es el router o bien la linea de fibra; algún "capado" hay.

 

Lo que mas me cabrea es el pasotismo que tiene Movistar con el tema; no hace falta tener mucha inteligencia para ver que el probelama no es de abrir puertos en el router, como me han dicho; si fuera así que me lo demuestren y pido disculpas.

 

 

Saludos

Mensaje 44 de 56
2.480 Visitas
Theliel
Yo probé el VDSL

Buenas @Jesmo

 

Entiendo perfectamente tu crispación y tu no entender como funcionan algunas cosas. También entiendo perfectamente que en principio "cargues" contra el ISP porque algo no funciona como crees que debería de funcionar. Pero intenta también leer un poco, todo es demostrable sin problema

 

No, no es el PC, no, no es la línea. Cuando te conectas a un Router, para poder usar la conexión el Router hace NAT, igual que hacen por desgracia las operadoras para las redes Móvil. Hay varios tipos de NAT por así decirlo, más seguros y menos seguros, más aptos para algunas cosas y menos aptos para otras.

 

Para poder conectarse de un equipo a otro a equipos que están detrás de dispositivos NAT, es necesario por lo general abrir puertos. TeamViewer para evitar a los usuarios que abran puertos, usa un mecanismo para "sortear" NAT, llamado Hole Punching. Pero este sistema NO FUNCIONA generalmente cuando tanto un extremo como el otro extremo usan NAT simétrico.

 

Ty HGU usa NAT Simétrico, así que si intentas conectarte hacia cualquier sitio (o desde cualquier sitio hacia tu equipo) que esté detrás de NAT simétrico también, TENDRAS PROBLEMAS.

 

A día de hoy la mayoría de equipos más nuevos usan NAT Simétrico por seguridad y por sencillez. Antes el Router que tenías no usaría NAT Simétrico, así que como uno de los extremos no lo usaba, no había problemas. Ahora tu extremo si lo usa, con lo que dependes del otro extremo, y como te estoy diciendo, cada vez es más usado.

 

No hay nada que solucionar porque es como funciona TeamViewer, y el Router funciona como es debido. Si aun así no te queda claro, con gusto te hago un esquema y capturas para mostrarte de un modo más gráfico si lo prefieres como funciona la historia y el motivo por el cual tienes problemas.

 

Intentar usar DMZ en el Router es drástico pero podría funcionar. Otra opción sería que el Router permitiese cambiar el tipo de NAT, cosa bastante poco habitual en equipos de este tipo (en alguno de Movistar es posible aun hacerlo de malas maneras), y como ultima solución habla con TeamViewer y les preguntas para cuando van a permitir usar TV en modo cliente-servidor.



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 45 de 56
2.470 Visitas
Theliel
Yo probé el VDSL

Bueno, como me gusta llegar hasta el fondo de la cuestión, pongo a quien interese un resumen de todo, y una posible solución, aunque no probada, al menos para el ASKEY:

 

Después de estar jugando largo y tendido con TeamViewer:

 

TV intenta siempre realizar una conexión por UDP usando Hole Punching entre origen-destino, siendo la opción preferida por ser mucho más rápida y más tolerante a fallos. Cuando este no es factible, generalmente por el uso de NAT simétrico, la conexión se intenta hacer pasar por un servidor de TV intermedio y con TCP, lo que puede producir otros problemas similares.

 

El ASKEY al menos, presupongo que el HGU Mitrastar también, usan ambos NAT Simétrico, y esto es un problema a la hora de hacer Hole Punching, sobre todo si ambos extremos están bajo NAT simétrico. En todas mis pruebas, la conexión era posible por UDP (hole punching) siempre y cuando ambos extremos no usasen NAT simétrico, si los dos estaban bajo NAT simétrico, entonces TV pasaba a una conexión TCP, pero se permitía y funcionaba "bien". No obstante, la alternativa TCP de TV pasa por sus servidores, los cuales no siempre están operativos tampoco, con lo que terminas con problemas.

 

Por qué afecta esto?

 

Habría que explicar cada tipo de NAT, pero lo más sencillo es verlo con ejemplo real, gracias a una pequeña utilidad de Python llamada PyStun, veamos Full Cone NAT, Restricted Cone NAT y SymetricCone  NAT. Lo que hace Pystun es iniciar la conexión a un servidor STUN y solicitarle al servidor externo sus propios datos, es decir, que datos de nosotros ve el otro extremo. Acto seguido se solicita un cambio de IP o de puerto, para ver si el servidor STUN es capaz de conectarse con nosotros a raiz de esa primera conexión que hemos realizado, dependiendo de esto se puede conocer que NAT tenemos.

 

 

pystun -d -p 65000

Test1
Conectando Servidor STUN: stun.ekiga.net
Enviar a: ('stun.ekiga.net', 3478)
Recibido desde: ('217.10.68.152', 3478)
Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 65000, 'ChangedPort': 3479, 'SourcePort': 3478, 'SourceIP': '217.10.68.152', 'ChangedIP': '217.116.122.137'}

Test2
Enviar a: ('stun.ekiga.net', 3478)
Recibido desde: ('217.116.122.137', 3479)
Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 65000, 'ChangedPort': 3479, 'SourcePort': 3479, 'SourceIP': '217.116.122.137', 'ChangedIP': '217.116.122.137'}
NAT Type: Full Cone
External IP: mi_ip
External Port: 65000

 

pystun -p 65000
Test1 Conectando Servidor STUN: stun.ekiga.net Enviar a: ('stun.ekiga.net', 3478) Recibido desde: ('217.10.68.152', 3478) Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 65000, 'ChangedPort': 3479, 'SourcePort': 3478, 'SourceIP': '217.10.68.152', 'ChangedIP': '217.116.122.138'}
Test2 Enviar a: ('stun.ekiga.net', 3478) Enviar a: ('stun.ekiga.net', 3478) Enviar a: ('stun.ekiga.net', 3478) Enviar a: ('stun.ekiga.net', 3478) Resultado: {'ExternalIP': None, 'Resp': False, 'ExternalPort': None, 'ChangedPort': None, 'SourcePort': None, 'SourceIP': None, 'ChangedIP': None}
Test3 Enviar a: ('217.116.122.138', 3479) Recibido desde: ('217.116.122.138', 3479) Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 65000, 'ChangedPort': 3478, 'SourcePort': 3479, 'SourceIP': '217.116.122.138', 'ChangedIP': '217.10.68.152'}
Test4 Enviar a: ('217.116.122.138', 3478) Recibido desde: ('217.116.122.138', 3479)
Result: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 65000, 'ChangedPort': 3478, 'SourcePort': 3478, 'SourceIP': '217.116.122.138', 'ChangedIP': '217.10.68.152'} NAT Type: Restric NAT External IP: mi_ip External Port: 65000

 

pystun -d -p 65000

Test1
Conectando Servidor STUN: stun.ekiga.net
Enviar a: ('stun.ekiga.net', 3478)
Recibido desde: ('217.10.68.152', 3478)
Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 41014, 'ChangedPort': 3479, 'SourcePort': 3478, 'SourceIP': '217.10.68.152', 'ChangedIP': '217.116.122.138'}

Test2
Enviar a: ('stun.ekiga.net', 3478)
Enviar a: ('stun.ekiga.net', 3478)
Enviar a: ('stun.ekiga.net', 3478)
Enviar a: ('stun.ekiga.net', 3478)
Resultado: {'ExternalIP': None, 'Resp': False, 'ExternalPort': None, 'ChangedPort': None, 'SourcePort': None, 'SourceIP': None, 'ChangedIP': None}

Test3
Enviar a: ('217.116.122.138', 3479)
Recibido desde: ('217.116.122.138', 3479)
Resultado: {'ExternalIP': 'mi_ip', 'Resp': True, 'ExternalPort': 31543, 'ChangedPort': 3478, 'SourcePort': 3479, 'SourceIP': '217.116.122.138', 'ChangedIP': '217.10.68.152'}
NAT Type: Symmetric NAT
External IP: mi_ip
External Port: 31543

Full Cone:

 

Es el primer ejemplo, y lo que sucede es exactamente lo mismo cuando se abre/mapea un puerto.

a) Conectamos con el servidor STUN desde un puerto concreto. El servidor nos contesta y nos dice que el puerto que el ve es el mismo que especificamos nosotros

b) El servidor nos avisa ahora que el próximo paquete que le enviemos, nos los va a devolver otro servidor (otra IP) y otro puerto

c) Dado que nuestro equipo recibe de nuevo la respuesta, sólo cabe que estemos en Full Cone NAT, mientras enviemos en ese caso las peticiones por el puerto especificado, 65000, todo el tráfico que venga hacia él, desde cualquier IP y puerto, se va a aceptar.

 

Restricted Cone:

 

En este caso  la cosa no es tan sencilla

a) Igual que el paso anterior
b) Igual que el paso anterior.

c) En este caso nuestro equipo no es capaz de recibir nada desde el servidor STUN, no hay conexión entrante desde la otra IP con otro puerto. Así que no es Full Cone

d) Ahora se inicia otro test, en este caso es igual que el primero en este caso el servidor nos responde que el próximo paquete que nos responda cambiará el puerto, pero mantendrá la IP (no se usará un segundo servidor STUN como pasó en el caso anterior).

e) En este caso, a pesar de que el puerto de origen ha cambiado, el paquete si llega, con lo que estamos ante Restricted NAT

 

Port Restricted Cone:

 

Este escenario no lo he configurado, pero sería similar al anterior, solo que en este caso además de la restricción de que el paquete tiene que venir desde la misma IP, también se aplica la restricción de que debe de hacerlo desde el mismo puerto. Es decir, se llegaría hasta el paso d anterior, y tampoco habría respuesta puesto que el puerto se había cambiado.

 

 

Symmetric NAT

 

Por último, y aquí es donde tenemos los "problemas.

 

a), b), c) y d) son iguales al caso de Restricted NAT, no cambia nada

e) En este caso el paquete también llega, podría parecer que estamos de nuevo con Restricted NAT, pero si nos fijamos, nuestro puerto externo que que ve el servidor STUN es diferente en los test 1 y 3. A pesar de que especificamos usar el puerto 65000, el Router mapea ese puerto que será el que realmente sea visible para el exterior, pero además, ese mapeo será diferente (otro puerto) en diferentes conexiones, incluso cuando es a la misma IP, el puerto externo que está usando el Router es diferente.

 

 

Este es el problema que ocasionan a algunos juegos y otros servicios Nat simétrico, porque los equipos externos no pueden conocer de antemano (por lo general) que puerto usará el Router para la siguiente conexión a menos que nuestro equipo haya iniciado explícitamente la conexión a ese destino y a ese puerto. Si el destino intenta enviarnos de vuelta contenido al mismo puerto, fallará, porque ese puerto ya no se estará usando posiblemente, será otro el que tenga la conexión abierta.

 

--------------------------------------------

 

Dicho todo esto, en los HGU tal vez exista una solución, además de usar DMZ. Ambas soluciones son igual de malas realmente, pero son "soluciones". En teoría, los HGU permiten configurarse como Full Cone, abandonando la seguridad que aporta NAT simétrico. Usar Full Cone es muy arriesgado, sería algo así como que el Router tiene los puertos abiertos en el momento que un equipo interno solicita una conexión hacia otro lado, sería casi casi estar sin Firewall.

 

Quien quiera probar puede hacerlo, pero no es nada recomendable. Sería editando la interfaz WAN pppoe y habilitando Full Cone.

 

Ya que estaba con ello, por cierto, me ha dado por mirar la telefonía móvil, recordemos que desde algunos lugares el compañero podía hacerlo y otros no. Para mi sorpresa, en los 3-4 sitios que he probado, en todos están usando ya NAT Simétrico. Personalmente creía que era una excepción y una rareza, pero por ahora, al menos por mi zona, parece que las operadoras están usando también NAT simétrico en las redes móviles

 

Que tenga constancia, ambos HGU de Movistar usan NAT Simétrico, los LiveBox de Orange también. No he tenido tiempo para ir comprobando otros modelos.

 

En cualquier caso, TeamViewer debería de conectar por TCP usando un servidor en medio, cosa que en este caso parece que no es posible por alguna razón. Para ver por qué falla la conexión por TCP sería necesario que habilitases los registros de TeamViewer de conexiones, y los subieses a algun lado. No solventa el problema de Nat simétrico, pero igual con suerte se podría hacer algo.

 



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 46 de 56
2.429 Visitas
Jesmo
Yo probé el VDSL
Hola Theliel Gracias por toda la información, me queda mucho mas claro, aunque hay sosas en las que me sigo perdiendo. No es que cargue la culpa al ISP, pero creo que la explicación que das tu, u otra mas resumida incluso la podría haber dado Movistar y no la "lindeza" de los puertos. Intentaré ver los de los registros de conexiones en Teamviewer a ver si sacamos algo en claro. Supongo que esto que me ocurre a mi, y he estado explicando espero no ser el único, ya que todo esta funcionado correctamente, debe afectar de igual forma a mas usuarios, porque empiezo a sentirme un poco raro. Saludos Saludos
Mensaje 47 de 56
2.351 Visitas
Theliel
Yo probé el VDSL

Buenas @Jesmo

 

Tienes toda la razón en que Julio, en este caso, no ha estado demasiado acertado, la verdad. Son cuestiones bastante complejas, y no son precisamente las más sencillas de testear/probar. A fin de cuentas un puerto es algo que puedes redireccionar de forma sencilla, con lo que pruebas en este aspecto son muy rápidas. Pero cambiar el comportamiento NAT de un equipo implica mucho mucho más, ojo, simplemente comprobar que tipo de NAT tenemos, no es nada trivial, requiere del uso de diferentes servidores (al menos dos) externos y de forma más o menos controlada.

 

Por otro lado, existe otra problemática aun mayor, que por ahí arriba la dejaba claro. TeamViewer es un software propietario y de código cerrado creado por una empresa. Tenemos que dar gracias de saber a grandes rasgos como funciona, y no por que TV nos lo diga, sino a costa de muchas pruebas, deducciones, experimentos... en este caso concreto repito, tenemos suerte de más o menos tener idea de como lo hace, repito que es un software propietario, que usa sus propios protocolos, sus propios mecanismos...

 

Partiendo de la base de que sabemos que el equipo y la línea funcionan bien, sabiendo los problemas que ocasiona NAT simétrico a cierto tipo de técnicas (y se puede comprobar), lo único que podemos sacar al 100% seguro que mientras se esté ambos extremos con NAT simétrico es imposible establecer la conexión por UDP, y que la conexión por TCP es muy muy poco fiable. Que eso no quiere decir que no "podamos" hacerlo andar, que puede ser "temporal" por fallo en los servidores de TV, que... pues es como te digo, mucho estudio y ver que pasa...

 

Mira a ver si puedes subir los archivos de registro a ver si dicen algo del motivo por el cual la conexión TCP está fallando, mucho mas no podemos hacer compi, ojalá pudiese replicarlo por mi parte y poder echar un ojo mejor



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 48 de 56
2.335 Visitas
Jesmo
Yo probé el VDSL

Hola

 

A ver si estos son los datos que hacen falta:

 

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\TeamViewer\Version6]
"Always_Online"=dword:00000000
"Proxy_Type"=dword:00000001
"Proxy_IP"=""
"ProxyUsername"=""
"ProxyPasswordAES"=hex:88,44,d7,0a,b2,96,2a,3d,63,16,3c,ff,e4,15,04,fb
"LanOnly"=dword:00000000
"General_DirectLAN"=dword:00000000
"SecurityPasswordAES"=hex:88,44,d7,0a,b2,96,2a,3d,63,16,3c,ff,e4,15,04,fb
"Security_WinLogin"=dword:00000000
"Security_PasswordStrength"=dword:00000000
"Blacklist"=hex(7):00,00
"Whitelist"=hex(7):00,00
"BlacklistBuddy"=hex(7):00,00
"WhitelistBuddy"=hex(7):00,00
"UseWhitelist"=dword:00000000
"Security_AcceptIncoming"=dword:00000001
"MultiPwdMgmtIDs"=hex(7):00,00
"MultiPwdMgmtPWDs"=hex(7):00,00
"Security_Disableshutdown"=dword:00000000
"HideOnlineStateOfTV"=dword:00000000
"ACFullAccessOnLoginScreen"=dword:00000000
"UpdateCheckInterval"=dword:00000000
"Logging"=dword:00000001
"LogIncomingConnections"=dword:00000001
"LogOutgoingConnections"=dword:00000001
"Security_ActivateDirectIn"=dword:00000000
"ListenHttp"=dword:00000001
"CustomRouter"=""
"ServerPasswordAES"=hex:88,44,d7,0a,b2,96,2a,3d,63,16,3c,ff,e4,15,04,fb
"UPNP"=dword:00000000
"useUDP"=dword:00000001
"Security_Adminrights"=dword:00000000
"OptionsPasswordAES"=hex:88,44,d7,0a,b2,96,2a,3d,63,16,3c,ff,e4,15,04,fb

[HKEY_CURRENT_USER\SOFTWARE\TeamViewer\Version6]
"MinimizeToTray"=dword:00000000
"Remote_QualityMode"=dword:00000000
"Remote_Colors"=dword:00000008
"Remote_Compression"=dword:00000064
"Remote_UseHooks"=dword:00000001
"Remote_UseAeroGlass"=dword:00000001
"Remote_RemoveWallpaper"=dword:00000001
"Remote_RemoteCursor"=dword:00000000
"AutorecordRemoteControl"=dword:00000000
"SessionRecorderDirectory"=""
"Pres_QualityMode"=dword:00000001
"Pres_Colors"=dword:00000010
"Pres_Compression"=dword:00000064
"Pres_UseHooks"=dword:00000001
"Pres_UseAeroGlass"=dword:00000001
"Pres_RemoveWallpaper"=dword:00000001
"Pres_ShowSelectionForOutgoingPresentations"=dword:00000000
"OfflinePartnersInOwnGroup"=dword:00000001
"Buddy_NotifyOnMessage"=dword:00000001
"Buddy_NotifyOnPartnerSignIn"=dword:00000001
"Buddy_ShowPartnerListOnStartup"=dword:00000001
"CustomInvitationText"=""
"CustomInvitationTextP"=""
"CustomInvitationSubject"=""
"CustomInvitationSubjectP"=""
"SelectedLanguage"=""
"Buddy_QuickPresEnabled"=dword:00000001
"Buddy_QuickPresExclusions"=hex(7):63,00,68,00,72,00,6f,00,6d,00,65,00,2e,00,65,00,78,00,65,00,00,00,\
64,00,65,00,76,00,65,00,6e,00,76,00,2e,00,65,00,78,00,65,00,00,00,\
6d,00,65,00,64,00,69,00,61,00,6d,00,6f,00,6e,00,6b,00,65,00,79,00,2e,00,65,00,78,00,65,00,00,00,\
6d,00,73,00,6e,00,6d,00,73,00,67,00,72,00,2e,00,65,00,78,00,65,00,00,00,\
6f,00,70,00,65,00,72,00,61,00,2e,00,65,00,78,00,65,00,00,00,\
70,00,73,00,72,00,2e,00,65,00,78,00,65,00,00,00,\
73,00,75,00,70,00,65,00,72,00,2e,00,65,00,78,00,65,00,00,00,\
77,00,6c,00,6d,00,61,00,69,00,6c,00,2e,00,65,00,78,00,65,00,00,00,\
77,00,6c,00,78,00,70,00,68,00,6f,00,74,00,6f,00,67,00,61,00,6c,00,6c,00,65,00,72,00,79,00,2e,00,65,00,78,00,65,00,00,00,\
00,00
"Buddy_QuickPresPosition"=dword:0000000a
"Remote_BlackScreen"=dword:00000000
"CachePasswords"=dword:00000001
"AutoHideServerControl"=dword:00000000
"DisableCaptureBlt"=dword:00000000
"ClipboardSync"=dword:00000001
"ChangeDynamicPassword"=dword:00000000
"DeactivatedDynamicPassword"=dword:00000000

[HKEY_CURRENT_USER\SOFTWARE\TeamViewer\Version6\AccessControl]
"AC_AllowOutgoingConnections"=dword:00000001
"AC_Client_AccessControlType"=dword:00000000
"AC_Client_Custom_AllowPartnerViewDesktop"=dword:00000000
"AC_Client_Custom_RemoteControlAccess"=dword:00000000
"AC_Client_Custom_FileTransferAccess"=dword:00000000
"AC_Client_Custom_AllowVPN"=dword:00000000
"AC_Client_Custom_DisableRemoteImput"=dword:00000000
"AC_Client_Custom_ControlRemoteTV"=dword:00000000
"AC_Client_Custom_ChangeDirAllowed"=dword:00000000
"AC_Client_Custom_DisableRemoteInputAtStart"=dword:00000000
"AC_Pres_Allow_Presentations"=dword:00000001
"AC_Pres_ChangeDir"=dword:00000001
"AC_Pres_Allow_Partner_Input"=dword:00000001
"AC_Pres_All_Apps_On_Startup"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\TeamViewer\Version6\AccessControl]
"AC_Server_AccessControlType"=dword:00000000
"AC_Server_Custom_AllowPartnerViewDesktop"=dword:00000000
"AC_Server_Custom_RemoteControlAccess"=dword:00000000
"AC_Server_Custom_FileTransferAccess"=dword:00000000
"AC_Server_Custom_AllowVPN"=dword:00000000
"AC_Server_Custom_DisableRemoteImput"=dword:00000000
"AC_Server_Custom_ControlRemoteTV"=dword:00000000

[HKEY_CURRENT_USER\SOFTWARE\TeamViewer\Version6\MsgBoxDontShow]
"PasswordOnSessionEnd"=dword:00000001

 

 

 

Saludos

Mensaje 49 de 56
2.317 Visitas
Theliel
Yo probé el VDSL

Buenas compi,

 

No, no me refería a las entradas del registro de Windows. En TV pudes habilitar el registro, en opciones, avanzado, mostrar opciones avanzadas, archivos de registro, y marcas las 3 opciones.

 

Una vez ese paso se ha realizado, apuntas más o menos la hora a la que haces la prueba para que sea luego más comodo mirar los registros, y haces algunos intentos de conexión. Una vez terminado, le das a extra, y a abrir archivos de registro, y abrá un archivo llamado TeamViewer....log. Ese es el archivo que habría que echarle un ojo, lo puedes subir a cualquier sitio o incluso pegar el contenido en pastebin



Por privado solo asuntos privados, para lo demás la comunidad."El conocimiento nace del desacuerdo"
Mensaje 50 de 56
2.306 Visitas