Автор, не обижайтесь но покритикую. Без fakedns, который сейчас стандарт-дефакто, ваша схема выглядит как велосипед. Особенно с adguard, который нет-нет, да уже подставлял. Только на dot и doh полагаться нельзя, надо использовать оба, а еще лучше иметь failsafe на случай падения обоих. Убирать их схемы dnsmasq считаю неправильным, лучше понять его и полюбить, зато в случае чего у вас роутер не останется без dns. Качать чужие dat, тем более в /tmp - а если не скачается? А если битым скачается? А если авторы листов сойдут с ума и раздуют до размера не совместимого с жизнью? Не используйте чужие листы, да геморно, но составляйте свои. quic не страшный. udp тоже проксируется, нет в этом никакой проблемы. ipv6 точно так же легко добавляется в схему, для него только что надо тот же fakedns настроить. Под ipset можно написать собственные обработчики, тот же firewall позволяет вам использовать user скрипты. Ну и схема в кучей серверов - я не знаю, может у вас используется куча дохнущих серверов из подписки, но по-моему лучше использовать 1-2 своих. В идеале вообще каскад (я думаю вы сами в состоянии придумать)... Просто не рационально заводить 5-6 vps и по пингу решать какую использовать. Завтра может все заблочат, выбирать будет не из чего. Хорошо если роутер у вас один, но вы же небось друзьям и знакомым схему настроили. Я не знаю в каком сообществе вы состоите, может сами через документацию всю схему придумывали (хотя есть паттерны, которые говорят что точно вдохновлялись), но таки поищите в тг... Статья крутая для понимания xray, хотя документация на мой взгляд у xray хорошая. Для средней прокачености юзера обычно хватает подкопа. Кстати у xray есть свои неочевидные минусы, может еще столкнетесь. Желаю вам успехов.
Хорошая статья. Непонятно только зачем указывать домен, если и без него всегда все работает. Может есть какие-то исключения, но я не сталкивался. И конечно сети из 50 mp у меня нет.
Если стоит auto, рано или поздно нигде работать не будет.
Плюшки - ну это становится заметно если mesh нод у вас много. Они самоорганизуются, сами строят между собой маршруты, сами их перестраивают в случае чего. А sta вы прибиваете роутер к конкретной точке.
Mesh на каждом радио это то как представляют себе работу mesh, юзеры на проприетарных прошивках. Поэтому это надо объяснять еще и с точки зрения что это возможно, но есть нюансы.
Хорошо бы рассказать почему не получится подружить проприетарную реализацию easymesh с openwrt 802.11s
Еще кстати объяснить бы что mesh по проводу это не mesh. Но тут совсем сложно…
Mesh это отдельный интерфейс. Грубо говоря можно взять провод, соединить два роутера, а если провода нет, можно взять mesh. Правила по сути такие же, как если ды вы соединяли два роутера проводом. Далее ваше дело что делать с интерфейсов mesh, натить или бриджевать (со всеми вытекающими).
Из важных нюансов, хочется сказать про каналы. Если вы на физическом радио0 поднимаете mesh и ap, они оба будут использовать один и тот же канал. Нельзя получить 6 канал для ap и 11 для mesh на одном радио. Так же как и нельзя соединить две mesh ноды разными каналами.
А еще хочется сказать про stp. Можно в теории поднять по mesh на каждом радио, забриджевать все в lan, включить stp и радоваться. Только без доп пиналки типа dawn чаще всего роутеры будут соединяться по 2.4Ghz. Если автор статьи знает как сделать выбор несущей более разумным, прошу описать в следующей статье.
Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu. Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq) nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом: Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера. Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать] udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом] udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает. Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.
А чем плохо выставить фронтом xray, а уже после него fallback nginx?
Автор, не обижайтесь но покритикую. Без fakedns, который сейчас стандарт-дефакто, ваша схема выглядит как велосипед. Особенно с adguard, который нет-нет, да уже подставлял. Только на dot и doh полагаться нельзя, надо использовать оба, а еще лучше иметь failsafe на случай падения обоих. Убирать их схемы dnsmasq считаю неправильным, лучше понять его и полюбить, зато в случае чего у вас роутер не останется без dns. Качать чужие dat, тем более в /tmp - а если не скачается? А если битым скачается? А если авторы листов сойдут с ума и раздуют до размера не совместимого с жизнью? Не используйте чужие листы, да геморно, но составляйте свои. quic не страшный. udp тоже проксируется, нет в этом никакой проблемы. ipv6 точно так же легко добавляется в схему, для него только что надо тот же fakedns настроить. Под ipset можно написать собственные обработчики, тот же firewall позволяет вам использовать user скрипты. Ну и схема в кучей серверов - я не знаю, может у вас используется куча дохнущих серверов из подписки, но по-моему лучше использовать 1-2 своих. В идеале вообще каскад (я думаю вы сами в состоянии придумать)... Просто не рационально заводить 5-6 vps и по пингу решать какую использовать. Завтра может все заблочат, выбирать будет не из чего. Хорошо если роутер у вас один, но вы же небось друзьям и знакомым схему настроили.
Я не знаю в каком сообществе вы состоите, может сами через документацию всю схему придумывали (хотя есть паттерны, которые говорят что точно вдохновлялись), но таки поищите в тг...
Статья крутая для понимания xray, хотя документация на мой взгляд у xray хорошая. Для средней прокачености юзера обычно хватает подкопа. Кстати у xray есть свои неочевидные минусы, может еще столкнетесь. Желаю вам успехов.
Хорошая статья. Непонятно только зачем указывать домен, если и без него всегда все работает. Может есть какие-то исключения, но я не сталкивался. И конечно сети из 50 mp у меня нет.
Я видимо плохо объясняю, а вам видимо нужно пройти весь путь самостоятельно.
Еще кстати, раньше по крайней мере, был нюанс что при такой схеме если забриджевать все в одну сеть, от sta dhcp не работал.
Если стоит auto, рано или поздно нигде работать не будет.
Плюшки - ну это становится заметно если mesh нод у вас много. Они самоорганизуются, сами строят между собой маршруты, сами их перестраивают в случае чего. А sta вы прибиваете роутер к конкретной точке.
Честно говоря одна из самых скотских ИТ специальностей. А еще уровень токсичности в профессии запредельный.
Mesh на каждом радио это то как представляют себе работу mesh, юзеры на проприетарных прошивках. Поэтому это надо объяснять еще и с точки зрения что это возможно, но есть нюансы.
Хорошо бы рассказать почему не получится подружить проприетарную реализацию easymesh с openwrt 802.11s
Еще кстати объяснить бы что mesh по проводу это не mesh. Но тут совсем сложно…
Mesh это отдельный интерфейс. Грубо говоря можно взять провод, соединить два роутера, а если провода нет, можно взять mesh. Правила по сути такие же, как если ды вы соединяли два роутера проводом. Далее ваше дело что делать с интерфейсов mesh, натить или бриджевать (со всеми вытекающими).
Из важных нюансов, хочется сказать про каналы. Если вы на физическом радио0 поднимаете mesh и ap, они оба будут использовать один и тот же канал. Нельзя получить 6 канал для ap и 11 для mesh на одном радио. Так же как и нельзя соединить две mesh ноды разными каналами.
А еще хочется сказать про stp. Можно в теории поднять по mesh на каждом радио, забриджевать все в lan, включить stp и радоваться. Только без доп пиналки типа dawn чаще всего роутеры будут соединяться по 2.4Ghz. Если автор статьи знает как сделать выбор несущей более разумным, прошу описать в следующей статье.
Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Эх, сейчас бы снова XIP пересобирать.
Просто совет для тех кому в конфиг sing-box сложно. Бейте секции на отдельные json и делайте merge в один.
Пользуюсь случаем, хочу сказать какая-же отстойная у sing-box документация
Спасибо, вторая пошла шиться. Добавьте тогда bzt33cyu что ли в список поддерживаемых.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu.
Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu
Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Интересно, а батарейку начнет адекватно показывать наконец?
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq)
nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом:
Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера.
Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать]
udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом]
udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает.
Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.