Проблема с работой облачного сервиса 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. -
Если нужны только камеры, достаточно доверяете провайдерам и есть постоянные IP со всех сторон — можно воспользоваться менее затратными IPIP тунелями.
Для анализа работы протоколов и передачи пакетов всегда используются сетевые дампы. Под Windows это обычно WireShark, под *nix системами tcpdump.IPIP штука хорошая, но IMHO, требует белой статики на обоих концах и pfSense, вроде как не поддерживается?
-
Если нужны только камеры, достаточно доверяете провайдерам и есть постоянные IP со всех сторон — можно воспользоваться менее затратными IPIP тунелями.
Для анализа работы протоколов и передачи пакетов всегда используются сетевые дампы. Под Windows это обычно WireShark, под *nix системами tcpdump.IPIP штука хорошая, но IMHO, требует белой статики на обоих концах и pfSense, вроде как не поддерживается?
Почему это не поддерживается — GIF интерфейсы это и есть IPIP тунели
-
И оно совместимо, например, например, с IPIP в реализации Микротик?
Там это реализуется без задания промежуточной туннельной сети:
https://forummikrotik.ru/viewtopic.php?t=5693 -
И оно совместимо, например, например, с 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 имеется данная настройка и целый раздел в мануале под названием "Статический порт"
-
Я конечно не буду спорить что софтина на стороне клиента пробмлемная, но проблема не разовая. Не зря в pfSense имеется данная настройка и целый раздел в мануале под названием "Статический порт"
Вообще-то любой роутер с NAT, действительно ведет себя, как пишет ув. werter.
Static port в англ. ветках советуют включать для игровых приставок типа xbox.
Положение исправилось выставлением статического порта для Outbound NAT
Идеологически правильнее было бы создать в Outbound NAT отдельное правило для dest IP сервиса камер со static port , поставить его выше отредактированного вами, а в основном static port убрать.
