Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
+7 (495) 108-0-888 info@ubiquiti.ru
Каталог
+7 (499) 350-36-46 info@ubiquiti.ru
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Форумы: UniFi Protect, UniFi Network, UniFi Access, UniFi Talk, UniFi Drive, UniFi Mobility, UniFi Connect, UniFi Play, Wifiman, Feature-request, Site-manager, Edgemax, airfiber-ltu, unifi-led, unifi-voip, solar, security, link, aircontrol, unifi-video, new-to-unifi, ufiber, unms, Airfiber, Innerspace, ISP-design-center, Airmax, UISP-app, UID, 60GHz, General
Поиск  Пользователи  Правила  Войти
Страницы: 1
RSS
Unifi и VirtualBox, HTTPS не работает., UniFi Network
 
#1
02.01.2025 14:51:00
Привет! У меня вот какие устройства Unifi: У меня ноут подключён к Wi-Fi, на нём VirtualBox VM с настроенной bridged сетью. Эта VM получает IP в той же сети, что и мой ноут (bridged mode), HTTP работает, а вот HTTPS — нет. Ну, как несложно догадаться, если подключаюсь к другой Wi-Fi сети, не использующей Unifi, всё работает. Есть какие-нибудь подсказки, где искать проблему?
 
 
 
#2
03.01.2025 12:02:00
VPN все равно лучший вариант. То есть, ты доказал, что проблема где-то в Unifi. По умолчанию ничего не блокируется при выходе, только правила могут что-то изменить, так что, очевидно, проблема в настройках Wi-Fi, если по Ethernet все работает. Попробуй создать еще одну VLAN и подключить к ней другой SSID для временного теста и посмотри, что произойдет.
 
 
 
#3
03.01.2025 11:41:00
Да, знаю, но с 500M оптоволокном и дешевой электроэнергией я предпочитаю держать сервер дома, чем использовать aws или azure. Насчет проблемы, я вообще не понимаю, где искать. Сделал еще 2 теста: запустил точку доступа с телефона, подключил ноутбук к этой новой сети Wi-Fi, запустил VM, и HTTPS работает как положено. Подключил ноутбук через Ethernet вместо Wi-Fi, изменил VM на bridge к сетевой карте Ethernet вместо Wi-Fi, запустил VM и HTTPS тоже работает. А вот когда подключаю ноутбук обратно к сети UniFi Wi-Fi, перезагружаю VM, HTTPS уже не работает.
 
 
 
#4
03.01.2025 10:37:00
Перенаправление портов — это очень слабое место с точки зрения безопасности. Ожидай много атак на открытые порты, вроде HTTP/S. Похоже, что ты запускаешь много сервисов с удаленным доступом. Тебе действительно нужны эти порты открытыми? VPN — гораздо более безопасный способ удаленного доступа к твоей сети. Ничего очевидного по HTTPS не вижу, но, как уже говорилось, по умолчанию ничто не должно блокировать HTTPS из твоей сети.
 
 
 
#5
03.01.2025 10:24:00
Я настроил перенаправление портов, но не помню, чтобы трогал что-то еще в брандмауэре:
 
 
 
#6
03.01.2025 10:17:00
Ну и какие у вас правила, в конце концов? Есть ли среди них что-то, касающееся HTTPS?
 
 
 
#7
03.01.2025 10:09:00
Всё очень быстро:
 
 
 
#8
02.01.2025 17:35:00
Сколько времени проходит, прежде чем curl возвращает ошибку 35? Возможно, у вас проблема с MTU. Попробуйте curl -v (и уберите > /dev/null), чтобы посмотреть, где именно происходит сбой в процессе SSL handshake. Очевидно, что нарушать https — это не стандартная функция оборудования UniFi. Что-то еще в вашей сети настроено не так, и это вас подводит.
 
 
 
#9
02.01.2025 16:39:00
Вот результат, но опять же, http и https — это оба TCP, и проблема не в TCP. Как видите ниже, я могу tracepath, я могу http, но не могу https. И снова, это проблема только внутри VM в режиме bridge. Значит, есть проблема с шифрованием с вторичного/виртуального IP, идущего с виртуального MAC-адреса?
 
 
 
#10
02.01.2025 16:23:00
traceroute использует UDP (опционально ICMP), а не TCP, и использует последовательные номера портов. Тебе нужен tcptraceroute или tracepath.
 
 
 
#11
02.01.2025 15:03:00
Ну, тут, конечно, не приходится говорить, что это будет работать на одной сети и не работать на другой. Судя по твоим скриншотам, HTTPS блокируется на твоей сети. Пробей traceroute до внешнего сайта и посмотри, где он обрывается.
 
 
 
#12
03.01.2025 17:26:00
Ну ладно, это вообще не связано с Unifi. Проклятый firewalld на ноуте засунул одну вайфай в другую зону, и я понятия не имею, в чем разница, но я удалил все настройки для firewalld, перезагрузился, и теперь все работает. Еще я не понимаю, почему firewalld мог отбрасывать только TLS-трафик с бриджового интерфейса. Ненавижу firewalld, хотелось бы, чтобы он исчез ночью, но спасибо всем за помощь.
 
 
 
#13
03.01.2025 17:22:00
Странно. А что, если создать новую VLAN, но перенастроить существующий SSID так, чтобы он использовал эту новую VLAN? Не создавать новый SSID, чтобы сохранить пароли и всё такое. Просто тогда все устройства на этом SSID придётся перезагрузить, чтобы они получили новый диапазон IP-адресов.
 
 
 
#14
03.01.2025 15:53:00
Согласен, думаю, мы близки к решению. Я создал новую Wi-Fi сеть, и все работает. А потом я удалил старую Wi-Fi сеть и воссоздал её с тем же названием и паролем, чтобы не пришлось перенастраивать все мои IoT-устройства. Но опять не работает. Есть ли что-то, что я могу сделать, чтобы очистить остатки старых настроек перед созданием новой сети? Кажется, она что-то подхватывает от старой.
 
 
 
#15
02.01.2025 15:20:00
Попробуй выполнить traceroute -p 443 google.com. Есть ли какие-нибудь правила, блокирующие доступ к консоли по HTTPS, и есть ли правило, которое блокирует весь HTTPS?
 
 
 
#16
02.01.2025 15:16:00
Определенно заблокировано на моей сети, потому что тот же ноутбук и vm работают на других сетях. Но как мне сделать traceroute по HTTPS? Раз обычный HTTP работает, это не проблема с подключением по TCP — я могу подключаться к удаленным сайтам, но всё ломается, когда дело касается шифрования.
 
 
 
Страницы: 1
Читают тему (гостей: 1)