Les règles de réponse UDP de Dante inversent le sens from/to
Appliquez les règles de réponse de Dante dans le sens extérieur vers intérieur, au lieu de recopier les hypothèses d'adresse du client sortant.
Le client est authentifié et l'association UDP est autorisée. Les réponses échouent pourtant. Dans Dante, examinez le sens de la règle qui traite le trafic de retour.
Dante sépare les commandes d'initiation du traitement des réponses :
| Commandes de règle | from | to |
|---|---|---|
connect, bind, udpassociate | Client interne | Destination externe |
bindreply, udpreply | Hôte externe | Client interne |
Recopier sans changement la restriction de sous-réseau d'un client dans les deux sens peut donc correspondre au mauvais côté dans la règle de réponse. Vérifiez les expéditeurs externes et les destinataires internes visés, et pas seulement la présence du mot UDP dans une règle d'autorisation.
L'authentification a une frontière connexe. Le service externe qui répond à un datagramme UDP n'est pas un client SOCKS capable de mener à bien votre échange nom d'utilisateur et mot de passe. La documentation de Dante explique que les opérations de réponse découlent d'une association BIND ou UDP antérieure du client ; authentifiez cette opération d'initiation et appliquez la politique de réponse associée appropriée.
Cela ne justifie pas un trafic entrant non sollicité sans restriction. L'association UDP, la politique de destination, l'adresse de relais et le chemin du pare-feu restent importants. Activer bindreply ne transforme pas non plus l'association UDP en service public universel de redirection de ports.
Gardez visibles séparément l'échange SOCKS côté client et le chemin de retour UDP réel. Une connexion TCP réussie ne vérifie ni le sens des adresses de l'ACL de réponse ni l'accessibilité du point de terminaison du relais UDP.