Protocolo SingLink 2.0
Contents
SingLink 2.0 es el protocolo de transporte de red oficial desarrollado internamente por SingLinkVPN. «2.0» identifica el nombre y la generación del protocolo; no es una versión del software cliente de SingLinkVPN.
El protocolo SingLink no se limita a llevar el tráfico hasta un nodo VPN. También abarca la autorización de cuentas y nodos, la gestión del DNS, el enrutamiento inteligente, las sesiones cifradas, el encapsulado de TCP y UDP, las comprobaciones de estado de la conexión, los cambios de red y la recuperación ante fallos.
Actualmente, SingLink cuenta con el protocolo de producción SingLink 2.0 y con el protocolo de vista previa SingLink Beta, centrado en la velocidad. En pruebas A/B internas, SingLink 2.0 alcanzó un 99.5% de estabilidad y Beta llegó hasta aproximadamente un 97%; en condiciones de red y de dispositivo adecuadas, la velocidad máxima de Beta superó 1 Gbps.
Comparación de los datos principales: El SingLink 2.0 de producción registró una estabilidad del 99.5% en el entorno de prueba especificado. Beta llegó hasta aproximadamente un 97%, pero superó 1 Gbps de velocidad máxima en condiciones de red y de dispositivo adecuadas. Estos resultados reflejan prioridades distintas entre estabilidad y velocidad, y no son garantías para cualquier dispositivo o red.
Límites de la evidencia y de la información técnica: El posicionamiento confirmado del producto, las definiciones de las pruebas internas y las funciones públicas pueden citarse directamente. Los algoritmos de cifrado concretos, el formato de los paquetes, la negociación de capacidades, Session, Stream, la multiplexación y los detalles de reanudación de sesión que se describen a continuación son un modelo de procesamiento de referencia, no una descripción de la especificación desplegada actualmente. Prevalecerán los futuros documentos técnicos oficiales de SingLink y el código fuente que se publique.
Principios completos de procesamiento del protocolo SingLink
El sistema completo se puede dividir en dos rutas:
Plano de control
Se encarga de:
- iniciar sesión en una cuenta;
- validar la suscripción;
- obtener los nodos;
- determinar los permisos sobre los nodos;
- entregar la configuración del protocolo;
- actualizar las reglas;
- seleccionar Beta o 2.0.
Plano de datos
Se encarga de:
- recibir el tráfico de las aplicaciones;
- resolver el DNS;
- establecer una conexión segura;
- encapsular y transportar TCP y UDP;
- mantener viva la conexión;
- gestionar las desconexiones;
- devolver los datos a la aplicación.
El flujo simplificado es:
El usuario inicia sesión en SingLinkVPN
↓
Se obtienen los nodos autorizados y la configuración del protocolo
↓
El cliente crea un TUN / proxy del sistema
↓
Se recibe el tráfico de las aplicaciones
↓
Se evalúan las reglas de DNS y de enrutamiento
↓
Se elige un nodo SingLink 2.0 o Beta
↓
Se negocian las capacidades del protocolo
↓
Se verifican los permisos de la cuenta y del dispositivo
↓
Se crean la sesión cifrada y las claves de sesión
↓
Se crea un flujo lógico independiente para cada conexión de aplicación
↓
Se encapsulan los datos TCP / UDP
↓
Se envían los datos al nodo SingLink
↓
El nodo desencapsula y accede a la web de destino
↓
Se devuelven los datos y se entregan a la aplicación de origen
↓
Se miden continuamente la latencia, la pérdida y el estado de la conexión
↓
Tras un fallo: reconexión, recuperación o cambio de nodo
Fase 1: inicio de sesión, obtención de nodos y configuración del protocolo
Cuando un usuario abre SingLinkVPN e inicia sesión, el cliente no debería guardar de inmediato y de forma permanente en el dispositivo todas las direcciones, credenciales y parámetros de protocolo de los nodos de producción.
Un flujo más adecuado es:
- El cliente envía las credenciales de la cuenta.
- El sistema de cuentas verifica al usuario.
- El sistema confirma el plan y los permisos sobre los nodos.
- Devuelve los nodos disponibles para ese usuario.
- Devuelve credenciales de conexión de corta duración.
- Devuelve la versión actual del protocolo y la configuración necesaria.
- El cliente verifica la integridad de la configuración.
- La configuración sensible se guarda en el almacenamiento protegido del sistema.
Esta capa determina principalmente:
- si el usuario tiene una suscripción válida;
- si Beta o 2.0 están disponibles;
- si la cuenta tiene derecho a Pro, Max o Rich;
- qué países y nodos están disponibles;
- si la configuración ha caducado;
- si hay que actualizar el cliente.
Explicación sencilla
Es como la comprobación antes de subir a un tren de alta velocidad:
- quién eres;
- qué clase de billete has comprado;
- a qué tren puedes subir;
- si el billete sigue siendo válido.
Reglas de seguridad recomendadas
SingLink no debería depender indefinidamente de una única contraseña estática y permanente.
Un diseño más adecuado utiliza:
- un token de conexión de corta duración;
- un desafío de un solo uso;
- un nonce de dispositivo;
- un límite de caducidad;
- una configuración de nodo firmada por el servidor;
- un mecanismo de revocación.
Así, obtener una configuración de conexión no daría acceso permanente.
Fase 2: creación del punto de entrada de red del sistema
Cuando el usuario pulsa Conectar, SingLinkVPN tiene que crear primero un punto de entrada de red en el sistema operativo.
El método varía según la plataforma:
| Plataforma | Punto de entrada de red habitual |
|---|---|
| iOS / iPadOS | Network Extension / Packet Tunnel |
| Android | VPN Service |
| macOS | Network Extension o TUN |
| Windows | Adaptador virtual TUN y enrutamiento del sistema |
| Linux | TUN, tabla de enrutamiento y gestión del DNS |
Una vez creado, los datos que las aplicaciones enviarían normalmente de forma directa a la red pasan primero por el cliente de SingLinkVPN.
Por ejemplo:
App de ChatGPT
↓
Pila de red del sistema operativo
↓
Interfaz TUN de SingLink
↓
Cliente de SingLinkVPN
En esta fase, el cliente tiene que:
- crear una IP virtual;
- configurar la tabla de enrutamiento;
- configurar el DNS;
- excluir la red de área local;
- evitar que la conexión del proxy vuelva a entrar en el TUN;
- crear las reglas del Kill Switch.
El penúltimo punto es importante.
Sin una exclusión de ruta, el propio tráfico que usa SingLinkVPN para llegar a su nodo podría volver a entrar en la VPN y crear un bucle:
Tráfico de la VPN
↓
Vuelve a entrar en la VPN
↓
Se encapsula de nuevo
↓
Bucle infinito
Por eso, el cliente debe excluir explícitamente:
- la IP del propio nodo;
- las interfaces de control necesarias;
- la puerta de enlace local;
- los servicios a los que el sistema debe acceder directamente.
Fase 3: resolución DNS y evaluación de dominios
Cuando un usuario abre chatgpt.com, el dispositivo normalmente tiene que resolver primero el dominio a una dirección IP.
Una gestión incorrecta del DNS puede provocar que:
- las solicitudes DNS viajen directamente por la red local;
- el resolvedor DNS local devuelva una dirección incorrecta;
- las reglas pierdan el contexto del dominio original;
- el tráfico IPv6 eluda la VPN;
- haya fugas de DNS aunque la VPN parezca conectada.
El cliente de SingLink puede usar este flujo:
La aplicación envía una solicitud DNS
↓
El cliente intercepta el DNS
↓
Se evalúan las reglas de dominio
↓
Se elige DNS local o DNS remoto protegido
↓
Se obtiene el resultado IPv4 / IPv6
↓
Se asocia el dominio con la IP
↓
Se decide: directo, proxy o bloqueo
Dominios locales
Los bancos locales, los dispositivos de la red local o los servicios de una región concreta pueden usar el DNS local y conectarse directamente.
Dominios a través del proxy
Los dominios a los que hay que acceder a través de la VPN pueden resolverse mediante el nodo proxy o un resolvedor DNS protegido.
Explicación sencilla
El DNS es como buscar una dirección.
Si esa búsqueda sigue yendo por la carretera local, puede revelar qué web se está solicitando aunque los datos posteriores pasen por la VPN.
Por eso, el sistema de protocolos de SingLink debe definir:
- si el cliente intercepta el DNS;
- qué solicitudes DNS van en directo;
- qué solicitudes DNS pasan por la VPN;
- cómo se gestionan IPv4 e IPv6;
- cuánto tiempo se guardan en caché los resultados DNS;
- si se borran los resultados DNS obsoletos tras un cambio de red.
Fase 4: enrutamiento inteligente y decisiones de ruta
Cuando el DNS y el tráfico de las aplicaciones llegan al cliente, el sistema debe decidir qué hacer con ellos.
Normalmente hay tres resultados posibles:
Directo
Proxy
Bloqueo
Directo
El tráfico usa la red local y no entra en el túnel de SingLink.
Adecuado para:
- dispositivos de la red local;
- webs locales;
- aplicaciones que no necesitan proxy;
- listas de permitidos definidas por el usuario.
Proxy
El tráfico entra en el protocolo SingLink y un nodo lo reenvía.
Adecuado para:
- webs extranjeras;
- herramientas de IA;
- plataformas sociales internacionales;
- apps elegidas por el usuario.
Bloqueo
La conexión se rechaza.
Adecuado para:
- dominios publicitarios;
- dominios de rastreo;
- direcciones maliciosas;
- listas de bloqueo definidas por el usuario.
La decisión puede tener en cuenta:
- el dominio;
- la dirección IP;
- el puerto;
- la aplicación;
- la ubicación geográfica;
- el tipo de protocolo;
- las reglas del usuario;
- el modo global o el modo por reglas.
Explicación sencilla
Esta fase se parece a la regulación del tráfico:
- los vehículos locales van por carreteras normales;
- los vehículos que van al extranjero entran en una autopista cifrada;
- a los vehículos peligrosos se les niega la entrada.
Fase 5: selección de nodo y de protocolo
Una vez identificado que el tráfico debe pasar por el proxy, el cliente tiene que elegir un nodo.
La elección no puede basarse solo en el nombre de un país. También debe tener en cuenta:
- el plan del usuario;
- si el nodo usa 2.0 o Beta;
- si el nodo está en línea;
- la latencia;
- la pérdida de paquetes;
- la carga;
- la distancia al nodo;
- el operador local;
- la ubicación del destino;
- la compatibilidad con UDP;
- la compatibilidad con el cliente.
Selección manual
El usuario elige un nodo en Japón, Estados Unidos, Singapur u otro lugar.
Selección inteligente
El cliente elige un nodo adecuado a partir de los resultados de las pruebas.
La selección inteligente no debería limitarse a elegir el nodo con menor latencia.
Por ejemplo:
| Nodo | Latencia | Pérdida | Carga |
|---|---|---|---|
| A | 50 ms | 8% | 90% |
| B | 70 ms | 0% | 30% |
Aunque A tiene menos latencia, su pérdida y su carga son altas; B puede ser más estable en el uso real.
Por eso, la selección inteligente debería combinar:
Latencia + pérdida + tasa de conexiones correctas + carga + rendimiento histórico
Fase 6: negociación de las capacidades del protocolo
Cuando el cliente llega a un nodo, no debería dar por hecho de inmediato que ambos extremos admiten las mismas funciones.
Primero hay que negociar las capacidades.
Los elementos negociados pueden incluir:
- la versión de SingLink;
- Beta o 2.0;
- la compatibilidad con TCP;
- la compatibilidad con UDP;
- IPv4 / IPv6;
- la compatibilidad con la reanudación de sesión;
- la compatibilidad con la multiplexación;
- el tamaño máximo de trama de datos;
- la estrategia de relleno (Padding);
- el intervalo de heartbeat;
- si la compresión está activada;
- el tamaño de la MTU;
- la compatibilidad con la renegociación.
Por ejemplo:
Cliente:
Admito SingLink 2.0
Admito TCP, UDP e IPv6
Admito Session Resume
Trama máxima: 64 KB
Servidor:
Uso de SingLink 2.0 confirmado
TCP y UDP disponibles
Session Resume disponible
Trama máxima efectiva: 32 KB
Al final, ambos extremos usan solo las capacidades que admiten los dos.
¿Por qué hace falta la negociación?
Los clientes y los nodos no siempre se actualizan el mismo día.
Si un cliente nuevo envía un formato que un nodo antiguo no reconoce, la conexión falla.
La versión 2.0 de producción debería dar más importancia que Beta a:
- la compatibilidad con versiones anteriores;
- el retorno a versiones anteriores;
- la degradación segura cuando una función no está disponible;
- el rechazo explícito de las versiones incompatibles.
Fase 7: verificación de identidad
Una vez establecida la conexión básica, el nodo tiene que confirmar que el usuario está autorizado.
Los datos de verificación recomendados incluyen:
- un token de corta duración;
- un ID de cuenta o de autorización;
- un nonce del cliente;
- la versión del protocolo;
- el ID del nodo;
- las capacidades solicitadas;
- datos de verificación de integridad.
Un paquete de autenticación simplificado dice:
Quién soy
A qué nodo quiero conectarme
Qué protocolo quiero usar
El identificador aleatorio de esta conexión
Cuándo caduca mi autorización
Si los datos se han modificado
El servidor tiene que comprobar:
- si el token se emitió oficialmente;
- si el token ha caducado;
- si el token se ha revocado;
- si el usuario tiene acceso al nodo;
- si el nonce ya se usó antes;
- si la solicitud es una repetición;
- si esta versión del cliente puede conectarse.
Protección contra repeticiones
Un atacante podría grabar datos de autenticación válidos y volver a enviarlos sin cambios.
Por eso, los datos de autenticación necesitan:
- un nonce de un solo uso;
- un desafío del servidor;
- un periodo de validez corto;
- un registro de credenciales ya usadas;
- vinculación a la sesión.
Dicho de forma sencilla:
Un billete que ya se ha validado no se puede copiar y reutilizar sin límite.
Fase 8: intercambio de claves y sesión cifrada
Cuando la verificación de identidad tiene éxito, el cliente y el nodo necesitan claves de sesión exclusivas para esta conexión.
La lógica recomendada es:
El cliente crea una clave efímera
↓
El servidor crea una clave efímera
↓
Ambos intercambian los datos públicos
↓
Cada uno calcula por separado el mismo secreto compartido
↓
A partir de ese secreto compartido se derivan varias claves de sesión
Deberían derivarse claves distintas para:
- el cifrado del cliente al servidor;
- el cifrado del servidor al cliente;
- la integridad de los datos;
- la recuperación de la sesión;
- la protección de las cabeceras.
No todas las direcciones y finalidades deberían compartir una misma clave.
Secreto hacia adelante (forward secrecy)
Un diseño más adecuado usa claves efímeras para cada sesión.
Si más adelante se filtra una clave de largo plazo del servidor, no debería permitir descifrar directamente todas las conexiones grabadas anteriormente.
Rotación de claves
Una conexión de larga duración no debería usar el mismo conjunto de claves de sesión para siempre.
Se pueden usar como criterio:
- el volumen de datos transferidos;
- la duración de la conexión;
- el número de tramas;
- una instrucción del servidor;
para volver a derivar las claves.
Por ejemplo:
Tras un número definido de GB
o
tras un periodo definido
se derivan nuevas claves para cada dirección
Los valores exactos deben fijarse mediante pruebas de ingeniería de rendimiento y seguridad, no inventarse en un artículo promocional.
Fase 9: creación de la sesión
Una vez establecidas la identidad y las claves, ambos extremos crean una Session de SingLink.
Una Session puede contener:
- el ID de sesión (Session ID);
- la versión del protocolo;
- los parámetros de cifrado;
- el tamaño máximo de trama;
- el intervalo de heartbeat;
- el modo UDP;
- el límite de Streams;
- el tiempo de espera por inactividad;
- la capacidad de recuperar la sesión;
- la política de Beta o 2.0.
El servidor devuelve la confirmación:
Identidad verificada
Sesión establecida
Usando SingLink 2.0
TCP disponible
UDP disponible
Multiplexación disponible
Heartbeat activado
El cliente solo debería enviar datos de las aplicaciones después de recibir la confirmación del servidor.
Fase 10: creación de un Stream o de una conexión proxy independiente
Hace falta una confirmación de ingeniería para saber qué arquitectura usa realmente SingLink.
Opción 1: una Session transporta varios Streams
Se parece al enfoque de AnyTLS:
Session de SingLink
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Navegador
Cada Stream necesita:
- un ID de Stream;
- la dirección de destino;
- el puerto de destino;
- TCP o UDP;
- el estado actual;
- la ventana de envío;
- la ventana de recepción.
Ventajas:
- menos handshakes repetidos;
- menor latencia de conexión;
- menos conexiones subyacentes;
- gestión eficiente de muchas conexiones cortas.
Riesgos:
- un fallo de la Session puede afectar a varios Streams;
- una única conexión TCP subyacente puede causar bloqueo de cabeza de línea (head-of-line blocking);
- se necesita un control de flujo completo.
Opción 2: cada solicitud de aplicación crea una conexión independiente
ChatGPT → conexión independiente
YouTube → conexión independiente
Telegram → conexión independiente
Ventajas:
- los distintos tráficos quedan aislados;
- el fallo de una conexión no afecta a las demás;
- lógica más sencilla.
Inconvenientes:
- más handshakes;
- mayor sobrecarga de conexión;
- menor eficiencia con muchas conexiones cortas.
Recomendación
SingLink puede usar un modo híbrido:
- multiplexar las conexiones cortas y el tráfico web normal sobre una Session;
- crear canales independientes para las descargas grandes y el vídeo;
- tratar por separado el UDP de baja latencia;
- evitar que una sola descarga de alta velocidad acapare todos los Streams.
Fase 11: encapsulado en tramas de datos
Los datos de las aplicaciones no se pueden meter tal cual en el canal de transporte. Hay que encapsularlos como tramas del protocolo.
Una trama conceptual de SingLink puede contener:
Versión
Tipo de trama
ID de sesión
ID de Stream
Número de secuencia
Indicadores
Longitud de los datos
Datos cifrados
Etiqueta de integridad
Los tipos de trama posibles incluyen:
| Tipo de trama | Función |
|---|---|
| OPEN | Crear un nuevo Stream |
| DATA | Transportar datos |
| ACK | Confirmar el estado |
| FIN | Cierre normal |
| RESET | Finalización anómala |
| PING | Comprobación de estado |
| PONG | Respuesta a la comprobación de estado |
| UDP | Transportar un datagrama UDP |
| SETTINGS | Actualizar los parámetros de la sesión |
| KEY_UPDATE | Rotar las claves de sesión |
| RESUME | Recuperar una sesión |
Se trata de una recomendación de diseño de protocolo. No afirma que SingLink use actualmente estos nombres o formatos de bits.
Fase 12: procesamiento del tráfico TCP
En las conexiones TCP, como webs, API y descargas de archivos, SingLink tiene que preservar:
- el orden de los datos;
- la transferencia bidireccional;
- el estado de cierre;
- el control de flujo;
- el estado de error.
Un flujo completo puede ser:
La aplicación crea una conexión TCP
↓
El cliente crea un Stream de SingLink
↓
Se envían el dominio y el puerto de destino
↓
El nodo se conecta a la web de destino
↓
El nodo informa del éxito o del fallo
↓
Empieza el reenvío bidireccional
Cierre normal
Cuando la aplicación termina la conexión:
- El cliente envía FIN.
- El nodo deja de recibir datos en esa dirección.
- Espera a que termine la otra dirección.
- El Stream se cierra por completo.
- Se liberan la memoria y el estado de la conexión.
Cierre anómalo
Si el destino rechaza la conexión:
- El nodo devuelve un error.
- El cliente comunica el fallo de conexión a la aplicación.
- El Stream se limpia de inmediato.
- Los demás Streams no se ven afectados.
Fase 13: procesamiento del tráfico UDP
UDP no tiene una conexión al estilo de TCP. Cada datagrama tiene que conservar:
- la asociación de origen;
- la dirección de destino;
- el puerto de destino;
- la longitud de los datos;
- los límites del datagrama;
- el tiempo de espera de la asociación.
Por ejemplo:
ID de asociación UDP
Dirección de destino
Puerto de destino
Longitud de los datos
Carga útil UDP
SingLink tiene que elegir explícitamente entre estos enfoques:
UDP sobre TCP
Los datagramas UDP se transportan dentro de TCP o de una Session fiable.
Ventajas:
- atraviesa con más facilidad las redes que solo permiten TCP;
- menos probabilidad de perder datos;
- despliegue más sencillo.
Inconvenientes:
- una pérdida en TCP bloquea los datos UDP posteriores;
- no es adecuado para algunos juegos, voz y usos en tiempo real.
UDP nativo
UDP transporta los datos directamente.
Ventajas:
- baja latencia;
- adecuado para juegos, voz y QUIC;
- no le afecta el bloqueo de cabeza de línea de TCP.
Inconvenientes:
- algunas redes restringen UDP;
- la gestión de NAT y cortafuegos es más compleja.
Transporte al estilo de QUIC
Se basa en UDP, pero aporta en la capa del protocolo:
- cifrado;
- retransmisión;
- varios Streams;
- control de congestión;
- migración entre redes.
Ofrece capacidades técnicas más completas, pero es más difícil de implementar.
Una dirección razonable para SingLink es:
Elegir automáticamente UDP nativo, encapsulado fiable u otro modo compatible según la red y el tipo de tráfico.
Falta confirmar si esto está implementado.
Fase 14: control de flujo y contrapresión
Supongamos que YouTube está descargando rápidamente mientras ChatGPT solo transfiere pequeñas cantidades de texto.
Sin control de flujo, el Stream de vídeo puede llenar el canal y provocar:
- respuestas más lentas de ChatGPT;
- retrasos en el DNS;
- aplicaciones bloqueadas;
- un uso de memoria que no deja de crecer.
Por eso hacen falta dos niveles de control de flujo:
Nivel de Session
Limita cuántos datos sin confirmar puede transportar toda la Session.
Nivel de Stream
Limita qué parte de la ventana de transporte puede ocupar cada Stream.
Dicho de forma sencilla:
Un solo camión grande no puede ocupar todos los carriles de una autopista. Cada Stream necesita un reparto justo de los recursos de transporte.
El protocolo 2.0 de producción puede usar una planificación más conservadora que Beta para que la búsqueda de la velocidad máxima no perjudique a otras conexiones.
Fase 15: segmentación, relleno y apariencia del tráfico
Aunque los datos estén cifrados, un observador todavía puede ver:
- la longitud de los paquetes;
- el intervalo de envío;
- la duración de la conexión;
- la proporción entre subida y bajada;
- el comportamiento de reconexión.
Por eso, el protocolo puede modificar la apariencia del tráfico, por ejemplo:
- dividiendo los datos grandes en varias tramas;
- combinando los datos pequeños;
- añadiendo un relleno (Padding) variable;
- ajustando los lotes de envío;
- evitando una longitud de handshake fija;
- actualizando periódicamente la estrategia de relleno.
Pero hay que dejar claro que:
El relleno no puede sustituir al cifrado ni garantizar que el tráfico sea siempre imposible de identificar.
Un exceso de relleno también provoca:
- más tráfico;
- más latencia;
- más uso de CPU;
- desperdicio de la cuota del plan gratuito.
Por eso, el perfil 2.0 puede adaptarse:
- usar poca sobrecarga en redes normales;
- aumentar el tratamiento de la apariencia en entornos de red especiales;
- reducir el relleno innecesario durante las descargas de alta velocidad;
- aplicar un relleno adecuado a los datos de control pequeños.
Beta, en cambio, puede reducir la sobrecarga adicional para mejorar la velocidad máxima.
Fase 16: gestión de la MTU y del tamaño de los paquetes
Añadir cabeceras de protocolo y datos cifrados al tráfico TUN aumenta el tamaño de los paquetes.
Superar la MTU de la red puede provocar:
- fragmentación IP;
- paquetes descartados;
- webs que no se abren;
- velocidad inestable;
- una VPN que se conecta pero no transporta datos.
SingLink tiene que:
- determinar la MTU del TUN;
- restar las cabeceras del protocolo;
- restar la sobrecarga del cifrado;
- ajustarse para IPv4 e IPv6;
- dividir los datos cuando sea necesario;
- evitar la fragmentación IP innecesaria.
Por eso, un tamaño de paquete fijo no sirve para todas las redes.
La versión 2.0 de producción debería tener una compatibilidad de MTU entre plataformas más completa. Si Beta usa tramas grandes de forma más agresiva, puede ser más rápido en algunas redes, pero menos estable en redes poco habituales.
Fase 17: gestión de la latencia, la pérdida y la congestión
El cliente tiene que observar continuamente:
- la latencia RTT;
- el jitter;
- la pérdida de paquetes;
- la velocidad de envío;
- la velocidad de recepción;
- los datos sin confirmar;
- la respuesta del nodo.
No puede basarse en un único Ping.
Por ejemplo:
Normal: 60 ms
Aumento temporal: 120 ms
Aumento sostenido: 500 ms
Sin respuesta: tiempo de espera agotado
Cada situación requiere un tratamiento distinto:
| Situación | Tratamiento |
|---|---|
| Latencia temporal | Seguir esperando; no reconectar de inmediato |
| Pérdida de paquetes leve | Ajustar la ventana o el ritmo de envío |
| Latencia alta sostenida | Reducir la concurrencia o considerar otro nodo |
| No llegan datos, pero el heartbeat funciona | Mantener la Session |
| Fallan tanto el heartbeat como los datos | Considerar la conexión interrumpida |
| Fallo total del nodo | Reconectar o cambiar de nodo |
Reconectar tras perder un solo paquete haría el protocolo menos estable.
Fase 18: heartbeats y comprobaciones de estado
Aunque no haya datos de las aplicaciones durante mucho tiempo, el sistema necesita saber si el canal sigue vivo.
Puede usar:
PING
↓
PONG
Los heartbeats no pueden ser demasiado frecuentes.
Una frecuencia excesiva:
- gasta batería;
- consume datos;
- aumenta la carga del servidor;
- crea una característica temporal fija.
Una frecuencia insuficiente:
- retrasa la detección de un nodo caído;
- hace que las aplicaciones esperen más;
- ralentiza la recuperación tras un cambio de red.
Por eso, la frecuencia de los heartbeats puede adaptarse al estado:
- si hay tráfico normal, no se añaden heartbeats;
- tras un periodo de inactividad, se empiezan heartbeats de baja frecuencia;
- tras un cambio de red, se aumentan temporalmente las comprobaciones;
- tras varios fallos seguidos, se marca la conexión como interrumpida.
Fase 19: cambios de red y recuperación de la sesión
Cuando un móvil pasa de Wi-Fi a 5G, la conexión original suele dejar de ser válida.
Un tratamiento completo debería ser:
Se detecta el cambio de red
↓
Se deja de enviar datos nuevos por el canal caído
↓
Se obtienen la nueva IP local y la nueva ruta
↓
Se vuelve a conectar al nodo original
↓
Se envía la credencial de recuperación de la sesión
↓
El servidor valida la Session antigua
↓
Se recuperan los Streams lógicos recuperables
↓
Se pide a las aplicaciones que rehagan las conexiones TCP que no se pueden recuperar
Una limitación importante:
No todas las conexiones TCP de las aplicaciones se pueden recuperar sin interrupciones.
El protocolo puede recuperar:
- el estado de la Session;
- la autorización del nodo;
- los parámetros del protocolo;
- algunos Streams cuyo estado sigue siendo válido.
Pero si la propia conexión TCP de la web de destino ha terminado, es posible que la aplicación tenga que volver a conectarse.
Por eso, no debería promocionarse como:
Todas las aplicaciones pasarán siempre por un cambio de red sin ninguna interrupción.
Una afirmación más precisa es:
SingLink 2.0 acorta el tiempo de reconexión, restaura el estado del protocolo y del enrutamiento e intenta reducir al mínimo el impacto en las aplicaciones.
Fase 20: fallo del nodo y cambio automático
Las anomalías de los nodos se pueden dividir en:
Fallo leve
- latencia en aumento;
- pérdida de paquetes ocasional;
- falta de respuesta temporal;
- algunos destinos no disponibles.
Tratamiento:
- esperar un poco;
- reducir la presión de transporte;
- volver a medir;
- reconectar al mismo nodo.
Fallo grave
- no se puede llegar al nodo;
- la interfaz de autenticación no está disponible;
- tiempo de espera agotado de forma sostenida;
- nodo retirado del servicio.
Tratamiento:
- Dejar de usar el nodo original.
- Activar el Kill Switch.
- Elegir una alternativa de la lista de nodos disponibles.
- Establecer una nueva Session segura.
- Restaurar el DNS y las rutas.
- Pedir a las aplicaciones que rehagan las conexiones necesarias.
La versión 2.0 de producción puede cambiar de nodo de forma más conservadora para que un jitter breve no provoque saltos repetidos entre nodos.
Beta puede reconectar o elegir nodos de alta velocidad de forma más agresiva, aunque esto puede producir más variaciones.
Fase 21: devolución de los datos y desencapsulado
La respuesta de la web de destino sigue este flujo:
La web de destino devuelve los datos
↓
El nodo de SingLink los recibe
↓
Se localizan la Session y el Stream correspondientes
↓
Se encapsulan como trama de datos de SingLink
↓
Se cifran y se envían al cliente
↓
El cliente verifica la integridad
↓
Se descifran
↓
Se separan por ID de Stream
↓
Se escriben en el TUN o en el proxy del sistema
↓
Se devuelven a la aplicación de origen
El cliente tiene que comprobar:
- si los datos se han modificado;
- si los números de secuencia son correctos;
- si la trama está duplicada;
- si el Stream sigue existiendo;
- si la longitud está dentro de los límites;
- si se ha superado la ventana de recepción.
Los datos no válidos no deben entregarse directamente a la aplicación.
Fase 22: desconexión normal y limpieza segura
Cuando el usuario pulsa Desconectar, el cliente debería:
- dejar de aceptar nuevo tráfico a través del proxy;
- cerrar con normalidad los Streams activos;
- enviar al nodo el fin de la Session;
- borrar las claves de sesión;
- revocar o descartar los tokens de corta duración;
- cerrar el TUN;
- restaurar las rutas del sistema;
- restaurar el DNS;
- eliminar las reglas del Kill Switch;
- eliminar la configuración temporal innecesaria.
Si el cliente se bloquea, el sistema operativo o el siguiente arranque también necesitan una vía de reparación para no dejar:
- un proxy del sistema no válido;
- un DNS incorrecto;
- rutas residuales;
- el dispositivo sin acceso a Internet;
- un Kill Switch bloqueado de forma permanente.
Diferencias detalladas de estrategia entre SingLink Beta y 2.0
Lo siguiente refleja el posicionamiento técnico del producto; los parámetros exactos aún requieren confirmación de ingeniería.
| Ámbito de procesamiento | SingLink Beta | SingLink 2.0 |
|---|---|---|
| Orientación principal | Velocidad máxima | Velocidad, estabilidad, compatibilidad |
| Parámetros de conexión | Más agresivos | Adaptativos y más conservadores |
| Concurrencia | Puede usar más concurrencia | Evita que un solo flujo llene el canal |
| Ventana de transporte | Orientada al rendimiento | Ajustada dinámicamente según latencia y pérdida |
| Cambio de nodo | Prueba antes los nodos de alta velocidad | Confirma el fallo antes de cambiar |
| Multiplexación | Orientada a la eficiencia de reutilización | Equilibra reutilización y aislamiento de fallos |
| Relleno (Padding) | Prioriza una menor sobrecarga | Se adapta al entorno |
| Cambio de red | Recuperación básica | Recuperación y compatibilidad más completas |
| Pruebas de regresión por plataforma | Alcance de vista previa | Pruebas completas de producción |
| Estabilidad interna | Aproximadamente 97% | 99.5% |
| Velocidad | Más de 1 Gbps en condiciones adecuadas | Sigue siendo rápido sin perseguir solo el pico |
Todo el principio de procesamiento en un párrafo
En SingLink, primero el cliente toma el control del tráfico del dispositivo y completa el procesamiento del DNS, el enrutamiento inteligente y la selección de nodo. Después verifica los permisos de la cuenta y del nodo, negocia las capacidades del protocolo con el nodo y establece claves de cifrado temporales. Una vez creada la conexión, el tráfico TCP y UDP de cada aplicación se encapsula como una conexión proxy independiente o un Stream lógico y se transporta por un canal protegido hasta el nodo, que accede a la web de destino. Durante la transferencia, el sistema gestiona continuamente las ventanas de flujo, la integridad de los datos, la latencia, la pérdida de paquetes, los heartbeats y el estado del nodo. Cuando cambia la red o falla un nodo, restablece la Session, restaura las rutas o cambia a un nodo disponible.
La diferencia esencial entre Beta y 2.0 es:
SingLink Beta persigue la velocidad máxima de forma más agresiva. SingLink 2.0 añade una compatibilidad, unas comprobaciones de estado, una clasificación de anomalías, una recuperación de sesión y una gestión multiplataforma más completas, sin renunciar a la transferencia de alta velocidad, y por eso logra una mayor estabilidad.
Preguntas frecuentes (FAQ)
¿Qué es SingLink 2.0?
SingLink 2.0 es el protocolo de transporte de red oficial desarrollado por SingLinkVPN. Se encarga de la verificación de identidad, las sesiones cifradas, el encapsulado del tráfico, el transporte TCP y UDP, las comprobaciones de estado y la recuperación ante fallos.
¿SingLink 2.0 es una versión del software?
No. SingLink 2.0 es el nombre oficial del protocolo. Las versiones de los clientes de Windows, macOS, Android e iOS siguen un sistema de numeración independiente.
¿Qué diferencia hay entre SingLink Beta y 2.0?
Beta es un protocolo de vista previa centrado en la velocidad, cuya velocidad máxima puede superar 1 Gbps en condiciones adecuadas. 2.0 es el protocolo de producción y da prioridad a la velocidad, la estabilidad, la compatibilidad multiplataforma y la recuperación tras desconexiones.
¿Cuál es la tasa de estabilidad de SingLink 2.0?
En la prueba A/B interna de SingLinkVPN en condiciones especificadas, SingLink 2.0 alcanzó un 99.5% de estabilidad y Beta llegó hasta aproximadamente un 97%.
¿Cómo procesa SingLink el tráfico de red?
El cliente toma primero el control del tráfico del sistema y realiza la gestión del DNS y el enrutamiento inteligente. Después verifica los permisos de la cuenta y del nodo, establece una Session cifrada, encapsula los datos TCP o UDP y los envía a un nodo.
¿Cómo gestiona SingLink las desconexiones?
El sistema comprueba continuamente la latencia, la pérdida de paquetes, los heartbeats y el estado del nodo. Tras una anomalía, puede restablecer la Session, restaurar las rutas o cambiar a un nodo disponible.
¿En qué se diferencia SingLink de VLESS?
VLESS define principalmente la identidad, los comandos y el reenvío al destino. SingLink integra la identidad, el enrutamiento, los permisos sobre los nodos, la política de transporte, las comprobaciones de estado y la recuperación ante fallos en un sistema de protocolos más amplio.
¿En qué se diferencia SingLink de AnyTLS?
AnyTLS transporta principalmente una Session y varios Streams sobre una conexión TLS. SingLink tiene un papel de producto más amplio, que también incluye el enrutamiento inteligente, los permisos según la suscripción, la planificación de nodos y la recuperación de la conexión. La implementación real de Session y Stream queda sujeta a la documentación técnica oficial.
¿Quién puede usar SingLink 2.0?
Los nodos con el protocolo de producción SingLink 2.0 están disponibles actualmente sobre todo para los usuarios de Pro, Max y Rich. El protocolo Beta está abierto a todos los miembros. Para el acceso real, prevalece lo que muestre la versión más reciente del cliente.
¿SingLink 2.0 es totalmente de código abierto?
El código fuente del protocolo principal todavía no es totalmente público, pero los documentos técnicos, los métodos de prueba, los formatos de datos, las herramientas de validación y el mecanismo de divulgación de vulnerabilidades forman parte del plan de código abierto en curso.
Fuentes y lecturas recomendadas
El posicionamiento del producto y las afirmaciones sobre el alcance público de este artículo también se basan en el centro tecnológico oficial de SingLinkVPN, el repositorio público de investigación de SingLinkLabs y su metodología de pruebas de rendimiento.
Lecturas relacionadas: la guía completa del plan gratuito de SingLinkVPN, el plan de código abierto de SingLinkVPN y el informe de auditoría de seguridad de SingLinkVPN de 2026.
Nota técnica: Las cifras del 99.5%, de aproximadamente el 97% y de más de 1 Gbps corresponden, respectivamente, a resultados internos de estabilidad en pruebas A/B y a resultados de rendimiento máximo en condiciones especificadas. No significan que cualquier región, dispositivo, operador, red o franja horaria vaya a producir el mismo resultado. Los algoritmos de cifrado concretos, los formatos de los paquetes y los mecanismos de Session y Stream quedan sujetos a los futuros documentos técnicos oficiales de SingLink y al código fuente que se publique.
