Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
КРИТИЧЕСКАЯ ОШИБКА — в выводе SYSLOG на UDM Pro отсутствуют имя правила фаервола и информация о действии, UniFi Network
 
Надеюсь, что этот широко обсуждаемый баг (столько тем и комментариев) с выводом SYSLOG для логов файрвола UDM Pro, в котором отсутствует имя правила или действие, выполненное с трафиком, наконец-то будет исправлен. Из-за этого невозможно выполнить даже базовое устранение неполадок и составление отчетов с помощью UDM Pro, и я бы сказал, что это фактически делает невозможным рекомендовать использование UDM Pro как устройство файрвола (вы вообще не можете понять из логов, был ли трафик принят или заблокирован, то есть полностью отсутствует возможность аудита). На USG это работает, значит, это должна быть ошибка, которую нужно исправить. Пожалуйста, ребята из UI, обратите внимание на этот базовый вопрос сетевой безопасности и как можно скорее предложите исправление или временное решение. Эта проблема существует с момента запуска, я понимаю, что мой «КРИТИЧЕСКИЙ БАГ» может звучать громко, но на самом деле это большая проблема для многих людей. Мне пришлось добавить дополнительные файрволы кроме UDM Pro, чтобы удовлетворить базовые требования по логированию и аудиту для клиентов — так дальше нельзя. Тип устройства: UDM Pro; прошивка: 1.10.4; версия сети: 6.5.55. Пример лога, в котором нет имени правила файрвола и действия: <12>Dec 23 12:19:44 UDMPro,<snip>,udm-1.10.4.3702 kernel: [686358.267558] IN=br0 OUT=eth8 MAC=<snip> SRC=<snip> DST=<snip> LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=64577 DPT=567 WINDOW=65535 RES=0x00 SYN URGP=0
 
@stevehmac @travis.vitek СПАСИБО! Я посмотрел старый лог, который сделал в прошлом октябре, и там этого не было. Сейчас все детали отображаются. Я добавил правило в свои Graylog pipelines, и теперь могу точно понять, что отклоняется, а что проходит. Спасибо, что написали, что эту проблему наконец-то решили!
 
D — значит Drop, R — Reject, A — Accept, RET — неизвестно. Возможно, это Reject с TCP Reset (обычный Reject — это ICMP порт недоступен). Формат сообщения на UDM/UXG/UDR отличается от USG и EdgeRouter, к сожалению.
 
Учитывая строку [WAN_LOCAL-D-xx] из вашего правила выше, WAN_LOCAL — это интерфейс, D — действие, а xx — номер правила. Я полагаю, что D = Отбросить, R = Отклонить, а RET = Принять.
 
@stevehmac Где и как это исправлено? У меня стоят последние версии всего, но в syslog UDM Pro я не вижу номера правила или действия. Вот сообщение из syslog, которое я получил сегодня от SRC, который я блокирую; в нем нет ничего, что указывало бы, что это отклонила 4-е правило в фаерволе. Где ты видишь имя правила и/или действие? UDM-Pro,xx,udm-1.12.22.4309 kernel: [94376.741433] [WAN_LOCAL-D-xx] IN=ppp0 OUT= MAC= SRC=69.165.173.49 DST=xx LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=37471 DF PROTO=TCP SPT=26442 DPT=8291 WINDOW=14600 RES=0x00 SYN URGP=0
 
Просто подтверждаю, что эта проблема решена, теперь в логах отображаются действие и номер правила.
Страницы: 1
Читают тему (гостей: 1)