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