Hola, buenas tardes. Parece que Movistar está bloqueando las conexiones a webs (entre ellas la mía) que usan Cloudflare o está teniendo problemas de enrutamiento. Ocurre solo con fibra, desde redes móviles no ocurre. En otras compañías funciona perfectamente. ¿Se sabe algo?
No es cosa tuya no, y tampoco ha estado arreglado del todo... hay una IP de las que yo reporté que nunca ha devuelto PING desde hace 4 días... pero ahora mismo es que las "vecinas" que ayer si iban, ahora tampoco responden. Y todo eso pasa SOLO desde Movistar/O2... otros proveedores hacen ping a TODAS sin problema.
Ejemplo:
fw (10.0.0.254) -> 143.244.56.50 (143.244.56.50) 2025-02-05T17:34:07+0100
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. router 0.0% 61 0.4 0.4 0.3 0.6 0.0
2. 192.168.144.1 0.0% 61 2.0 2.0 1.7 2.3 0.1
3. 233.red-81-46-64.customer.static.ccgg.telefonica.net 93.3% 61 2.3 2.4 2.2 2.5 0.1
4. 106.red-81-46-65.customer.static.ccgg.telefonica.net 19.1% 61 3.1 3.1 2.8 3.4 0.1
5. 61.red-80-58-96.staticip.rima-tde.net 0.0% 61 3.0 4.1 2.8 19.8 3.5
ahi se ve como en el host: 233.red-81-46-64.customer.static.ccgg.telefonica.net que es la ip 81.46.64.233, por la que pasa la traza, está perdiendo como el 93% de los paquetes y el siguiente salto casi el 20%... además de que ahí se corta la traza no sigue ni termina de llegar al host final. Y el nombre de las máquinas que están perdiendo paquetes claramente lo dice, dominio *telefonica.net* no es CloudFlare, ni Bunny, ni perico de los palotes.
Buenas tardes, llevo 4 días con la misma incidencia, yo gestiono la web www.clubsimracing.com y solamente los usuarios de Movistar son los que me están abriendo incidencias de no poder acceder a al web y a nuestra app. Llamé hace 3 días al 1002, y no me solventaron la incidencia, el lunes por la mañana si me la resolvieron (en local), pero ahora vuelve a fallar, desde hace 30 minutos. He probado a acceder a las webs que indicáis en el hilo y nada de nada. Voy a llamar al 1002 nuevamente, pero si lo arreglan un día y al siguiente vuelven a hacer cambios, esto es un absurdo. Necesitamos una solución.
Buenas tardes. ¿Es cosa mía o vuelve a fallar desde hace un rato? Saludos.
Ahora no es exactamente ese caso, o no lo parece. Yo les reporté una traza y pings... de dos ips que no se podía llegar (no ping). y resulta que una "contigua" de la misma clase C si respondía ping perfectamente. Probando desde otros operadores, hosting etc, todos recibían el ping perfectamente de la que NO funciona en Movistar.
Y aun siguen diciendo "reinicia tu router".... así nos va..
Yo no descartaría que el problema fuese de limitación entre Cloudflare y Movistar por haber superado límites de peering de pago.
En el pasado ya hubo un problema de estos entre Movistar y Cloudflare en los que cada noche los sitios de CloudFlare no iban porque se superaba lo contratado por Cloudflare.
Buenas noches, hace ya días me quejé de algo que seguramente era el mismo problema y Telefónica no me supo contestar y dijo que de ellos no era el problema, La red de Movistar con webs en Cloudlfare de hace días con la fibra de Movistar va todo muy lento y con problemas de cuelgues y lentitud, con otros proveedores ningún problema, No se si es con Cloudflare gratis o de pago, esto no lo puedo corroborar.
Este era mi post:
Buenas odlfg
Da exactamente igual que seas o no cliente de Movistar para pasar por la red troncal de Telefónica, como te he dicho Telefonica es un Tier1 por el que circula tráfico de medio mundo. Y para nada estoy alegando ni mucho menos la latencia de la conexión para ello, que por cierto nada tiene que ver con la velocidad.
La ruta en ambos tracer son igualmente correctas. Dices que no pasa el tráfico a la red de CloudFlare? Claro que se enruta hacia ellos en ambas pruebas que has puesto:
9 188.114.108.57 (188.114.108.57) 14.617 ms
188.114.108.55 (188.114.108.55) 13.027 ms
188.114.108.53 (188.114.108.53) 11.617 ms
10 104.21.96.1 (104.21.96.1) 12.356 ms 12.231 ms 11.978 ms
Ese salto, es la red de CloudFlare, el contenido no te lo sirve Movistar!! En el salto 9 son sus servidores, nada tiene que ver con Movistar compañero. Del mismo modo en el otro tracert
9 cloudflare.alta.espanix.net (185.79.175.179) 75.048 ms 35.858 ms 52.702 ms
10 188.114.108.9 (188.114.108.9) 46.529 ms
188.114.108.55 (188.114.108.55) 61.191 ms 39.004 ms
11 104.21.64.1 (104.21.64.1) 47.438 ms 31.939 ms 38.343 ms
El salto 9 en este caso es el punto de intercambio de espanix con Clouflare, donde en el 10 está ya en la red de CloudFlare.
Ni mucho menos intento deslegitimar tus pruebas, es más, hablan por si mismas y cualquiera puede repetirlas si quiere, con diferentes resultados ya que desde cada ubicación serán diferentes. En ambos casos el trazado es totalmente correcto, y mucho mucho mucho menos quiere decir que exista ningún tipo de secuestro de tráfico o interceptación ni historias varias.
Es normal que si Telefonica tiene un peer con Cloudflare el tráfico pase por la red de Telefonica (que no Movistar, que es diferente) y entre en ClodFlare. Y esto tanto si tu conexión es de O2 o cualquier otra. Eso no quiere decir que el único camino posible hacia CloudFlare sea pasar por la red de Telefónica, si has mirado el enlace previo CloudFlare tiene cientos de Peer, con lo que el tráfico hacia ellos puede pasar en un momento dado por cualquiera de ellos... obviamente esto no es del todo correcto dado que depende enormemente la ubicación geográfica. En cualquier caso, es totalmente normal.
Respecto a la respuesta que copiaste/pegaste me llego el correo pro estar suscrito a este hilo. Seguramente salgó filtros de SPAM teniendo en cuenta el contenido que había, desde direcciones de correo, enlaces, y un largo etc... vamos, que es totalmente normal que se borrase. SI te hubieses limitado a copiar/pegar el texto no habría mayores problemas.
De echo, en el correo que haces alusión, sacado del copiar/pegar que pusiste, no se donde dices que pone que se aprecia algo raro, dice todo lo contrario:
"Debemos insistir en que, desde INCIBE-CERT, no apreciamos indicios de que exista un incidente de seguridad que esté comprendido en nuestras funciones, que puede consultar en el siguiente enlace"
"Insistimos en que su traza no demuestra que Telefónica esté secuestrando su tráfico, sino que está realizando una traza desde un recurso que usa su infraestructura al ser realizada desde una conexión a Internet que presta esta compañía, motivo por el que estas rutas estáticas no aparecen si sale a Internet por otro proveedor o a través de una VPN"
Honestamente, no veo en todo ello donde dicen que pasa algo raro. Lo que te están diciendo en el primer párrafo es que no existe indicio ni problemas que ellos deban siquiera investigar. Y en el segundo te explican a groso modo lo mismo que te he dicho previamente.
---------
Para terminar, en cualquier caso, y como ya te he dicho en mi anterior respuesta, cualquier detalle que no estés de acuerdo podemos debatirlo tranquilamente y sin problema alguno. Si no te parece adecuado, o como dices quieres dar el tema por zanjado, no hay tampoco mayor problema por mi parte.
Un saludo.
Para que quede claro, las pruebas no fueron realizadas en igualdad de condiciones. La conexión de O2 es fibra óptica, mientras que la conexión de Yoigo se realizó mediante tethering 4G con un móvil antiguo y con cobertura media.
A priori, la conexión de O2 debería ser mucho más rápida y eficiente pero funciona y nadie nos llama vendiendo mas cosas.
Sin embargo, es precisamente en esa conexión donde se produce la anomalía en el traceroute y donde aparecen los errores Soft 404 reflejados en GSC. Esto demuestra que el problema no es la velocidad de la conexión, sino la forma en que Telefónica/O2 está gestionando el tráfico. Un traceroute debería mostrar la ruta de conexión independientemente de la velocidad. El hecho de que con O2 no se vea la ruta hacia Cloudflare es, cuanto menos, sospechoso. De hecho, si nos ponemos a pensar un poco... parece un "secuestro" de manual.
Me parece injusto que se intente desacreditar mis pruebas, realizadas con rigor, simplemente porque una conexión es más rápida que la otra. Lo que importa aquí es la ruta que sigue el tráfico, no la velocidad a la que lo hace. Y esa ruta, en el caso de O2, no es la correcta. No voy a permitir que se beneficien de mis resultados de investigación sin que se reconozca la gravedad del problema que he expuesto y sin que se me ofrezca una solución.
Ahora si mi ultimo post y me voy de aquí:
Hola Theliel,
Agradezco tu explicación, pero sigo sin estar de acuerdo con tu interpretación. Dices que es "normal" que el tráfico pase por la red de Telefónica, pero olvidas un detalle fundamental: no soy cliente de Telefónica/O2, ni he solicitado que intervengan en mi conexión.
Insistes en que "es simplemente como funciona Internet", pero el traceroute a creatia.app a través de O2 no muestra los nodos de Cloudflare que sí aparecen con otros operadores. Eso no es normal.
El problema no es que el tráfico pase por la red de Telefónica, sino que Telefónica/O2 parece estar resolviendo las peticiones a mi web desde su propia infraestructura, sin pasar por Cloudflare. Eso es lo que indica el traceroute y eso es lo que, a mi entender, se asemeja a un "middleman" no autorizado, aunque no sea el clásico.
Dices que "Movistar está enrutando el tráfico por su red hacia el destino, sin más". Pero, ¿por qué no enruta hacia Cloudflare, que es donde está alojada mi web? ¿Por qué los errores Soft 404 solo ocurren con O2? ¿Por qué, como tú mismo indicas, se ha caído estos días el acceso a webs en planes gratuitos de Cloudflare desde Movistar, y no desde otros operadores? ¿Qué tiene que ver la configuración gratuita de Cloudflare para que Telefónica se salte a Cloudflare y enrute a su antojo?
Tú mismo reconoces que Telefónica tiene un "peer propio" con Cloudflare. Entonces, ¿por qué no lo usa en este caso? ¿Por qué el tráfico se desvía por la infraestructura de Telefónica en lugar de seguir la ruta directa hacia Cloudflare?
Me preocupa que se normalice una situación en la que un operador, sin mi consentimiento, decide cómo y dónde se sirve mi web. Esto, a mi juicio, afecta a la neutralidad de la red y a la seguridad de las comunicaciones, y me deja en una situación de completa indefensión como titular del dominio.
Insisto en que no se trata de un problema de latencia o eficiencia, sino de una cuestión de principios y de control sobre mi propia web.
Si Telefónica/O2 no estuviera interceptando y cacheando el tráfico, los cambios realizados por Cloudflare no habrían provocado la caída de mi web ni los errores Soft 404.
Agradecería que, en lugar de justificar la actuación de Telefónica/O2, se investigara a fondo este problema y se diera una explicación clara y transparente. Los usuarios merecemos saber qué está pasando con nuestro tráfico en Internet.
Por cierto, la respuesta de INCIBE-CERT, borrada por moderación (curioso, ¿no?), aunque no clasificaba el incidente como de seguridad, sí reconocía problemas de conexión entre Telefónica y Cloudflare.
¡Hasta luego!
(este ha sido mi último post)
Oscar
Buenas odlfg
No tengo nada claro el análisis que haces, no tiene mucho sentido.
Partamos por tu primer tracert que pusiste algo más arriba desde una conexión de O2. ¿Por qué está mal el tracert? Telefónica no está actuando como un MitM, Movistar está enrutando el tráfico por su red hacia le destino, sin más. Como cualquier otra conexión que uno haga, cuando su tráfico entra en la red del ISP que sea (sea red de origen, intermediaria o final), es dicha red la que va a enviar el tráfico por un lado o por otro según ese momento concreto, situación de la red, de sus peer... etc etc etc.
Esto es ni más ni menos como funciona Internet. El ISP te brinda la conexión, enviando el tráfico por su red hasta la siguiente red. Sin más. En el caso concreto de que el ISP tuviese un Peer con el destino final, nos ahorraríamos como es lógico redes intermedias. Una conexión VPN, por cierto, es una conexión indirecta donde todo el tráfico pasa igualmente por la red del ISP, la única diferencia es que el destino es diferente, en vez de ser la página X es la del servidor VPN, pero el tráfico enrutado por su red hacia el servidor VPN sigue las mismas normas que todos.
Decir o creer que Movistar/Telefónica actúa como MitM porque dependiendo del destino/horario/situación el tráfico se enrute por sus redes carece totalmente de lógica aquí. Máxime si tenemos en cuenta que la red de Telefónica es un Tier1 en Internet, es una red troncal, por la que pasa el tráfico de medio mundo. Como pueda serlo la de Level3, NTT, TATA... ver que el tráfico entra o sale de ellas es totalmente normal y habitual.
De echo, en tus propios tracert lo que se aprecia es que CloudFlare tiene un rendimiento bastante mejor cuando se está con Movistar, porque CloudFlare sí tiene un peer propio con Telefónica, mientras que con Orange tiene que pasar por un punto de intercambio, como es espanix, posiblemente porque desde sus conexiones es el camino más apropiado de ello. Por cierto, todo ello es información pública por supuesto
https://bgp.he.net/AS13335#_peers
Eso implica que lo más normal, rápido y eficiente para cualquier conexión desde la red de Movistar, es pasar el tráfico por lo general a la red troncal de Telefónica, y de esta a CloudFlare, pues tienen peer directo. No solo esto es un error, sino que es preferible, minimizando la latencia. Solo tienes que ver los resultados en tu tracert de una conexión a otra 🙂
Vamos, que me temo que es simplemente como funciona Internet, no existe ninguna anomalía en ello ni ningún problema de seguridad. Es como decir por ejemplo que espanix actúa de MitM porque el tráfico pasa por ellos. El 99% de las veces, a menos que el destino tenga un Peer directo con el propio ISP, el tráfico va a saltar por diferentes redes, a veces una red intermedia, a veces dos, a veces tres... y obviamente no es porque actúen como MitM, sino porque repito es como funciona Internet. Internet no es más que una red de redes, unas conectadas a otras conectadas a otras....
Saludos, y espero que quede algo más claro. En cualquier caso si te quedas con alguna duda que no te cuadre o lo que sea, lo comentamos igualmente.
Estimado Sr. de la Fuente:
Debemos insistir en que, desde INCIBE-CERT, no apreciamos indicios de que exista un incidente de seguridad que esté comprendido en nuestras funciones, que puede consultar en el siguiente enlace:
https://www.incibe.es/incibe-cert/incidentes/respuesta-incidentes
Insistimos en que su traza no demuestra que Telefónica esté secuestrando su tráfico, sino que está realizando una traza desde un recurso que usa su infraestructura al ser realizada desde una conexión a Internet que presta esta compañía, motivo por el que estas rutas estáticas no aparecen si sale a Internet por otro proveedor o a través de una VPN.
Además, y por la misma razón que exponíamos al principio, INCIBE-CERT no tiene capacidad de actuación directa sobre los recursos de las redes de telecomunicaciones ni tampoco la de actuar directamente contra una entidad pública o privada. Si cree que está siendo víctima de un [....] o delito, puede presentar una denuncia ante las Fuerzas y Cuerpos de Seguridad del Estado siguiendo las instrucciones de este enlace:
https://www.incibe.es/ciudadania/ayuda/denuncia
Recuerde que las denuncias presentadas de forma telefónica o electrónica deben firmarse presencialmente en un plazo máximo de 72 horas para que adquieran eficacia.
Un cordial saludo.
- --
INCIBE-CERT - CSIRT del Instituto Nacional de Ciberseguridad de España
https://www.incibe.es/incibe-cert
Servicio gratuito ofrecido de forma ininterrumpida (24x7). Puede valorarlo en https://www.incibe.es/incibe-cert/encuesta-satisfaccion-servicio-gestion-incidentes
Financiado por la Unión Europea - NextGenerationEU
Claves PGP: https://www.incibe.es/incibe-cert/sobre-incibe-cert/claves-publicas-pgp
====================================================================
INCIBE-CERT es el CSIRT Nacional de referencia en España para ciudadanos y entidades de derecho privado, así como proveedores de servicios digitales, operadores críticos y de servicios esenciales y otras entidades no incluidas en el ámbito subjetivo de aplicación de la Ley de Régimen Jurídico del Sector Público 40/2015; tal y como establece el Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información que transpone la Directiva (UE) 2016/1148 del Parlamento Europeo y del Consejo, de 6 de julio de 2016, relativa a las medidas destinadas a garantizar un elevado nivel común de seguridad de las redes y sistemas de información en la Unión.
====================================================================
En cumplimiento del Reglamento General de Protección de Datos de la UE (Reglamento UE 2016/679, de 27 de abril de 2016) le informamos que sus datos personales, corporativos (así como los incorporados a documentos adjuntos); y dirección de correo electrónico, podrán ser incorporados en nuestros registros con la finalidad derivada de obligaciones legales, contractuales o precontractuales o bien, para responder a sus consultas, pudiendo ejercitar sus derechos de acceso, rectificación, supresión, portabilidad, limitación del tratamiento y oposición en los términos establecidos en la legislación vigente y de manera gratuita mediante correo electrónico a dpd@incibe.es. Recordamos que los trabajadores tienen el derecho a la desconexión digital entendido como la libertad del trabajador a no tener que conectarse a ningún dispositivo digital o software corporativo, mientras esté en períodos de descanso o vacaciones, o fuera de horario laboral. El responsable del tratamiento es
la S.M.E. Instituto Nacional de Ciberseguridad de España M.P., S.A. Más información en nuestra web: https://www.incibe.es/proteccion-datos-personales y https://www.incibe.es/registro-actividad.
====================================================================
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEsc0PA25fZ79t5mlGDr1alK9E0w4FAmeh2n0ACgkQDr1alK9E
0w4c/g//XANTjn4e2ak6fZmO808uSY/jFAb3EsNBx5KT4i9gt4IL9gB55MTpbnOx
R0N5XTDQXoeq7zZtvUJaWP6F/W/eTIuZAWzu6MQT+geOicl28FEK84+ItUKv450D
BPcGcKvm7JdUxe7s0yMIXgQb6NXHPgoOTzslbfCOR3s6jPz0OMnX0/+sU1a9W8fF
kf2aEcBHl/Wa/+5FJfPmvwjZfrhUzpof7c6jYDivvl2YSjn0MI5/fzBF5CdVd35u
R4zGPRbpqTJYKn+khmGyrCzpSa84lXlnjJQIWYPMc0GZI0UYGn5xZiSSsOWPGTBB
CuE5JaMOra9n/fUjhW0cTq+BiDQeUu7giEsBIi900qfRa5t9fFRCU/AwlZAdKX9C
+xia5gjIbUkXcvLi3M9LkB75QWhUyxykJB8pRiNjBW/FWtxYFLjGKsiL8hP7HXIw
5U6oO8r7CBaYwMfk+HsqQ2fIrvtiGhShfJm2V3dJ5vOjhc9HsGiFHiyoTh1KKf3p
Umdzgbt7yLB7R58Me1NKGltNNojszNi5i6bSVtaYH9UPy9oInoYxgFjqxDrxU81e
SODCGD/LpdaAVUviZ3qgX+YpprdqWXpYF6I+vK0S/Te8fFoTYQCtGx1W08YoTpGl
JKGKnKe2xPjqdHfmPIXGvHh+WAbYYiYS1wxNXn7ggRf6szwc5xE=
=9ZuQ
-----END PGP SIGNATURE-----
