El manual de RouterOS SOCKS documenta la autenticación por contraseña SOCKS5 y una lista propia de usuarios SOCKS. Eso responde a una pregunta de funcionalidad para las versiones que incluyen esos controles, no es la promesa de que un router más antiguo los tenga.

En la disposición documentada, ambas partes deben coincidir:

  • El router elige SOCKS5 y un método de autenticación que exige negociación de contraseña, con un usuario SOCKS dedicado y habilitado.
  • El cliente implementa la negociación de usuario y contraseña de SOCKS5. Un cuadro de inicio de sesión de un proxy HTTP o una implementación SOCKS solo sin autenticación no bastan.

Usa los campos que admite la versión instalada. Si una versión no los tiene, elige su diseño compatible o una alternativa aprobada en lugar de copiar los campos de un manual más reciente.

Son cuentas SOCKS. No demuestran que el proxy web HTTP independiente de RouterOS ofrezca la misma interfaz ni obligan a conceder acceso a la administración del router. Mantén también restringidas la política de acceso origen/destino y el cortafuegos del router.

El método de contraseña por sí solo no cifra las credenciales: la negociación RFC 1929 precede a cualquier sesión HTTPS posterior con un sitio web. Utiliza una ruta cliente-router debidamente protegida; el TLS de destino no puede proteger retroactivamente ese intercambio anterior.

Artículos relacionados