Añade autenticación por nombre de usuario a Dante

Pasa de una política SOCKS basada solo en el origen a una comprobación explícita de cuenta en Dante 1.4.4, manteniendo las restricciones de origen y destino.

En Dante 1.4.4, las reglas de cliente admiten la conexión antes de la negociación SOCKS, mientras que las reglas SOCKS deciden qué solicitudes autenticadas pueden continuar. Una conexión desde un origen permitido todavía puede requerir un nombre de usuario en la segunda fase.

Para autenticar con usuarios del sistema operativo, revisa tanto las identidades del servicio como el método. Leer la base de cuentas puede requerir una identidad privilegiada:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Usa la cuenta de servicio real con pocos privilegios instalada para Dante. Crea o selecciona una cuenta de cliente autorizada y compatible con el backend de nombres de usuario; la identidad del servicio y el inicio de sesión del cliente cumplen funciones distintas.

Mantén los límites de las solicitudes

Después de la regla de cliente restrictiva existente, exige la cuenta en la ruta SOCKS permitida:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

Las direcciones y el nombre de cuenta son valores de ejemplo. Esto permite un origen, un destino, un comando y el usuario autenticado indicado. No sustituyas ese límite por orígenes sin restricciones solo porque hayas añadido una contraseña.

La configuración global del método y la específica de la regla deben coincidir. Busca alguna regla antigua que solo admita none y haya quedado de la configuración basada únicamente en el origen. Conserva también las restricciones previstas del punto de escucha y del cortafuegos.

Prueba la negociación y el acceso por separado

Antes de arrancar el servidor, verifica el archivo con el modo de comprobación de configuración de la versión instalada. Después usa un cliente autorizado que realmente admita negociación SOCKS5 con usuario y contraseña. Prueba credenciales ausentes, credenciales incorrectas y una cuenta permitida que solicite un destino prohibido.

La subnegociación de usuario y contraseña definida en RFC 1929 no cifra la contraseña. Una sesión HTTPS posterior con el destino no protege ese intercambio previo con el proxy. Usa un trayecto debidamente protegido entre cliente y servidor.

Una comprobación de configuración correcta confirma la sintaxis y las identidades, no la base de cuentas ni la ruta de red. Consulta los registros del servidor para identificar la fase que rechazó una prueba real.

Artículos relacionados