-
Постов
697 -
Зарегистрирован
-
Победитель дней
11
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Denis P
-
разве если повесить его через веб на "Home" не будет того же эффекта? как раз output из-за security level private
-
Это тоже локальный адрес, он вам не мешает. Можете убедиться в выводе ip a конкретно интерфейс ezcfg0 Но если это принципиально: ip http proxy cloud no dns-override
-
В основном это ситуация при разворачивании "офлайн" инсталера с уже готовым набором пакетов и скриптами Т.е приходится дергать интерфейс чтобы подхватилось из netfilter.d. не сказать что это прям создает сильный дискомфорт, но если есть какой-то вариант этого не делать, кроме ручного запуска скриптов, было бы удобнее)
-
уже реализовано в cli, можно конкретные маршруты привязать к конкретным политикам IP: добавлены настройки статических маршрутов, специфичных для политики [NDM-3435]: ip policy {name} ip route ( {network} {mask} | {host} ) ( {gateway} [interface] | {interface}) [auto] [metric] [reject] ip policy {name} ipv6 route {prefix} ( {interface} [gateway] | {gateway} ) [auto] [metric] [reject]
-
@Le ecureuilвсё еще актуально последний раз воспроизвелось include'ом интерфейса USB сетевой карты в Bridge0 дергаем любой интерфейс (down/up) - loopback снова работает
-
Собственно проблема указана в заголовке Заводим нового пользователя -> даем ему права администратора -> создаем пароль -> Пользователь создается без пароля. Что чревато потерей удаленного доступа к вебу: Тема создана именно в разделе о ПО, а не приложения, потому что по словам одного из разработчиков она касается именно прошивки да и на 4.2.6 такого поведения нет
-
немного влезу, но попутно задам один вопрос, который тоже касается netfilter каким-то образом можно инициализировать его перезапуск не трогая политики/интерфейсы/правила переадресации/мсэ и остальное что служит тригером для его перезапуска? т.е грубо говоря вручную заставить перечитать скрипты которые лежат в netfilter.d не меняя параметры системы
-
Запрещающее правило создано при этом?
-
Зачем же вы тогда создаете разрешающее правило в мсэ, если при пробросе порта это не требуется? Имеет смысл только запрещающее, если нужно ограничить доступ временно или в соответствии с определенными критериями
-
Так у вас настроена и переадресация и правила в мсэ?
-
Перед тем как написать, проверил на нескольких устройствах с 4.2.х из стабильной ветки и на 4.3.b4. В первом случае не воспроизводится. Во втором - отключение правила срабатывает с задержкой
-
Вернитесь на ветку stable, там такой проблемы нет.
-
Подтверждение пароля очень важная вещь, особенно на устройствах которые могут находится на огромном удалении от администратора. Если при одиночном вводе была допущена ошибка, это может привести к довольно печальным последствиям, огромная просьба вернуть второе поле для ввода
-
всё верно, но чтобы не мучаться с *.io, ту же процедуру можно проделать и с crazedns доменами и пригвоздить их к адресам интерфейсов wg удаленных устройств
-
Откройте для себя команду ip host
-
Так и пользуйтесь, в чем проблема? Через wg тоже можно ходить на веб по https до пиров Домены *.io отображаются в явном виде прямым текстом, если не получен собственный домен. Выглядит это всё, пока что, как надуманные проблемы в вакууме.
-
уже всё сделано за вас есть целых два варианта ходить по HTTPS из локалки: 1)заходим в раздел домены и наблюдаем там служебный домен *.io - ходим по нему и спим спокойно, естественно ограничив доступ по 80 порту для локальных клиентов 2)регистрируем себе домен через keendns crazedns и см. выше^ з.ы получить сертификат на частные адреса нельзя, по этому и ходить на https://192.168.1.1 не получится. Мы ведь не хотим пользоваться самоподписными сертами, да?
-
Только не те, к которым вы пришли. В stable проблем нет. Разработчик вам выше ответил что в beta3 тоже будет всё исправлено. Остальное это только лишь ваша фантазия