Перейти к содержанию

NoAdO

Участники форума
 Профиль  Обзор контента

  • Постов

    7

  • Зарегистрирован

  • Посещение

  • Победитель дней

    1

 Тип контента 

Сообщения, опубликованные NoAdO

    AdGuardHome

    в Каталог готовых решений Opkg

    Опубликовано · Изменено пользователем NoAdO

    Подскажите, пожалуйста. Делаю  

    opkg update
opkg upgrade
opkg find adguardhome-go

    Получаю результат 

    adguardhome-go - v0.107.44-1 - AdGuard Home is a network-wide software for blocking ads and tracking.

    Правильно ли я понимаю, что последняя актуальная версия в репозитории это .44-1? На гите числится последняя как v0.107.51, это задержка в обновлении репозитория? Нужно для вот этого фикса.

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано · Изменено пользователем NoAdO

    1 час назад, mr.robot сказал:

    Я поставил AGH в Entware, есть ли смысл в настройках роутера отключать

    По идее это не важно. Если все клиенты получают по параметрам сети IP роутера как DNS сервера, DNS сервером работает AGH а у него свой список куда стучаться, кто будет использовать эти неотключённые провайдерские сервера? Ради интереса отключил DNS провайдера в интернет-фильтрах - не изменилось вообще ничего. Если нет ни одного DNS там то AGH не резолвит ничего. Непонятно, как это связано, как будто транспорт запросов запрещается, но если есть хоть одна запись то резолвится по моим спискам вышестоящим, проверял на тех ресурсах которые у себя РФ забанили через DNS.

    E билайна при смене оборудования нужно зайти по адресу internet.beeline.ru который провайдерский DNS раздаёт из внутренних. Придётся позвонить и IP спросить при смене роутера. 🙃

    Но я не профессионал, могу ошибаться.

    1 час назад, mr.robot сказал:

    В топике про AGH пишут, что нет смысла шифровать и так мол никаких проблем не будет. Но я тут неуверен, так как слабо разбираюсь в теме. Буду рад вашему комментарию.

    Внутри локалки - конечно нет смысла шифровать, мы её считаем достаточно доверенной сетью. А вот снаружи.. в AGH я не нашёл функционала бана клиентов по mac, только по IP. То есть мало того что нешифрованный DNS мне андроид скорее всего не даст прописать, проблема ещё и в том что если кто-то решит использовать мой сервер DNS (в обоих случаях) избавиться я от него могу только сменой моего IP потому что динамику и сотовые сети по айпи банить бесполезно. В общем это какая-то своеобразная паранойя, даже если и подцепится то в DNS сервере ничего нет кроме блокировок, но у меня открыт только 853, через это я вроде как не попадаюсь на поиск DNS серверов по порту..  и меня это устраивает.

    1 час назад, mr.robot сказал:

    Правильно ли я понял, что домен у вас не сервисный от кинетика прикручен к роутеру?

    Верно, и это важно. 853 это DoT или QUIC и для установки шифрованного соединения нужен и домен и сертификат к нему. Но у меня белый IP и A-запись так что всё в порядке.

     

    Попутно поделюсь грустью: на моем KN-3810 фактически получается разогнаться только до 150/250 Мбит, при чём как в freedom так и в VPS, дело в скорострельности на этапе роутинга, получается. То есть любой клиент, к которому применена политика в роутере подлежит разбору трафика на предмет того куда его слать дальше и это ограничивает скорость, если я правильно понимаю.

    • Спасибо 2

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано

    18 часов назад, mr.robot сказал:

    Подскажите, как настраивали AdGuard Home для DoT/DoH на кинетике и телефоне?

    Логика работы в том, что AGH заменяет родной DNS сервер, то есть клиенты локальной сети всё так же работают с *.1 и внутри локалки это нешифрованные запросы. Сам AGH же имеет в основном списке серверов исключительно DoT, DoH вышестоящие серверы, нешифрованный DNS запрос идёт только к bootstrap серверам чтобы выяснить на каких IP живут DoH/DoT. Это, конечно, не очень хорошо, запрос может быть перехвачен, предоставлен неверный ответ, но в отзыве именно про это оговорка и есть. Таким образом единственный DNS для всех клиентов локалки это AGH, AGH не использует сервера провайдера, роутер не использует сервера провайдера а все запросы идут к списку с DoT/DoH серверами.

    Что касается телефона вне локальной сети, у меня белый IP и есть доменное имя, так что полученный сертификат добавлен в AGH и порт 853 открыт на роутер, что позволяет вписать доменное имя в строку "частный DNS сервер" прямо в настройках Android и получать данные так. Это нужно не столько для приватности, сколько для блокировки рекламы, которая реализована в AGH как списки доменов, для которых резолвится недействительный IP. В том числе поэтому я и не хочу от AGH избавляться.

    • Спасибо 1
    • Популярный пост
    • Популярный пост

    Xkeen

    в Каталог готовых решений Opkg

    Опубликовано · Изменено пользователем NoAdO
    изменён тестовый домен в примере на myip.com

    Ну что, попробовал я это чудо чудное диво дивное. По установке вопросов не возникло, а вот с конфигами пришлось повозиться и помощи в чате попросить. Пока непросто, надеюсь в будущем мы увидим мастер настройки что сам будет формировать json-ы да вот хотя бы на базе примеров из шапки под несколько типовых конфигураций. 

    Задача: в Интернет ходим как обычно, список выбранных доменов ходит через VPS где развёрнут 3X-UI с Reality. Голосовая связь должна работать (Discord и т.п.) так что Mixed режим. На роутере установлен AdGuard Home ( далее AGH), который также используется как DoT сервер для телефона не из дома так что DNS мы не трогаем (так-то могли бы и DNS туда завернуть). Помним, что в этом варианте даже если AGH использует DoT/DoH или прочие защищённые протоколы, ему всё равно надо у кого-то сперва спросить, на каком IP находится домен с DoT у которого он потом всё спрашивать будет. Это в AGH называется bootstrap DNS и провайдер этот запрос увидит, хоть ничего незаконного в использовании защищённых DNS и нет.

    Сразу оговорюсь: оказалось крайне полезно, что правила применяются на базе политик, задаваемых в роутере. Так что даже если мы "всё сломали", можно просто убрать политику и читать в интернете решение.

    Чтобы понимать логику работы, проще всего представить себе чёрный ящик со входом и выходами. Мы должны настроить что он входом будет пылесосить, какими выходами он плюёт трафик и правила, по которым он будет плеваться тем что спылесосил на входе в определённый выход.

    После установки по инструкции я залез в /opt/etc/xray/configs/ и (хоть и не сразу но) привёл их к вот такому виду. Это, скорее, пример реализации чем реальное руководство к действию. Конфиги сильно проще редактировать текстовым редактором на ПК, если хранилище роутера доступно из локальной сети. Тогда это путь вида \\Keenetic-9870\ext4\etc\xray\configs
    В inbounds (на момент написания комментария 03_inbounds.json) по сути менять относительно образца из Mixed конфига особо нечего. Разве что IP роутера, если вы назначили другие цифры. То есть редактировать надо там где есть комментарий с двумя слешами, между двойными кавычками:

    Скрытый текст 
    {
    "inbounds": [
        {
            "tag": "redirect",
            "listen": "192.168.0.1",    // IP адрес роутера, через который заходите в Web-интерфейс
            "port": 61219,
            "protocol": "dokodemo-door",
            "settings": {
                "network": "tcp",
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        },
        {
            "tag": "tproxy",
            "listen": "127.0.0.1",
            "port": 61219,
            "protocol": "dokodemo-door",
            "settings": {
                "network": "udp",
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ]
            },
            "streamSettings": {
                "sockopt": {
                    "tproxy": "tproxy"
                }
            }
        }
    ]
}

    Редактируется всего 1 значение в 1 строчке. 192.168.0.1 при необходимости меняется на ваш вариант. Всё.

    Как читать json: В целом json это скобки, вложенные в скобки, вложенные в скобки. Поэтому используются отступы слева чтобы понимать глубину вложенности. Это значит, что если я хочу понять, что относится к блоку "sniffing": { то я читаю всё до закрытия фигурной скобки }. В примере это "enabled": true, "destOverride": [ "http", "tls" ] разнесённый по нескольким строчкам. Так уже и попонятней, что читать. Notepad++ умеет выделять закрывающую скобку при щелчке по открывающей, это тоже помогает с пониманием или если вы вдруг скобку удалили и не понимаете, где. Ну а всё что после // и до конца строки это комментарий.

    image.thumb.png.4b2215dede3df2985966bd3e6d09eee4.png

    Посмотрите, насколько удобней читать. 

    В outbounds () уже сильно больше изменений. 

    Скрытый текст 
    // Настройка исходящих соединений

{
    "outbounds": [
  
    // VPS соединение  |  Основное
    {
            "tag": "vless-reality",    // Название соединения
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "██.███.███.██",    // IP адрес или доменное имя сервера VPS
                        "port": 443,    // Порт Reality. 443 обязателен
                        "users": [
                            {
                                "encryption": "none",
                                "flow": "xtls-rprx-vision",
                                "id": "████████-████-████-████-████████████"    // ID, присвоенный пользователю на сервере
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "publicKey": "█████████████████████████████████████",    // Public Key, присвоенный пользователю на сервере
                    "fingerprint": "chrome",    // Finger Print, указанный на сервере
                    "serverName": "█████████.██",    // SNI, указанный на сервере
                    "shortId": "████████",    // Short ID, присвоенный пользователю на сервере
                    "spiderX": "/"
                }
            }
        },
           
        {
      "tag": "direct",
      "protocol": "freedom"
        },
        
        {
      "tag": "block",
      "protocol": "blackhole",
            "settings": {
        "response": {
          "type": "http"
        }
      }
        }
    ]
}

     

    Сейчас мы редактируем "выходы" с чёрного ящика.

    Блок с "tag": "vless-reality" это "выход" траффика, который отправится в VPS. Мы ему этот тег будем назначать и дальше опишем, куда трафик отправляется. address - публичный айпи VPS. Порт 443 не меняется потому что у нас Reality, наш сервер работает "зеркалом" какого-то домена, а стандартный порт https - 443. Flow - xtls-rprx-vision потому что так указано в настройках на стороне 3X-UI. Мы вообще оттуда всё копируем. ID - это идентификатор пользователя, он написан в окошке редактирования пользователя.

    publicKey можно достать из окошка редактирования свойств Подключения в 3X-UI. Там же указан fingerprint (Поле uTLS), servername (поле Dest) и Short ID. Последнего, кстати, в X-UI я не нашёл вообще, потому и 3X-UI.

    То есть надо понимать, что я вот тут подробно пишу но понятия не имею почему нужно писать например             "settings": { "vnext": [ { а не как-то ещё. Для этого в шапке и лежат примеры, но разобраться что с чем стыкуется всё равно надо. 

    В целом же мой outbounds сообщает, что вот то что с тегом "vless-reality" идёт в VPS, что с тегом "direct" то идёт в "freedom" т.е. напрямую, а что с "block" то идёт в "blackhole" т.е. отбрасывается и никуда не идёт и вообще не тратим на это внимание и ресурсы, утруждая себя ответами.

    На сейчас мы разобрались, что мы ловим трафик, назначаем ему теги, запихиваем в чёрный ящик. И что из чёрного ящика может приходить траффик с другими тегами и его надо запульнуть в VPS, напрямую или в никуда. Осталось разобраться с правилами чёрного ящика.

    Скрытый текст 
    // Настройка маршрутизации

{
  "routing": {
    "rules": [
      // Правило 1 Настройка черного списка
      {
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "block",
        "type": "field",
        "domain": [
          "ext:geosite_v2fly.dat:category-ads-all",
          "google-analytics",
          "analytics.yandex",
          "appcenter.ms",
          "app-measurement.com",
          "firebase.io",
          "crashlytics.com"
          ]
      },

      // Правило 2 Блокируем соединение по уязвимым UDP портам
      {
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "block",
        "type": "field",
        "network": "udp",
        "port": "135, 137, 138, 139"
      },

        // Правило 3 Настройка подключений с помощью доменных имен  |  Внутри РФ
      {
        "inboundTag": ["redirect", "tproxy"],
        "outboundTag": "vless-reality",
        "type": "field",
        "domain": [
          //test
          "myip.com",
          // we are blocked
          "tmdb.org",
          "themoviedb.org",
          "radarr.video",
          "servarr.com",
          "tmdb-image-prod.b-cdn.net",
          "ext:geosite_v2fly.dat:facebook",
          "ext:geosite_v2fly.dat:instagram"
          ]
      },

        // Правило 4 Настройка остальных соединений  |  Вне РФ
        {
          "inboundTag": ["redirect", "tproxy"],
          "outboundTag": "direct",
          "type": "field"
        }
    ]
  }
}

     

    Опять же, разбираем код по кускам, комментариями на русском отмечены отдельные правила. К примеру, Правило 1 это мы ищем траффик с тегами ["redirect", "tproxy"] и назначаем ему тег "block" для доменов из списка, например analytics.yandex. То есть это улетает вникуда.

    Аналогично строится правило 3 для VPS - мы берём траффик с ["redirect", "tproxy"] и назначаем "vless-reality"  для доменов из списка. Обратите внимание, в списке есть английские комментарии. Я их просто для себя написал чтобы структурировать список. И да, вы тоже так можете.

    Ну и  правило 4 это опять мы смотрим трафик с метками "redirect", "tproxy" и помечаем его как "direct" (напрямую) без дополнительных условий, то есть весь остальной трафик что не попал в предыдущие правила.

    Момент с записями вида ext:geosite_v2fly.dat:facebook - как они составляются? Суть строки состоит в том что мы берём внешний (external) источник - аддон geosite_v2fly и оттуда спрашиваем список для facebook. Вот он: https://github.com/v2fly/domain-list-community/blob/master/data/facebook и там же рядом куча списков ещё. У facebook много адресов, можно аналогично поискать для себя другие крупные ресурсы. При редактировании списков не забудьте, что у каждой строки должна быть запятая в конце, кроме последней.

    При диагностике проблем пробуйте достучаться до сайтов из разных фильтров. Иногда это помогает в диагностике. К примеру, если работает умолчание но не работает VPS-путь, возможно что-то с правилом туда или с самим выходом. Ну или вы забыли применить политику к этому ПК 😃 Мне на старте вот этого понимания не очень хватало чтобы разобраться, что я и куда пишу. А ещё есть 01_log.json где можно выставить логгирование побольше и почитать логи. Только не забудьте обратно отключить потом.

    Ну, вот так как-то. Просили отзыв - вот отзыв =))

    • Спасибо 3
    • Лайк 10
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю