La UDP-respondaj reguloj de Dante inversigas la direkton from/to
Apliku la respondajn regulojn de Dante en la direkto de ekstere al ene, anstataŭ kopii la adresajn supozojn de la eliranta kliento.
La kliento estas aŭtentigita kaj UDP-asocio estas permesita. Respondoj tamen malsukcesas. En Dante, esploru la direkton de la regulo, kiu traktas la revenan trafikon.
Dante apartigas komencajn komandojn de responda traktado:
| Regulaj komandoj | from | to |
|---|---|---|
connect, bind, udpassociate | Interna kliento | Ekstera celo |
bindreply, udpreply | Ekstera gastiganto | Interna kliento |
Tial kopii la subretan limigon de kliento senŝanĝe en ambaŭ direktojn povas kongrui kun la malĝusta flanko en la responda regulo. Kontrolu la celatajn eksterajn sendantojn kaj internajn ricevantojn, ne nur ĉu la vorto UDP aperas en permesa regulo.
Aŭtentigo havas rilatan limon. La ekstera servo, kiu respondas al UDP-datagramo, ne estas SOCKS-kliento, kiu povus kompletigi vian interŝanĝon de uzantnomo kaj pasvorto. La dokumentaro de Dante klarigas, ke respondaj operacioj devenas de pli frua BIND- aŭ UDP-asocio de kliento; aŭtentigu tiun komencan operacion kaj apliku la taŭgan politikon pri asociitaj respondoj.
Tio ne pravigas senliman nepetitan envenantan trafikon. La UDP-asocio, cella politiko, relajsa adreso kaj fajroŝirma vojo ankoraŭ gravas. Nek ebligi bindreply transformas UDP-asocion en ĝeneralan publikan pordvarban servon.
Tenu la klientflankan SOCKS-interŝanĝon kaj la realan UDP-revenan vojon videblaj aparte. Sukcesa TCP-ensaluto konfirmas nek la adresdirekton de la responda ACL nek la atingeblon de la UDP-relajsa finpunkto.