Правила ответов 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.