Libro blanco técnico del protocolo SingLink

El cliente obtiene los paquetes, nodos y permisos de protocolo disponibles de la cuenta actual. Las credenciales de autenticación deben ser de corta duración, revocables y desacopladas del estado de envío de datos posterior.

El plano de control devuelve la dirección del nodo, el puerto, los protocolos disponibles y las políticas necesarias, y no debe entregar directamente claves maestras a largo plazo ni campos confidenciales innecesarios al cliente.

El cliente recibe el tráfico que debe procesarse a través del modo TUN, el proxy del sistema o la extensión de red de la plataforma. La entrada específica depende de las capacidades del sistema operativo.

Se deben utilizar políticas coherentes para las solicitudes de DNS y las conexiones posteriores para evitar que los nombres de dominio pasen por servidores proxy mientras el DNS todavía se filtra de la red local o provoca un desvío erróneo.

Determina las conexiones como directas, proxy o bloqueadas según las reglas, la aplicación, el nombre de dominio de destino, la IP y el estado de la red.

El modo manual utiliza nodos especificados por el usuario; el modo inteligente puede seleccionar nodos candidatos según la latencia, la disponibilidad, la carga, la región y los permisos del paquete.

El cliente y el servidor confirman las generaciones de protocolos y las capacidades admitidas por ambas partes. El cliente antiguo no debe permitir silenciosamente comportamientos incompatibles cuando no puede reconocer nuevas capacidades.

Los nodos verifican que la cuenta o sesión sea válida y deben evitar que los datos de autenticación antiguos se reutilicen mediante envejecimiento, aleatorización o mecanismos equivalentes.

El protocolo requiere establecer un contexto de cifrado separado para la conexión actual. Los conjuntos de cifrado específicos, los campos de reconocimiento y los períodos de rotación deben estar sujetos a futuras especificaciones públicas.

La sesión representa la sesión de transmisión entre el cliente y el nodo, que puede transportar el estado de la conexión, información de capacidad, latidos y uno o más flujos lógicos.

Cada solicitud de aplicación se puede asignar a una secuencia lógica dentro de la sesión o se puede establecer una conexión independiente; el método final depende de la implementación pública.

Se requiere información de destino, identificación de flujo, longitud de carga útil, comandos de control y datos para formar una trama analizable; Esta página no inventa campos binarios no documentados.

Los flujos de bytes TCP deben mantener el orden, manejar semicierres y cierres anormales, y pasar la contrapresión del lado de la aplicación al lado del transporte.

Los datagramas UDP deben conservar los límites de los mensajes y gestionar los tiempos de espera de las sesiones; Los servicios de tipo UDP como QUIC también deben evitar bloqueos innecesarios de cabecera de línea.

Cuando la velocidad de consumo del cliente, nodo o servicio de destino disminuye, el crecimiento del búfer debe limitarse para evitar que un solo flujo destruya toda la sesión.

La paquetización y el relleno sólo pueden utilizarse como parte de la estrategia de transmisión y no pueden describirse como sigilo absoluto; sus condiciones propicias y sus gastos generales requieren pruebas y verificación.

La sobrecarga del túnel reducirá la MTU disponible y las fallas de paquetes grandes deben reducirse evitando la fragmentación, ajustando MSS o mecanismos equivalentes.

El protocolo debe controlar el ritmo de envío y la retransmisión en función de la retroalimentación de la red y distinguir entre pérdida real de paquetes, retraso en la cola y fluctuación de red a corto plazo.

Supervise continuamente el estado de la sesión y del nodo para evitar depender únicamente de los largos tiempos de espera del sistema operativo para detectar conexiones inactivas.

Después de cambiar entre Wi-Fi y redes móviles, el cliente vuelve a confirmar la entrada a la red, el DNS, las sesiones de enrutamiento y transmisión, y reanuda la conexión según sus capacidades.

En el caso de una falla leve, la sesión se puede reconstruir primero y, en el caso de una falla grave, se pueden cambiar los nodos disponibles. Durante el proceso de conmutación, se debe restaurar el enrutamiento del sistema y se debe evitar el tráfico de conexiones directas inesperadas.

El cliente verifica y desencapsula los datos devueltos y borra el estado de la sesión temporal, las claves de caché, el enrutamiento y los cambios de DNS una vez completada la conexión.