Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
UniFi Network Debugger, UniFi Network
 
У меня жуткие проблемы с настройкой VLAN и обеспечением безопасности моих важных устройств. Даже если сегодня я всё настрою правильно, нет гарантии, что завтра я что-нибудь не сломаю. Чтобы это исправить, я хотел придумать способ как-то тестировать эти конфигурации.

Если мой IP-адрес — X, и я подключен к порту 3 свитча Y, и я на VLAN по умолчанию, и я отправляю multicast-сигнал, то устройство Z (с IP-адресом А и портом В) должно его получить.

Так почему бы не сделать это частью UniFi? Я уверен на 100%, что у ребят из UniFi уже есть интеграционные тесты в их коде, поэтому нам тоже стоит их разрабатывать. Эти тесты можно хранить в контроллере, и если кто-то изменит настройку, это может сломать тест. Это сразу скажет мне, что именно сломалось, и готов ли я к этому изменению или нет. Если я готов, нужно обновить тест.

Это лучше, чем слепо настраивать конфигурации, надеясь, что они всегда будут работать, и это предоставляет механизм отслеживания ожидаемых настроек безопасности в UniFi обновлениях.

Есть ли какое-нибудь программное обеспечение, которое позволяет это делать сегодня за пределами UniFi? Оно не будет таким надежным, потому что у него не будет доступа ко всем правилам брандмауэра и маршрутизации UniFi, но это наверняка поможет!
 
Думаю, проблема в том, что нужно понимать, как устроены используемые реализации. Правила файрвола обычно завтра не изменятся. Возьмем, к примеру, FTP. Предположим, мы не знаем, как это работает, и выяснили, что соединение клиента с FTP-сервером использует порт 21 и порт 46789. Мы разрешаем эти исходящие соединения, и FTP работает. Следующее соединение (возможно, завтра) будет сломано, потому что мы не знали, что оно будет случайным образом выделять дополнительный порт 46789, а сегодня это порт 55321. Наши правила файрвола все еще в порядке, они не предназначены для FTP, а для того, как мы предположили, будет работать FTP. Так что наша задача — разобраться и проанализировать трафик или почитать документацию о том, как происходит связь. После этого мы составляем правильный набор правил, который будет работать и завтра. В случае FTP лучше, чтобы кто-нибудь написал прокси-приложение, кстати, иначе мы не сможем безопасно пропускать через файрвол вещи, недружелюбные к NAT, например, Active/Passive FTP. Такие прокси сейчас встроены, а когда я начинал заниматься файрволингом, этого не было, забавные времена.
Страницы: 1
Читают тему (гостей: 1)