As regras de resposta UDP do Dante invertem a direção from/to
Aplique as regras de resposta do Dante na direção externo→interno em vez de copiar as suposições de endereço do cliente de saída.
O cliente está autenticado e a associação UDP é permitida. As respostas ainda falham. No Dante, examine a direção da regra que trata o tráfego de retorno.
O Dante separa os comandos iniciadores do tratamento das respostas:
| Comandos da regra | from | to |
|---|---|---|
connect, bind, udpassociate | Cliente interno | Destino externo |
bindreply, udpreply | Host externo | Cliente interno |
Copiar a restrição de sub-rede do cliente sem alterações para ambas as direções pode, portanto, corresponder ao lado errado na regra de resposta. Revise os remetentes externos e destinatários internos pretendidos, não apenas se a palavra UDP aparece numa regra pass.
A autenticação tem um limite relacionado. O serviço externo que responde a um datagrama UDP não é um cliente SOCKS capaz de concluir a troca de nome de usuário/senha. A documentação do Dante explica que as operações de resposta decorrem de uma associação BIND ou UDP anterior do cliente; autentique essa operação iniciadora e aplique a política de resposta associada adequada.
Isto não justifica tráfego de entrada não solicitado e irrestrito. A associação UDP, a política de destino, o endereço do relay e o caminho do firewall continuam a importar. Ativar bindreply também não transforma a associação UDP num serviço genérico de encaminhamento público de portas.
Mantenha a troca SOCKS do lado do cliente e o caminho de retorno UDP real visíveis separadamente. Um login TCP bem-sucedido não verifica nem a direção dos endereços na ACL de respostas nem a acessibilidade do endpoint do relay UDP.