Binabaligtad ng mga patakaran sa tugon ng UDP ng Dante ang direksyong from/to
Ilapat ang mga patakaran sa tugon ng Dante sa direksyong labas→loob sa halip na kopyahin ang mga palagay sa address ng kliyenteng lumalabas.
Na-authenticate ang kliyente at pinapayagan ang UDP association. Nabibigo pa rin ang mga tugon. Sa Dante, suriin ang direksyon ng patakarang humahawak sa trapikong bumabalik.
Hinihiwalay ng Dante ang mga command na nagpapasimula sa paghawak ng mga tugon:
| Mga command ng patakaran | from | to |
|---|---|---|
connect, bind, udpassociate | Panloob na kliyente | Panlabas na destinasyon |
bindreply, udpreply | Panlabas na host | Panloob na kliyente |
Ang pagkopya sa paghihigpit sa subnet ng kliyente nang walang pagbabago sa parehong direksyon ay maaaring tumugma sa maling panig sa patakaran sa tugon. Suriin ang nilalayong panlabas na nagpapadala at panloob na tumatanggap, hindi lamang kung ang salitang UDP ay lumilitaw sa isang pass na patakaran.
Ang authentication ay may kaugnay na hangganan. Ang panlabas na serbisyong tumutugon sa isang UDP datagram ay hindi isang SOCKS kliyente na makakapagkumpleto ng iyong palitan ng username/password. Ipinapaliwanag ng dokumentasyon ng Dante na ang mga operasyon ng tugon ay nagmumula sa naunang BIND o UDP association ng kliyente; i-authenticate ang nagpapasimulang operasyon at ilapat ang angkop na patakaran sa kaugnay na tugon.
Hindi nito binibigyang-katwiran ang walang limitasyong, hindi hinihinging papasok na trapiko. UDP association, patakaran sa destinasyon, address ng relay at landas ng firewall ay mahalaga pa rin. Ang pagpapagana ng bindreply ay hindi rin ginagawang pangkalahatang pampublikong serbisyo ng port forwarding ang UDP association.
Panatilihing hiwalay na nakikita ang palitan ng SOCKS sa panig ng kliyente at ang aktwal na landas ng pagbalik ng UDP. Ang matagumpay na pag-login sa TCP ay hindi nagbe-verify ng direksyon ng address ng ACL sa tugon o ng pag-abot sa UDP relay endpoint.