Мы просто в отчаянии из-за установки для клиента.

Мы просто в отчаянии из-за установки для клиента., UniFi Network

antonical

Guest

20.04.2025 18:22:00

У нас тут у клиента недавно была установка сети, охватывающая весь объект. Полная сеть по всей территории: 2 стойки, оптоволоконный backbone, 24 камеры и т.д. Внутренние и внешние точки доступа и т.д. Все было хорошо до этих выходных, когда клиенты сети начали сообщать, что не могут зайти на сайт клиента, другие сайты работают нормально. Только сайты, размещенные на этом хостинге. Как раз мы предоставляем хостинг для этого клиента. Мы проверили хостинг-сервер, все в порядке. Нет сетевых блокировок и т.д. Сайты можно просматривать извне сети Unifi. Нет черных списков и т.д. Но изнутри сети Unifi мы не можем зайти ни на один сайт, размещенный на этом хостинге. Однако мы можем зайти в панель управления хостингом по тому же IP-адресу! Мы подумали, может быть, это контент-фильтрация. Мы ее отключили. Без изменений. Мы внесли исключение обнаружения в конфигурацию IPS, разницы нет. Мы провели 2 часа в онлайн-поддержке. Полностью бесполезно! Мы можем пинговать, делать nslookup и т.д. веб-адреса изнутри сети Unifi. Кажется, все в порядке. Но до сих пор не можем подключиться ни к одному сайту, размещенному на этом хостинге. Все работало нормально до выходных. Потом "из коробки" не можем зайти на эти сайты, не имеем ни малейшего представления, почему или где они блокируются. В интернете полно постов с похожими проблемами. Случайно определенные сайты просто перестали быть доступными. Нет логов, информации о угрозах, ничего. Отладочный лог (удаленный доступ через оболочку) бесполезен, он не работает с локальной UDM Pro. Поэтому мы не можем получить удаленный доступ к оболочке UDM Pro Max или к чему-то другому, например, к коммутаторам Pro24. SSH-доступ включен и настроен, но отладочная оболочка выдает ошибку "Connection Error". Ответ поддержки на это был: "Я никогда раньше этого не видел, все работает в моей лабораторной среде". Пришлось ехать на объект, чтобы попытаться отладить это локально. Все равно не работало. В этот объект установлено более 20 тысяч долларов нового оборудования Unifi. Другие проблемы, похоже, связаны с подключением Wi-Fi, которое якобы находится в изолированной сети. Я могу зайти на страницу входа UDM Pro Max в управленческой VLAN. Правила брандмауэра говорят, что это не должно быть возможно. Сеть Wi-Fi изолирована. Есть правила брандмауэра, блокирующие межсетевую маршрутизацию. Но я могу зайти в управленческую сеть. Любая помощь от очень опытных сетевых администраторов приветствуется. Мы провели все обычные тесты. Что-то где-то блокирует доступ к этим сайтам из сети Unifi, и мы не можем это найти, а поддержка понятия не имеет. Эти сайты работают нормально и доступны из-за пределов сети Unifi без проблем. Надеюсь, кто-то сможет помочь нам, так как это теперь серьезная проблема для нас, так как клиент не может зайти на свой сайт!

Cheers,
Tony

travis.vitek

Guest

21.04.2025 02:13:00

Пытаетесь ли вы получить доступ к веб-серверу, размещенному на другом устройстве в локальной сети, по его публичному интернет-имени, или веб-сервер находится за пределами этой сети? Если вы пытаетесь получить доступ к веб-серверу в VLAN A с клиента в VLAN B и у вас настроена переадресация порта для веб-сервера, вам все равно нужно разрешить трафик в брандмауэре с B в A и ответный трафик с A в B. К тому же, не повредит использовать локальную DNS-запись, чтобы избежать hairpin NAT. В чем именно заключается проблема? Например, если вы запустите `curl -v <web-address>`, вы получите ошибку таймаута или что-то другое?

dvsa-bc-WiFI

Guest

21.04.2025 01:52:00

У меня тоже были подобные проблемы. Думаю, в вашем случае дело в том, что когда вы находитесь внутри сети, nslookup показывает внешний IP-адрес веб-сервера, хотя вы и находитесь внутри. Я видел, что многие брандмауэры испытывают трудности с тем, чтобы внутренний IP-адрес общался с внешним IP-адресом, который отображается на другой внутренний IP-адрес. Некоторые брандмауэры требуют специального правила для разрешения этого "перекрестного" трафика. Помните, что внутренний трафик направляется на шлюз провайдера, а не на внешний интерфейс брандмауэра. Один из способов обойти это — добавить записи хостов на внутреннем DNS-сервере, которые возвращают внутренний IP-адрес для домена и имени сервера. Было бы полезно знать, находятся ли веб-серверы в DMZ и что вы используете в качестве брандмауэра. Вы можете протестировать эту теорию, добавив записи в файл hosts на компьютере внутри сети, который испытывает проблемы, и посмотреть, начнет ли он волшебным образом работать для записей хостов, которые вы добавите.

antonical

Guest

20.04.2025 23:43:00

Не использую ZBF. Пока просто продвинутые правила. Почти из коробки, чтобы разобраться, что вообще происходит с доступом к этому конкретному веб-хостингу. Как будто вдруг где-то появилось скрытое правило, запрещающее доступ к этому хостингу. Это безумие. Нет никаких фильтров контента и т.д. Интернет-доступ вроде бы работает нормально для других сайтов, но вдруг перестал работать для конкретного веб-хостинга. Там размещено несколько сайтов. Не могу получить доступ ни к одному из них. Но доступ к панели управления по тому же IP есть. Странно… Я совсем застрял с этим, потому что клиент не может получить доступ к своему собственному сайту! Как это вообще возможно? Поддержка была хуже, чем бесполезная. Хороший совет дали по поводу изоляции сети. Странно, что у нас в работе есть правила межсетевого экранирования.

gregorio Guest	#5 20.04.2025 22:42:00 @khtadmin верно. Это касается стандартных и ZBF.

gregorio

Guest

20.04.2025 21:31:00

Сожалею об этом. Я не уверен, что происходит с доступом к сайту. Используете ли вы блокировщик рекламы или фильтры контента? Можете ли вы подключиться к порту 80 по telnet? Если используете ZBF, я знаю, что галочка "Isolate" вводит многих в заблуждение, заставляя думать, что Unifi автоматически создаёт все необходимые правила для этого. Вам все равно нужно создать конкретные правила на LAN Local, чтобы заблокировать порты 22, 80, 443 со всех VLAN, кроме доверенных. Если у вас есть VLAN для гостей, вам нужно сделать это снова на Guest Local.

antonical

Guest

22.04.2025 08:11:00

Просто небольшое обновление: у нас идет эскалация с провайдером, чтобы выяснить, не вмешиваются ли они как "человек посередине". Также заметили блокировку SMTP из сети Unifi. Блокировки на Webhost нет. Сюжет накаляется...

Akr1800 Guest	#8 21.04.2025 22:18:00 Если другие сайты работают, возможно, ваш сайт заблокирован на уровне сервера (а не на UniFi)? Может, стоит спросить об этом у разработчиков сайта и тех, кто его обслуживает.

gregorio Guest	#9 21.04.2025 21:50:00 Держите нас в курсе, потому что это очень необычное поведение.

antonical

Guest

#10

21.04.2025 21:35:00

@gregorio @flipper Большое спасибо за заметки. Да, мы уже пробовали curl тест и прочее. Загрузку резервной копии офлайн ещё не тестировали. На этой неделе вернёмся к основам, возможно, вообще начистим весь сайт и начнём заново. Мы перенесли их сайт на другой хостинг, так что теперь он доступен, и обогрев для него отключен. То, что у нас тут длинные выходные, конечно, помогло, хотя мы тут отдохнуть так ни разу и не успели! 😉

gregorio

Guest

#11

21.04.2025 18:53:00

Как показывают тесты на данный момент? Пробовали ли вы правило, которое сначала разрешает этот трафик, чтобы просто его логировать? Делали ли вы захват пакетов? Пробовали ли вы curl тест? Можете ли вы загрузить их резервную копию в вашу лабораторию, чтобы протестировать в автономном режиме? Понимаю, что вам срочно нужно решение, но такой проблемы невозможно протестировать удаленно на форуме.

flipper Guest	#12 21.04.2025 18:50:00 Ну и когда ты делал захват пакетов, что ты увидел? Где именно пакеты теряются?

antonical Guest	#13 21.04.2025 18:35:00 @flipper Это не ответ. Нам нужно понять, что тут происходит. Что, если оно случайно заблокирует ещё какой-нибудь сайт!

flipper Guest	#14 21.04.2025 10:30:00 Перезагрузи и восстанови резервные копии из той версии, когда всё работало хорошо.

antonical

Guest

#15

21.04.2025 09:49:00

Кажется, все остальные сайты работают. У нас нет никаких перенаправлений портов или других правил файрвола, которые могли бы блокировать конкретный веб-хостинг. Это действительно странно. Любой сайт на этом веб-хостинге – и по моему знанию их 20 – не работает. Это позволяет сделать вывод, что они находятся на одном публичном IP. Но так же и панель управления для этого веб-хостинга, но, конечно же, на другом порту, к которому у нас есть доступ. Так что это возвращает нас к мысли, что, должно быть, какая-то фильтрация внутри сети Unifi блокирует доступ к веб-хостингу по портам 80 и 443. Хотя ничего подобного не настроено. Мы отключили все виды защиты и фильтрации для тестирования. Но мы по-прежнему не можем получить доступ к сайту(ах) на этом веб-хостинге. Значит, должно быть, что-то в сети Unifi фильтрует или блокирует этот доступ. Но где?

Мы дошли до точки, когда нам, возможно, придется сбросить сеть до заводских настроек и начинать всё заново – это огромный объем неоплачиваемого труда. Но кто знает, не вернется ли это снова? Я действительно ненавижу подобную ерунду, когда это ходит по кругу, и в конечном итоге какая-нибудь новая версия исправляет это, но никто не знает, что пошло не так в самом начале. Это подрывает доверие! Как можно доверять сети, которая случайным образом блокирует доступ без каких-либо следов того, как или где это происходит.

Этот клиент в бешенстве, а у нас нет ответов!

gregorio Guest	#16 21.04.2025 02:32:00 Правила межсетевых экранов не действуют, когда шлюз является конечным пунктом назначения. Нужно использовать LOCAL.

Читают тему (гостей: 1)