Jami en Rusia: problemas del mensajero P2P y soluciones técnicas

Jami en Rusia: Obstáculos de red del mensajero P2P y sus soluciones

El mensajero descentralizado Jami enfrenta serios problemas en las redes rusas debido al CGNAT y los bloqueos, lo que hace que las conexiones directas peer-to-peer sean poco fiables. A pesar de su potencial técnico, la configuración actual del protocolo ICE y la dependencia de servidores TURN no pueden con las restricciones de red actuales. Este artículo desglosa los problemas de ingeniería y propone pasos concretos para reformar la arquitectura y lograr un rendimiento impecable.

Problemas de conexiones P2P en redes rusas

La principal inestabilidad de Jami proviene de cómo los proveedores de internet rusos gestionan su infraestructura. El CGNAT (NAT de grado operador), común en operadoras móviles, priva a los usuarios de direcciones IP públicas, bloqueando las conexiones entrantes. El NAT simétrico es especialmente problemático, ya que los trucos estándar como STUN y el hole punching UDP suelen fallar.

Principales obstáculos de red:

• Ausencia de IP públicas para usuarios móviles.
• El protocolo ICE tiene dificultades tras CGNAT.
• Servidores TURN como turn.jami.net son inaccesibles en Rusia.
• Sistemas DPI detectan fácilmente el tráfico TURN sin soporte DTLS/TLS.

Fallos en la arquitectura actual

Jami depende de componentes centralizados, lo que choca con su filosofía descentralizada. Los nodos de arranque DHT necesarios para unirse a la red pueden bloquearse, y los servidores TURN son puntos únicos de fallo. El tráfico enrutado por TURN añade latencia y es vulnerable a bloqueos, algo crítico bajo las regulaciones de internet en Rusia.

Comparación de enfoques de relés:

• TURN actual: Servidor centralizado, fácil de bloquear, aumenta la latencia.
• Relé P2P: Nodos de usuarios con IP públicas comparten la carga, distribuida.
• Redes mesh: Enrutamiento dinámico vía múltiples nodos, máxima resiliencia.

Soluciones técnicas para modernizar Jami

Superar estos límites de red requiere una actualización completa del protocolo y la arquitectura. Prioridad máxima: eliminar la dependencia de TURN y potenciar las conexiones directas.

Nivel 1: Potenciar conexiones P2P

• Priorizar IPv6: Forzar direcciones IPv6 en candidatos ICE para evitar NAT. Las redes móviles rusas ya impulsan IPv6, lo que podría permitir conexiones directas para hasta el 70% de usuarios.
• UPnP agresivo: Aumentar intentos de mapeo de puertos y reducir intervalos de keepalive a 15 segundos para mantener vivas las sesiones NAT.
• ICE optimizado para CGNAT: Añadir inferencia de puertos para predecir el comportamiento de NAT simétrico y forjar enlaces directos.

Nivel 2: Protocolos de transporte de nueva generación

Cambiar a QUIC sobre TCP/UDP para:

• Recorrido NAT más fluido con keepalives integrados y migración de conexiones.
• Multiplexación sin bloqueo head-of-line.
• Resistencia a DPI gracias al cifrado TLS 1.3 incorporado.
• Transiciones fluidas entre Wi-Fi y datos móviles.

Nivel 3: Relés P2P vía pares de relé

Implementar un sistema donde nodos con IP pública relayen para usuarios CGNAT:

• Nuevo tipo de candidato ICE: peer_relay.
• Publicar disponibilidad de relés en DHT.
• Cifrado de extremo a extremo incluso a través de relés.
• Red autoorganizada: más usuarios con IP pública, más robusta la red.

Nivel 4: Potenciar el uso de DHT

Integrar libtorrent para transferencias de texto y archivos totalmente descentralizadas:

• DHT para distribución de datos, no solo señalización.
• Sin servidores centralizados para tráfico no multimedia.
• Mayor resiliencia de red.

Nivel 5: Enrutamiento mesh

A largo plazo: Construir una superposición mesh con enrutamiento dinámico:

• Protocolos como BATMAN u OLSR.
• Rutas autoóptimas a través de múltiples nodos.
• La red se fortalece con cada nuevo usuario.

Nivel 6: Eliminar TURN del código

Una vez implementados los niveles previos, suprimir TURN por completo:

• Eliminar candidatos de relé de ICE.
• Quitar ajustes TURN de la interfaz.
• Compilar PJSIP sin TURN para reducir la superficie de ataque.

Optimización: Hole punching con coordinadores

Para reducir el tráfico de relés, usar nodos con IP pública solo como coordinadores para handshakes iniciales. Tras el hole punching, el relé se desconecta, pasando a P2P puro. Esto combina la fiabilidad de relés con la eficiencia directa.

Lecciones clave

• El CGNAT en redes móviles rusas es el mayor obstáculo para P2P en Jami.
• La dependencia de TURN genera vulnerabilidades y retrasos.
• IPv6 y QUIC resuelven la mayoría de problemas de NAT y bloqueos.
• Los relés P2P vía pares son una alternativa descentralizada a TURN.
• Eliminar TURN por completo debe ser el objetivo final del proyecto.

— Editorial Team