Regulile de răspuns UDP din Dante inversează direcția from/to
Aplicați regulile de răspuns Dante în direcția exterior→interior în loc să copiați presupunerile de adresă ale clientului care iese.
Clientul este autentificat și asocierea UDP este permisă. Răspunsurile tot eșuează. În Dante, examinați direcția regulii care gestionează traficul de retur.
Dante separă comenzile de inițiere de tratarea răspunsurilor:
| Comenzile regulii | from | to |
|---|---|---|
connect, bind, udpassociate | Client intern | Destinație externă |
bindreply, udpreply | Gazdă externă | Client intern |
Copierea restricției de subrețea a clientului neschimbată în ambele direcții poate deci potrivi partea greșită în regula de răspuns. Examinați expeditorii externi și destinatarii interni intenționați, nu doar dacă cuvântul UDP apare într-o regulă pass.
Autentificarea are o limită asociată. Serviciul extern care răspunde la un datagramă UDP nu este un client SOCKS care poate finaliza schimbul de nume de utilizator/parolă. Documentația Dante explică faptul că operațiile de răspuns provin din asocierea BIND sau UDP anterioară a clientului; autentificați acea operație de inițiere și aplicați politica adecvată de răspuns asociat.
Aceasta nu justifică trafic de intrare nesolicitat și nelimitat. Asocierea UDP, politica de destinație, adresa relay-ului și calea firewall-ului contează în continuare. Nici activarea bindreply nu transformă asocierea UDP într-un serviciu generic public de port forwarding.
Păstrați vizibile separat schimbul SOCKS pe partea clientului și calea reală de retur UDP. O autentificare TCP reușită nu verifică nici direcția adreselor din ACL-ul de răspuns, nici accesibilitatea endpoint-ului relay UDP.