Engade autenticación por nome de usuario a Dante

Pasa dunha política SOCKS baseada só na orixe a unha comprobación explícita de conta en Dante 1.4.4, mantendo as restricións de orixe e destino.

En Dante 1.4.4, as regras de cliente admiten a conexión antes da negociación SOCKS, mentres que as regras SOCKS deciden que peticións autenticadas poden continuar. Unha conexión dunha orixe permitida aínda pode requirir un nome de usuario na segunda fase.

Para autenticar con usuarios do sistema operativo, revisa as identidades do servizo ademais do método. Ler a base de contas pode requirir unha identidade privilexiada:

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

Usa a conta de servizo real con poucos privilexios instalada para Dante. Crea ou escolle unha conta de cliente autorizada e compatible co backend de nomes de usuario; a identidade do servizo e o inicio de sesión do cliente teñen funcións distintas.

Mantén os límites das peticións

Despois da regra de cliente restritiva existente, esixe a conta na 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
}

Os enderezos e o nome da conta son valores de exemplo. Isto permite unha orixe, un destino, un comando e o usuario autenticado indicado. Non substitúas ese límite por orixes sen restricións só porque engadiches un contrasinal.

Os axustes globais do método e os específicos da regra deben coincidir. Busca unha regra antiga que só admita none e quedase dunha configuración baseada unicamente na orixe. Conserva tamén as restricións previstas do punto de escoita e do cortalumes.

Proba a negociación e o acceso por separado

Antes de iniciar o servidor, verifica o ficheiro co modo de comprobación de configuración da versión instalada. Logo usa un cliente autorizado que realmente admita a negociación SOCKS5 con usuario e contrasinal. Proba credenciais ausentes, credenciais incorrectas e unha conta permitida que pida un destino prohibido.

A subnegociación de usuario e contrasinal definida no RFC 1929 non cifra o contrasinal. Unha sesión HTTPS posterior co destino non protexe ese intercambio anterior co proxy. Usa un camiño debidamente protexido entre cliente e servidor.

Unha comprobación correcta da configuración confirma a sintaxe e as identidades, non a base de contas nin a ruta de rede. Consulta os rexistros do servidor para saber que fase rexeitou unha proba real.

Artigos relacionados