Правілы адказаў UDP у Dante змяняюць кірунак from/to на адваротны
Ужывайце правілы адказаў Dante ў кірунку звонку-унутр, замест таго каб капіяваць здагадкі адраса кліента, які выходзіць.
Кліент прайшоў аўтэнтыфікацыю, і асацыяцыя UDP дазволена. Адпавяданні ўсё яшчэ не праходзяць. У Dante праверце кірунак правіла, якое апрацоўвае зваротны трафік.
Dante аддзяляе каманды ініцыяцыі ад апрацоўкі адказаў:
| Каманды правілаў | from | to |
|---|---|---|
connect, bind, udpassociate | Унутраны кліент | Знешні пункт прызначэння |
bindreply, udpreply | Знешні хост | Унутраны кліент |
Таму капіраванне абмежавання падсеткі кліента без змен у абодвух кірунках можа супасці з няправільным бокам у правіле адказу. Праверце меркаваных знешніх адпраўнікоў і ўнутраных атрымальнікаў, а не проста наяўнасць слова UDP у правіле пропуску.
Аўтэнтыфікацыя мае звязаную мяжу. Знешняя служба, якая адказвае на датаграму UDP, не з'яўляецца кліентам SOCKS, здольным завяршыць абмен імем карыстальніка і паролем. Дакументацыя Dante тлумачыць, што аперацыі адказу ўзнікаюць з папярэдняй асацыяцыі BIND або UDP кліента; аўтэнтыфікуйце гэтую аперацыю ініцыяцыі і прымяніце адпаведную палітыку звязаных адказаў.
Гэта не апраўдвае неабмежаваны незапатрабаваны ўваходны трафік. Асацыяцыя UDP, палітыка пункта прызначэння, адрас рэтранслятара і шлях праз файрвол па-ранейшаму важныя. Уключэнне bindreply таксама не ператварае асацыяцыю UDP ва ўніверсальную публічную службу перанакіравання портаў.
Трымайце абмен SOCKS на баку кліента і фактычны зваротны шлях UDP асобна бачнымі. Паспяховы ўваход па TCP не пацвярджае ні кірунак адрасоў у ACL адказаў, ні дасяжнасць канцавой кропкі рэтранслятара UDP.