Датчик запитывается на считанные доли секунды раз в несколько минут, как раз, чтобы исключить даже самое минимальное влияние нагрева в процессе измерения. Сам датчик выносится от основной схемы подальше, а вокруг него в плате делаются технологические зазоры, как в импульсных блоках питания, чтобы минимизировать передачу тепла к нему по плате, видел такие рекомендации в каком то даташите. Или вообще выносится на проводах в виде отдельной платы. Тогда температура его подложки и всего датчика целиком будет равна температуре окружающего воздуха.
Тогда нужно будет добавлять собственные правила в iptables
Вот я как то на это и рассчитывал. Я думаю, это более правильный подход для домашней сети, чтобы на всех устройствах все работало из коробки, без необходимости установки дополнительных программ. А все настройки производить на роутере и на домашнем сервере.
А если я хочу трафик от всех компьютеров в сети через него завернуть? Как тогда быть?
На CentOS он, кстати, не запускается, требует GLIBC 2.15, а такой версии в репозиториях нет.
Ну да, с ReQrypt. Вот запустил я его под виндой или на домашнем сервере, как теперь исходящий трафик через него пустить?
Серверы понятно, что не работают. Но там же исходники есть, можно будет свой сервер поднять.
А можете подсказать, как с ним работать правильно? На какой порт трафик перенаправлять? Может готовые правила iptables есть? На сайте как то скудно информация предоставлена.
А, вы хотите, как с antizapret, автоматически заворачивать туда только заблокированное?
Add DPI circumvention
А в чем смысл, если исходящий трафик и так будет идти через прокси?
Можно же вообще весь трафик по 80 порту через iptables на роутере завернуть в этот прокси, и со списками возиться не придется и провайдерские прослушивающие прокси минуем. Там на 99% будут короткие http запросы, трафик через прокси должен быть вообще минимален.
Проблемы негров гиков и отдельно взятых пользователей провайдеров не волнуют. Все лимиты будут рассчитываться из расчета на среднего пользователя. А средний пользователь это вк, танки, ютаб, и фильмы с торрентов в субботу по 1,4Гб без раздачи, там и сотни Гб в месяц не наберется.
Представьте, сколько жестких дисков придется закупать провайдеру, только для хранения вашего трафика, это огромные деньги, которые не окупятся вашей абонентской платой и за несколько лет.
Смутные времена настают…
Сейчас потихоньку дорабатываю ReQrypt под российские реалии
Интересный принцип работы. Особенно актуально для трекеров (не сайтов), которые определяют ip пира по REMOTE_ADDR. И использование прокси или vpn ломает нормальное функционирование системы, человек может качать, но вот раздавать — лишь частично (как из под nat), т.к, личеры будут пытаться подключиться к ip адресу прокси или vpn.
А в чем заключается доработка под российские реалии? https через нее тоже можно проксировать?
У меня meduza.io несколько дней уже не открывается, послание от 14-летнего мальчика тоже не открывается, и вобще последние дни много рандомных страниц не открывается.
Крутая железка, жаль процессор AES инструкции не поддерживает, для домашнего роутера это теперь желательно, чтобы всякие шифрованные vpn каналы держать.
Вот кстати, согласен. Многих так почитаешь, складывается впечатление, что завести трактор, это проще, чем сменить съемное жилье, типа взял и просто уехал.
Подтверждаю на счет перехвата dns, мой провайдер так делает, причем независимо от того, к какому серверу я обращаюсь. Видимо, все запросы на 53 порт проксируются и прослушиваются, заблокированные домены подменяются.
Это лечится dnscrypt`ом или заворачиванием dns запросов через vpn туннель. С dnscrypt крайне рекомендую разобраться в любом случае, очень актуальная вещь в нынешних условиях, настроил у себя на роутере и теперь провайдер не может подменять запросы.
nnm-club через ipv6 отлично работает, не далее, как вчера, я как раз настроил себе туннель. Захожу по ipv6.nnm-club.me.
Только рутрекер это и умеет, на сколько я понимаю.
Вот я как то на это и рассчитывал. Я думаю, это более правильный подход для домашней сети, чтобы на всех устройствах все работало из коробки, без необходимости установки дополнительных программ. А все настройки производить на роутере и на домашнем сервере.
На CentOS он, кстати, не запускается, требует GLIBC 2.15, а такой версии в репозиториях нет.
Серверы понятно, что не работают. Но там же исходники есть, можно будет свой сервер поднять.
А в чем смысл, если исходящий трафик и так будет идти через прокси?
Можно же вообще весь трафик по 80 порту через iptables на роутере завернуть в этот прокси, и со списками возиться не придется и провайдерские прослушивающие прокси минуем. Там на 99% будут короткие http запросы, трафик через прокси должен быть вообще минимален.
негровгиков и отдельно взятых пользователей провайдеров не волнуют. Все лимиты будут рассчитываться из расчета на среднего пользователя. А средний пользователь это вк, танки, ютаб, и фильмы с торрентов в субботу по 1,4Гб без раздачи, там и сотни Гб в месяц не наберется.Представьте, сколько жестких дисков придется закупать провайдеру, только для хранения вашего трафика, это огромные деньги, которые не окупятся вашей абонентской платой и за несколько лет.
Смутные времена настают…
Интересный принцип работы. Особенно актуально для трекеров (не сайтов), которые определяют ip пира по REMOTE_ADDR. И использование прокси или vpn ломает нормальное функционирование системы, человек может качать, но вот раздавать — лишь частично (как из под nat), т.к, личеры будут пытаться подключиться к ip адресу прокси или vpn.
А в чем заключается доработка под российские реалии? https через нее тоже можно проксировать?
Это лечится dnscrypt`ом или заворачиванием dns запросов через vpn туннель. С dnscrypt крайне рекомендую разобраться в любом случае, очень актуальная вещь в нынешних условиях, настроил у себя на роутере и теперь провайдер не может подменять запросы.
nnm-club через ipv6 отлично работает, не далее, как вчера, я как раз настроил себе туннель. Захожу по ipv6.nnm-club.me.