Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Брандмауэры PVE и SIP

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Брандмауэры PVE и SIP, Proxmox Виртуальная Среда
     
    arubenstein
    Guest
    #1
    0
    02.10.2024 13:12:00
    У меня возник очень странный ребус с фаерволом для виртуальной машины — это виртуальная АТС. Я потратил немало времени на поиск причины и просто не могу понять, что происходит. Считаю себя довольно опытным в PVE и в настройке фаерволов — буквально сотни ВМ на нескольких кластерах, многие с сложными правилами, и всё работает отлично. Я максимально упростил проблему. Это Linux-виртуалка с сетеовой картой VirtIO. Если на сетевой карте НЕ ставить галочку «Firewall», то всё работает без проблем: входящие и исходящие звонки идут весь день, всё просто отлично. Но стоит поставить эту галочку — и сразу начинаются проблемы с исходящими SIP-звонками от ВМ к нашему провайдеру.

    Я пробовал:
    - В настройках ставить «Firewall» в «NO»
    - В настройках выставлять «Input Policy» и «Output Policy» в ACCEPT
    - Добавлять правила с «out» и «in» в ACCEPT для всех IP
    - Добавлять правила с «out», «in» и «Protocol UDP» в ACCEPT для всего UDP

    Входящие звонки от провайдера к ВМ идут без проблем, двунаправленный звук тоже нормальный. Проблема только с исходящими звонками. Я в тупике, есть идеи?

    Код:
    :tap150i0-IN - [0:0]
    :tap150i0-OUT - [0:0]
    -A PVEFW-FWBR-IN -m physdev --physdev-out tap150i0 --physdev-is-bridged -j tap150i0-IN
    -A PVEFW-FWBR-OUT -m physdev --physdev-in tap150i0 --physdev-is-bridged -j tap150i0-OUT
    -A tap150i0-IN -p udp -m udp --sport 67 --dport 68 -j ACCEPT
    -A tap150i0-IN -j ACCEPT
    -A tap150i0-IN -m comment --comment "PVESIG:OFdXzqXcwmyj0szvDL/e5fRT+nI"
    -A tap150i0-OUT -p udp -m udp --sport 68 --dport 67 -g PVEFW-SET-ACCEPT-MARK
    -A tap150i0-OUT -m mac ! --mac-source 4e:62:60:5f:93:de -j DROP
    -A tap150i0-OUT -j MARK --set-xmark 0x0/0x80000000
    -A tap150i0-OUT -m limit --limit 1/sec -j NFLOG --nflog-prefix ":150:1:tap150i0-OUT: ACCEPT: "
    -A tap150i0-OUT -g PVEFW-SET-ACCEPT-MARK
    -A tap150i0-OUT -g PVEFW-SET-ACCEPT-MARK
    -A tap150i0-OUT -m comment --comment "PVESIG:DIY5MgeZA0+FJEjKMorU7Qunr1Q"
     
     
     
    KevinS
    Guest
    #2
    0
    17.10.2024 10:45:00
    Спасибо за обновление. Надеюсь, вы воспользуетесь нашим предложением с тикетом поддержки, потому что нам, вероятно, понадобится tcpdump, чтобы найти причину проблемы. На данный момент я не могу придумать техническую причину, почему входящий вызов (который затем отправляет SIP-инвайт в другую сеть, так как телефоны находятся в другом месте) работает, а исходящий — нет. Пока что я попробую настроить всё в нашей лаборатории и попытаться воспроизвести проблему.
     
     
     
    arubenstein
    Guest
    #3
    0
    11.12.2024 22:33:00
    Наконец-то обновил кластер до версии 8.3.0 — никакого изменения в поведении не заметил. Также пробовал холодный запуск виртуальной машины с включённым файрволом — безрезультатно.
     
     
     
    kissze
    Guest
    #4
    0
    14.03.2025 17:58:00
    Привет, у меня такая же проблема с VOIP. Если полностью отключить файрвол PVE, то всё работает нормально. Но как только включаю файрвол, часть связи (особенно UDP) перестаёт работать, даже если ВМ находятся на одном и том же хосте или на разных. Самое интересное, что я думаю, это не связано напрямую с Proxmox или файрволом PVE. Если создать такое правило: Code: iptables -A INPUT -m conntrack --ctstate INVALID -j LOG, то вся UDP связь между моим сервером Kamailio и rtpengines, которая основана на UDP, перестаёт работать. Если убрать это правило — всё возвращается в норму. Если отключить bridge-call-iptables, тогда связь работает, но как кто-то из Proxmox сказал, в файрволе PVE есть автоматизация, которая включает его снова, потому что надо делать фильтрацию на мосту. Так что, возможно, это проблема с conntrack, потому что он блокирует UDP-трафик, даже если правил DROP нет. Есть у кого-то идеи по этому поводу? Спасибо, Золтан
     
     
     
    kissze
    Guest
    #5
    0
    16.03.2025 11:42:00
    Итак, “обходным решением” стало переключение на бекенд nftables, отключение bridge_call_iptables и затем перезапуск pve-firewall. Теперь более крупные UDP SIP пакеты без проблем проходят через VLAN-aware мост.
     
     
     
    shanreich
    Guest
    #6
    0
    17.03.2025 08:58:00
    Ах, значит, возможно, вы столкнулись с такой ошибкой [1]: если на уровне моста включён файрвол, фрагментированные пакеты не собираются обратно и просто отбрасываются. [1] https://bugzilla.proxmox.com/show_bug.cgi?id=4158
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры