BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate
Fibra

No puedo entrar en la web kinguin.net ni funciona el comando tracert desde Digi

1
Makrod
✎
⋮

Me esta pasando algo muy extraño y es que no puedo entrar en esta pagina webkinguin.net. Que yo sepa no tiene nada ilegal. Es para comprar keys de juegos.

Lo mas extraño todavía o no se que ocurre es que no puedo usar el comando tracert, porque solo hace un salto.

Solo tengo problemas con esa página web.

Cuando entro sale este error ERR_CONNECTION_REFUSED, todas las demás funcionan bien.

¿De que será el problema?

Dejo el pequeño tracert que me dejo hacer y otro banda ancha por si se necesita, estoy con la compañía Digi.

Captura de pantalla 2024-05-10 120923
lhacc
2
⋮

Pues parece que cual sea el servidor DNS que usas está resolviendo kinguin.net a [::1]. Prueba a cambiar el servidor DNS.

🗨️ 8
✖
Makrod
⋮

Estoy usando las de Digi pero pruebo a cambiarlas y contesto a ver si funciona.

Edito.

Ya funciona pues algo anda mal con las DNS de Digi y esa pagina por que solo me pasa ahí.

Gracias por la ayuda.

🗨️ 7
✖
Walter Bishop
1
⋮

Acabo de probar por curiosidad y a mí con Movistar me dice "HTTP 451 – File unavailable For Legal Reasons". Con WARP sin problema. No sé si tendrá algo que ver.

🗨️ 1
✖
lordman
⋮

A mi me dice lo mismo.

Aokromes
⋮

yo no lo llamaria algo anda mal, si no que han ido al metodo comodon, editar la DNS para cumplir un requerimiento legal

🗨️ 4
✖
Makrod
⋮

Sigo sin entender que tiene esa web de ilegal.

🗨️ 3
✖
kaleth
1
⋮
lhacc
1
⋮
🗨️ 1
✖
Makrod
⋮
vukits
⋮

usar mejor clavecd.es :)

Makrod
3
⋮

La mano negra de la liga ya hasta cierra las paginas de videojuegos XD

Bilbokoa
⋮

Acabo de entrar con O2 sin problemas.

Krev Le Terro
⋮

no funciona con Digi, tampoco con Vodafone (fibra tb), el browser da un warning de seguridad. Funciona con un VPN pero con un servidor fuera de españa

DerrilMC
⋮

Con Digi no funciona pero todo bien con Orange.

pepejil
0
⋮

Mola. Digi para capar simplemente intercepta la petición y la resuelve como localhost en sus DNS.

Unos genios.

🗨️ 1
✖
PezDeRedes
⋮

Montan chapuzas en cosas importantes, pues imagina en la maquinaria de censura.

PezDeRedes
⋮

Desde Movistar no puedo acceder, con Cloudflare Warp sí.

Skep32
⋮

En mi caso con Movistar desde Chrome bien, pero desde Internet de Samsung me dice se ha restablecido la conexión.

aliveintheseptictank
⋮

Con Digi y DNS cloudflare funciona perfectamente

🗨️ 1
✖
Bilbokoa
⋮

Acabo de volver a probar otra vez, y sigue entrando bien, con O2 y DNS de Movistar.

Fassou
⋮

A mi me pasó hace cosa de un mes, que un día estuve mirando el precio de un producto y al siguiente no cargaba la web.

Si tiraba un tracert se quedaba en un salto a la 127.0.0.1

Lo más raro era que en Firefox no cargaba, pero en Chrome sí … (WTF)

Acabé mirando DNS mejores ( tenía los típicos de Google y alguno de Cloudflare ), y lo solucioné para todos lo navegadores al cambiarlos.

Salu2!

Uklosk
⋮

A mi desde hace unas semanas me están dando problemas múltiples webs, es un poco aleatorio.

Hoy por ejemplo me ha estado dando problemas github.com, en algunos intentos tardaba varios segundos en establecer la conexión y empezar a cargar la página, en otros directamente agotaba el tiempo de conexión al servidor.

Haciendo un traceroute se veía perfectamente como se quedaba a mitad de camino agotando varios intentos de conexión.

No tiene nada que ver con el DNS, la resolución de DNS con cloudflare es inmediata.

Tirando con ProtonVPN saliendo por Madrid también es inmediata la conexión, así que está claro que es un problema de enrutamiento de la red de Digi, y me está empezando a mosquear porque es impredecible y obviamente afecta a todos los dispositivos de la casa. Miedo me da tener que ponerme a discutir esto con uno de sus "técnicos"…

Tengo Fibra Digi 10GB en Madrid, por si alguien experimenta algún problema similar.

🗨️ 8
✖
Aokromes
⋮

personalmente uso github MUCHO y no he notado esos problemas con fibra 1 Gbps indirecta con DNS 1.0.0.1 y 9.9.9.9 y sus versiones IPv6.

🗨️ 6
✖
Uklosk
⋮

¿Si haces un traceroute a github.com pasas por rumanía?

Por ejemplo: tools.keycdn.com/geo?host=86.120.71.48

Me da que tienen el enrutamiento completamente roto, para ir a Frankfurt (github.com) pasa por Rumanía y luego por Reino Unido, un despropósito.

imagen
🗨️ 5
✖
Aokromes
⋮

esa IP .ro no esta en rumania, es fisicamente imposible tener 1ms de latencia hasta rumania, esa IP esta en madrid, y si, paso por esa IP. (la latencia de un tracert mio ahora no te valdra como ejemplo por que estoy transfiriendo un monton de teras) xd

1   125 ms   116 ms    93 ms  192.168.1.1
  2   238 ms    39 ms    23 ms  10.0.0.1
  3   215 ms   233 ms   163 ms  172.16.0.1
  4   298 ms   278 ms    78 ms  10.220.96.2
  5   126 ms     8 ms     8 ms  86-120-71-48.rdsnet.ro [86.120.71.48]
  6   326 ms   249 ms   119 ms  10.220.203.191
  7     *        *        *     Tiempo de espera agotado para esta solicitud.
  8   110 ms   127 ms   144 ms  ae1.cs1.ams17.nl.eth.zayo.com [64.125.29.78]
  9    40 ms    53 ms    46 ms  ae2.cs1.fra6.de.eth.zayo.com [64.125.29.58]
 10    42 ms    44 ms    43 ms  ae1.mcs1.fra6.de.eth.zayo.com [64.125.29.57]
 11    50 ms    97 ms    39 ms  82.98.193.31.IPYX-270403-001-ZYO.zip.zayo.com [82.98.193.31]
 12     *        *        *     Tiempo de espera agotado para esta solicitud.
 13     *        *        *     Tiempo de espera agotado para esta solicitud.
 14    65 ms    41 ms    84 ms  lb-140-82-121-4-fra.github.com [140.82.121.4]
🗨️ 2
✖
Uklosk
⋮
🗨️ 1
✖
lhacc
⋮
skgsergio
⋮

Tengo un dominio .as sirviendo contenido desde Frankfurt y no desde America Samoa. Que sea .ro no significa que sea rumania. Es más si fuese rumania no te daría 1ms.

No veo lo de Reino Unido en tu traza la verdad. De hecho la latencia al destino final (mejor si haces un ping) me da la impresión que va bastante directo.

Mira esta traza desde O2 en Madrid:

root@OpenWrt:~# mtr 140.82.121.4 -c4 -w
Start: 2024-05-11T09:11:23+0200
HOST: OpenWrt                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.144.1                                         0.0%     4    1.8   2.0   1.7   2.5   0.4
  2.|-- 173.red-81-46-66.customer.static.ccgg.telefonica.net  0.0%     4    2.2   2.3   2.2   2.4   0.1
  3.|-- 82.red-81-46-67.customer.static.ccgg.telefonica.net  75.0%     4    3.4   3.4   3.4   3.4   0.0
  4.|-- 205.red-81-46-0.customer.static.ccgg.telefonica.net   0.0%     4    5.0   3.9   3.5   5.0   0.8
  5.|-- ???                                                  100.0     4    0.0   0.0   0.0   0.0   0.0
  6.|-- ???                                                  100.0     4    0.0   0.0   0.0   0.0   0.0
  7.|-- ???                                                  100.0     4    0.0   0.0   0.0   0.0   0.0
  8.|-- ae10.cr0-mad5.ip4.gtt.net                             0.0%     4   10.6  10.6  10.6  10.6   0.0
  9.|-- ae21.cr2-fra6.ip4.gtt.net                             0.0%     4   35.9  36.4  35.0  39.5   2.1
 10.|-- 87.119.94.70                                          0.0%     4   43.6  43.4  43.2  43.6   0.2
 11.|-- ???                                                  100.0     4    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                                                  100.0     4    0.0   0.0   0.0   0.0   0.0
 13.|-- lb-140-82-121-4-fra.github.com                        0.0%     4   34.7  34.7  34.7  34.8   0.1
🗨️ 1
✖
Uklosk
⋮
aalmenar
⋮

El traceroute es muy bonito pero no es una herramienta de depuración eficiente de una conexión. Primero y principal por que va por udp y depende que el destino tenga abierto ciertos puertos. Segundo no son paquetes que se prioricen a nivel de routing incluso verás “perdidas” en el camino por que habrá equipos de routing que pasan de usar su cpu para contestar. Tercero no sabes el camino de vuelta desde el otro lado, con routing asimétrico que es lo normal no ves por qué puede haber aumento de latencia de un punto a otro. mtr y winmtr adolecen del segundo y tercer punto pero no del primero, normalmente pasan cortafuegos que tienen permitido icmp pero sigues teniendo el problema de no saber cuál es el camino de vuelta por lo que nunca sabrás si no llegas si el problema está en la vuelta desde donde deja de responder o en tu lado que no llega.

Por estas razones se inventaron los looking glass.

Después de todo esto, las ips están registradas usualmente en el país de donde es el operador y operan su red global usando esas ips, no significa que vayan a tal país y vuelvan.

image

Viendo esta traza desde Digi, no hay más que ver que 42ms de latencia no sería normal si saliera de madrid a rumanía a usa a frankfurt y vuelve a usa.

1