Проблема с работой облачного сервиса novicam.



  • Доброго дня.
    Вторую неделю бьюсь с непонятным траблом. После перевода офисной сети на pfSense отдел видеонаблюдения стал жаловаться на стабильность доступа к видеорегистраторам, а именно к той части которая настроена через облако. Та часть которая работает напрямую через проброшенный порт (внешний ip\порт -> внутр ip\порт регистратора) - продолжает работать стабильно. А облачные либо открываются долго, либо отваливаются с ошибкой что устройство недоступно - после нескольких попыток может подключиться. Сперва облачные ресурсы вообще не работали пока я не добавил разрешающее правило для айпишников отдела видеонаблюдения (попытался отловить порты которыми пользуется облачный сервис, но после 6-го порта плюнул и разрешил ipv4 видеонаблюдаторам * * * *)

    До этого всё работало через шлюз на clearOS - таких проблем не было. Правда и правил на нём не было никаких. Но по сути то и сейчас ничего не должно мешать.

    Буду признателен за любую помощь.



  • А зачем работая внутри локальной сети использовать облачное подключение?
    Если для удаленных пользователей — то самый лучший вариант это вначале подключатся по VPN, а потом смотреть. И не использовать проброс портов до видеорегистраторов (и так ботов развелось дофига).
    Ну а если все-таки требуется облачное подключение — снимайте дампы трафика, смотрите что  UPnP прописывает.



  • Торговые точки находятся удалённо.
    vpn пока только в планах. Да  и есть сомнения по поводу видео трафика внутри туннеля, хватит ли канала?
    По поводу дампов и upnp можно поподробнее?

    В ServicesUPnP & NAT-PMP всё отключено



  • по поводу видео трафика внутри туннеля, хватит ли канала?
    Правильнее спросить, хватит ли ресурсов CPU на обеих сторонах для передачи видео через VPN.
    На всякий случай, если решите выбрать OpenVPN и CPU на pfSense многоядерный.
    OpenVPN - задача однопоточная, не вешайте все точки  на один экземпляр сервера OpenVPN.



  • Если нужны только камеры, достаточно доверяете провайдерам и есть постоянные IP со всех сторон — можно воспользоваться менее затратными IPIP тунелями.
    Для анализа работы протоколов и передачи пакетов всегда используются сетевые дампы. Под Windows это обычно WireShark, под *nix системами tcpdump.



  • @PbIXTOP:

    Если нужны только камеры, достаточно доверяете провайдерам и есть постоянные IP со всех сторон — можно воспользоваться менее затратными IPIP тунелями.
    Для анализа работы протоколов и передачи пакетов всегда используются сетевые дампы. Под Windows это обычно WireShark, под *nix системами tcpdump.

    IPIP штука хорошая, но IMHO, требует белой статики на обоих концах и pfSense, вроде как не поддерживается?



  • @pigbrother:

    @PbIXTOP:

    Если нужны только камеры, достаточно доверяете провайдерам и есть постоянные IP со всех сторон — можно воспользоваться менее затратными IPIP тунелями.
    Для анализа работы протоколов и передачи пакетов всегда используются сетевые дампы. Под Windows это обычно WireShark, под *nix системами tcpdump.

    IPIP штука хорошая, но IMHO, требует белой статики на обоих концах и pfSense, вроде как не поддерживается?

    Почему это не поддерживается — GIF интерфейсы это и есть IPIP тунели



  • И оно совместимо, например, например, с IPIP в реализации Микротик?
    Там это реализуется  без задания промежуточной туннельной сети:
    https://forummikrotik.ru/viewtopic.php?t=5693



  • @pigbrother:

    И оно совместимо, например, например, с IPIP в реализации Микротик?
    Там это реализуется  без задания промежуточной туннельной сети:
    https://forummikrotik.ru/viewtopic.php?t=5693

    Странно конечно, но  в официальных доках https://wiki.mikrotik.com/wiki/Manual:Interface/IPIP на IPIP интерфейсы вешается сеть.
    Знакомый запускал Mikrotik-pfSense - вроде все работает нормально.



  • Добрый.
    @efgen42:

    Сперва облачные ресурсы вообще не работали пока я не добавил разрешающее правило для айпишников отдела видеонаблюдения (попытался отловить порты которыми пользуется облачный сервис, но после 6-го порта плюнул и разрешил ipv4 видеонаблюдаторам * * * *)

    Не нужно разрешать всё. Создайте на ЛАН разреш правило, где в сурс будет алиас из айпишников отдела видеонаблюдения ,в дест - ip-адрес\сеть\алиас из адресов облачного сервиса.



  • В source так и прописано, в дест - *.
    Я замучался отлавливать порты и хосты куда ломится эта софтина, их очень много.
    Переводить все точки на впн физически не получится  - их, работающих через облачные сервисы больше 80 штук.

    Решения проблемы я так и не нашёл. А отдел видеонаблюдения уже начали жаловаться руководству. Основной аргумент - до установки шлюза на pfsense ВСЁ РАБОТАЛО!
    Я уже поменял сетевуху интерфейса WAN стояла realtek - сейчас Intel.
    По всей видимости дело в настройках pfSense.
    Есть у кого-нибудь мысли куда дальше копать?



  • Разобрался :).
    По умолчанию, pfSense переписывает исходный порт во всех исходящих пакетах. При таком раскладе клиент обращающийся к облачному сервису от новикам пухнет и дохнет.
    Положение исправилось выставлением статического порта для Outbound NAT.
    Firewall -> NAT-> вкладка Outbound ->Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)) и Save. Дальше редактируем автоматически созданное правило для LAN,  а именно отмечаем флаг Static Port и жмём  Save. После этого я поставил режим исходящего NAT  - Hybrid Outbound NAT rule generation.
    День проработали - полёт нормальный



  • Доброе.

    По умолчанию, pfSense переписывает исходный порт во всех исходящих пакетах

    Это нормальное поведение любого роутера (а не только пф) . Исходящий порт генерируется случ. образом и это никак не должно влиять на работу с удален. сервисом.

    Проблема с ПО на стороне клиента.



  • Я конечно не буду спорить что софтина на стороне клиента пробмлемная, но проблема не разовая. Не зря в pfSense имеется данная настройка и целый раздел в мануале под названием "Статический порт"



  • @efgen42:

    Я конечно не буду спорить что софтина на стороне клиента пробмлемная, но проблема не разовая. Не зря в pfSense имеется данная настройка и целый раздел в мануале под названием "Статический порт"

    Вообще-то любой роутер с NAT, действительно ведет себя, как пишет ув. werter.
    Static port в англ. ветках советуют включать для игровых приставок типа xbox.
    Положение исправилось выставлением статического порта для Outbound NAT
    Идеологически правильнее было бы создать в Outbound NAT отдельное правило для dest IP сервиса камер со static port , поставить его выше отредактированного вами, а в основном static port убрать.


Log in to reply