Introducción
Hay muchos factores que incrementan la latencia entre dos puntos, pero la principal es la distancia entre ellos. Secundariamente a esto, la ruta que elije tu dispositivo mediante tu ISP también influye mucho. En mi caso, la ruta desde donde vivo hasta mi droplet en New York está sumamente congestionada, produciendo pérdidas de paquetes en el camino. Ahorita nos ponemos a revisar eso.
Todos los caminos hacia Roma (New York)
Al usar mi red WireGuard no tuve muchos problemas puesto que la uso para cosas sencillas y ligeras, pero mediante un ping entre mi dispositivo y mi droplet, encontré un agujero de casi 210ms. Esto se refleja cuando quiero usar un túnel para VNC, pues incrementa la latencia y vuelve un fastidio utilizar ese tipo de tecnologías.
Una advertencia: Tras todo este paseo, solo seremos capaces de descubrir la causa de la latencia, pero probablemente poco podremos hacer más que pedir explicaciones a la operadora. Si aún quieres utilizar un escritorio remoto mediante WireGuard, usa xrdp, más tolerante a la latencia alta; o sin usar WireGuard, usa AnyDesk, súper útil en cualquier red. Hay más opciones para escritorio remoto, pero no me acuerdo ahora ni tengo ganas de investigar 😀
Algo más: Mi objetivo solo es tener menor latencia para probar otros servicios o mejorar los existentes. Por ejemplo, Nextcloud está lentísimo. También me interesa saber si puedo usar Moonlight para jugar de forma remota, pero debido a que mis pruebas están realizándose por plan de datos, no estimo que sea algo que utilice a corto plazo.
Lo importante de esto es hacer un rastreo de las rutas que toman tus paquetes antes de llegar a su destino, pero primero calculamos la latencia con un ping
ping google.com
Esto nos dirá cuál es la latencia hacia Google, pero luego debemos hacer un ping hacia nuestro VPS para hacer el cálculo
ping interlan.ec
En mi caso, tuve una latencia de 99ms a Google, pero a mi VPS una de 210ms
Esto se explica de manera sencilla en la distancia física que hay de un punto a otro. En mi caso, Google tiene servidores en Sudamérica, pero mi droplet de Digital Ocean está físicamente en New York, lo que significa que está más lejos y tiene que cruzar el océano para poder llegar.
Lo siguiente es calcular la pérdida de paquetes hacia el destino y ver qué IP utilizamos para llegar.
Está documentado que los ISP usan la ruta más barata, no la más eficiente, por lo que es posible que crucemos por una ruta que esté congestionada.
Para hacer este diagnóstico utilizaremos la herramienta MTR en Linux. Si quieres, puedes utilizar WinMTR que funciona igual solo que con interfaz gráfica preferente.
Voy a establecer primero la razón que me llevó a buscar este diagnóstico:
Tengo pérdida de paquetes hacia mi servidor, pero esto no pasa en toda mi red. Pasa en segmentos de mi red. Desde mi Larkbox, tengo 0% de pérdida, pero desde mi Win i7, tengo 45% de pérdida. Mi Larkbox está detrás de un router LinkSys que conecta por LAN al router del proveedor y mi Win i7 conecta desde el router LinkSys mediante un router Xiaomi 4A.
Al hacer un escaneo desde MTR obtenía resultados estables desde el router LinkSys, pero desde el Xiaomi 4A, tenía 45% de pérdida.
Me pude dar cuenta de que la IP de mi Larkbox es una IPv4 y la de mi Win i7 es una IPv4, aunque ambos routers están en modo bridge, así que había algo raro. Tras investigar un poco, resulta que el firmware del Xiaomi Mi Router 4A estaba en el firmware MiWiFi 3.0.12, que por un bug, bloquea el tráfico IPv6 aunque es perfectamente capaz de manejarlo. La solución sería cambiarlo a modo router, pero sería un fastidio para mí pues me obligaría a crear más subredes.
Para comprobar finalmente si esto es cierto, utilizo esta herramienta https://test-ipv6.com/index.html.es_ES que permite comprobar en cada dispositivo si es compatible con IPv6. En el LarkBox, el resultado fue positivo, pero en el Win i7 da esta respuesta «Su navegador parece tener dirección IPv6 real – pero evita usarlo. Estamos preocupados por esto.»
Debido a esto, el tráfico generado por mi dispositivo Win i7, evita la ruta de la IPv6, más holgada, pasando por CGNAT (IPv4) de mi proveedor, actualmente congestionada, provocando pérdida de paquetes.
Para probar qué ruta está es la que están tomando los paquetes, utilizamos la herramienta WinMTR.
Con esta herramienta, apuntamos a la IP o dominio que deseamos analizar y estudiamos la estructura de la ruta, los paquetes perdidos y la latencia.
En mi caso, una vez resuelto lo del IPv6, aún mantengo una latencia alta, pero sin pérdida de paquetes entre mi casa y el proveedor, pero sí con un 65% de pérdida de paquetes entre el proveedor y el puente continental que lleva hasta Miami y desde allí hasta New York.
Conclusiones
Esta serie de pasos que hemos tomado para detectar la causa de la latencia no nos lleva a una solución, sino a descubrir problemas que no nos habíamos fijado. En este caso, un router con un Firmware obsoleto que bloquea el paso por IPv6. Corregir este error ayuda a reducir muchísimo la latencia en servicios cercanos, como Google o juegos en línea, pero si los servicios se encuentran físicamente lejanos, no hay cambio apreciable.
Teóricamente puedes hablar con tu ISP para poder acordar una ruta un poco más costosa pero más rápida, aunque en mi caso no lo veo necesario. Eso sí, tengo curiosidad. Mi VPS se encuentra en New York, que vendría siendo un buen punto intermedio para todo el mundo, pero mi latencia desde mi casa es de 204ms. Es bastante. Me gustaría saber qué ping hay desde otras partes del mundo, así que si alguien quiere, puede enviarme el valor en ms de la latencia que le da el comando ping y, si así lo prefiere, también el país desde donde lo ejecuta. Según yo, debería tener tiempos de reacción decentes para lugares como Estados Unidos, pero no estoy seguro de qué tan bien le va en España.
Como es un dato un poco sensible, puedes enviármelo por correo a drk0027@interlan.ec, pero como es un fastidio escribir correos, dejaré un formulario abierto que enviará esos datos directo a mi bandeja de correo de forma anónima.
