Давайте попробую объяснить. Для маршрутизации траффика до контейнера нам вполне достаточно динамических маршрутов, которые автоматически будут созданы в момент создания бриджа.
ip/route/print where gateway="containers"
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAc 172.20.0.0/24 containers 0
ipv6/route/print where gateway="containers"
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, DISTANCE
# DST-ADDRESS GATEWAY DISTANCE
DAc fd08:172:20::/64 containers 0
DAc fe80::%containers/64 containers 0
Ну а дальше мы просто создаём WG интерфейсы и пиры для каждого inbound в контейнере
Дальше нам нужно повесить на интерфейсы WG какие-нибудь IP адреса, любые, из приватного диапазона(по ним будет идти маршрутизация только до приложения в контейнере). Например так. Опять же, в целом можно без этого, т.к. маршрутизировать мы будет тупо по интерфейсу, но некрасиво.
Здесь мы отправляем всё, что будет в соотв. адрес листе в соотв. ему таблицу маршрутизации. Если нужно заворачивать несколько адрес листов в один интерфейс или как-то более гибко рулить всем этим безобразием - можно добавить свои цепочки и делать в них jump. Напр. как-то так:
В этом примере я создал для ipv6 отдельную цепочку prerouting_warp, в которой заворачиваю траффик в таблицу warp и помечаю соединение(можно собрать любое количество нужных правил). При этом проверяю, что коннект не идёт на адреса из списка, подключение до которых ни в коем случае не должно происходить через VPN - в качестве защиты от своих кривых рук. Ну и дальше двумя правилами закидываю в эту цепочку траффик для адресс листов youtube и facebook. Можно так, можно как в предыдущем примере - в зависимости от подхода и решаемой задачи. Как больше нравится и как удобнее.
Ну и вишенкой на торте - создаём маршруты в дикий интернет для наших новых таблиц маршрутизации
Наверное заработает, я лично не пробовал. Проблем вижу две - во первых, банально сложнее дебажить, т.к. даже шелл внутри контейнера с xray-core не открывается, уж не знаю почему). А во-вторых, dokodemo-door - это в любом случае один интерфейс, соотв. мы можем иметь только один аутбаунд(если не морочиться с маршрутами на уровне самого xray). А вот WG-интерфейсов можно наплодить сколь угодно много. Простота, единообразие, и возможность при минимальном изменении конфига утащить контейнер куда угодно(хоть на другой комп в ЛВС, хоть на удалённую площадку). При этом в приложении к использованию дома я вообще не вижу никакого пенальти по производительности(скорее всего если начать пытаться рулить сотнями одновременных подключений и гигабитными каналами разница вылезет, но у кого есть реально такие задачи - тот точно не будет разворачивать сервис в недодокере на роутере)
Хех. Лично мне больше понравился n1, как-то он для дома выглядит покомпактнее. Хотя если нужен хотсвап дисков - n2 конечно лучше. И если честно - не вижу смысла в спец ОС для NAS, по крайней мере в приложении к домашней хранилке. Обычный дебиан справится не хуже.
В общем случае вам нужны две ключевые пары из публичного и приватного ключа. Генерятся они любым удобным способом, главное чтоб публичная часть ключа соответствовала приватной. По конфигам раскалдываются каким-то таким образом
/interface/wireguard/print
Flags: X - disabled; R - running
4 R name="WARP-WG" mtu=1420 listen-port=13234 private-key="PrivkeyA"
public-key="PubkeyA"
/interface wireguard peers
add allowed-address=0.0.0.0/0,::/0 endpoint-address=172.20.0.2 endpoint-port=3125 interface=WARP-WG name=peer5 public-key=\
"PubkeyB"
При этом на самом деле PrivkeyA в конфиге сервера по большому счёту не должен быть нужен, не знаю зачем он его хранит - может это последствия генерации конфига через x-ui. Короче общая логика тут крест-накрест. С каждой стороны(и на сервере и на клиенте) есть конфиг интерфейса WireGuard, где живёт приватный ключ. К нему будут подключаться с публичным ключём те, у кого сконфигурен соотв. пир. И есть конфига пира с публичным ключом, к котому он сам в свою очередь будет подключаться. По сети идёт обмен именно публичными ключами, которые сравниваются с приватными.
На микроте ставим пакет с контейнерами, ребутаемся, включаем контейнеры /system/device-mode/update container=yes На железке после этого нужно будет нажать кнопку mode за ограниченное время, удалённо включить контейнеры не выйдет, т.к. потанцевальная дыра в безопасности. Дальше создаём VETH для нашего контейнера, создаём отдельный бридж для контейнеров, навешиваем туда ip адреса(я тут добавляю и ipv6 и ipv4 адрес. На самом деле для схемы с роутингом через WG интерфейс достаточно только v4, но у меня все контейнеры настроены единообразно, так что для общего понимания оставлю)
Последние два правила если что рождены в попытке заставить работать схему с byeDPI, для xray это тоже не нужно(при условии что вы отправляете траффик на ipv4 адрес. Если у вас ipv6-only VPS - то нужно, всё нужно) Дальше втыкаем в микрот флешку, из интерфейса форматируем её в EXT4(Обязательно! Иначе при распаковке контейнера порушатся разрешения фалов и ничего не взлетит) Конфигурим местный докер
Аттеншн! Тут ram-high=384.0MiB - это конфиг для AX3 с гигом оперативы. У AС3 её всего 256Мб и с пустым конфигом и установленным пакетом wifi-qcom доступно примерно 145Мб(а с подробным конфигом и под нагрузкой - что-то около 70Мб). У AC2(128Мб) при таких же вводных доступно и того меньше - всего примерно 30Мб. Для AC2 вероятно придётся вообще перейти на легаси Wifi драйвер, иначе с ресурсами ну совсем грустно. Соотв. выставляем параметр с запасом, так чтоб и самому роутеру хватило. При превышении лимита процессы в контейнере начнут нещадно троттлиться, т.е. работать будет, но с дикими тормозами. А вот если память у роутера закончится - скорее всего он тупо крашнется. Не доводим и не включаем старт контейнера при загрузке пока не отладим всё. Скачиваем образ
После этого можно попробовать его стартануть и убедиться что всё найс и ничего не сыпется. Дальше нужно приготовить конфигу xray (файлик config.json) Либо выдёргиваем его из /usr/local/x-ui/bin/config.json (не с сервера разумеется, а с заранее где-то настроенной клиентской инсталляции x-ui. В самом конфиге придётся поправить ip-шники при этом, очевидно), либо пишем ручками. Должно получиться что-то такое
Тут у меня конфига на два входа и к ним два выхода - в WARP и в свой VLESS VPN Подкидываем эту конфигу на флешку по пути /usb1/xray/ Добавляем маунт поинт и привязываем его к контейнеру
Всё, дальше совсем легко. Любым удобным способом настраиваем Wireguard подключения к нашему контейнеру, добавляем таблицы маршрутизации, настраиваем удобный нам вариант заворота траффика. Мануалов про эту часть в сети полно.
ИМХО xray удобнее цеплять через wireguard. Xray поддерживает его в качестве инбаунда и не нужен второй контейнер. Особенно актуально становится когда в xray заведено несколько профилей VPN, тогда вместо 2+ доп. контейнеров просто добавляем нужное количество входных wireguard интерфейсов и настраиваем маршрутизацию 1к1 по выходным интерфейсам. Да, wireguard туннель, не выходящий за пределы роутера выглядит довольно странным решением, но это работает, потерь по производительности нет а по ресурсам гораздо выгоднее.
Сам. Это проще чем может показаться. В том же Solidworks есть шикарная встроенная обучалка, которая позволит сносно моделить уже через несколько дней. Тонкости оформления чертежей по ЕСКД оно конечно не раскроет - но оно нам и не надо). И если есть навыки обращения со штангенциркулем - всё обязательно получится.
Проблема именно в том что пробовал, потому и осуждаю. В несостоятельности термоклея вы можете убедиться самостоятельно, вплавив в клеевой стержень резьбовую втулку, вкрутив винт и выдернув оную втулку буквально от руки( в крайнем случае пассатижами если нет удобного длинного винта под рукой, но точно не прикладывая особых усилий). Если у вас ваши методы работают долгие годы - вы вероятно либо очень везучий человек, либо просто не сталкивались со случаями, когда крепление петель идёт недоделанным с завода, либо когда в силу уронения об кафель родным посадкам наступает полный и безотлагательный карачун. Волею случая на этих выходных у жены сломалась петля на её MSI b4 modern(как раз вариант с изначально некомпетентной конструкцией).
Как можно заметить на фото - спасать тупо нечего, крепление уничтожено
Поэтому на помощь приходит её величество переходная пластина(благо модель я сохранил. Правая петля отлетела спустя 5 месяцев после покупки и после ремонта живёт уже третий год)
Перфорация нужна для увеличения площади контакта с клеевой массой.
Зачищаем от ошмётков родных креплений, вклеиваем по месту на благословенный двухкомпонентный поксипол и о чудо - держится даже на двух винтах из четырёх и никуда не убегает.
Суть же всех этих приседаний в том, что я получаю крепление прочнее заводского, в то время как вы восстанавливаете процент от заводской прочности. Термоклей - не считается, поверьте.
Я натурально зарегался чтобы ответить, до сего дня мне было полностью ОК в RO режиме. Термоклей - это очень, очень плохой способ ремонта, даже самые жёсткие его сорта не имеют достаточной жёсткости для удержания вплавляемых резьбовых вставок м2-м2.5(а именно такие и применяют в ноутбуках). Впрочем, эпоксидка так же не походит. Есть ровно один хороший способ ремонта таких поломок - зачистка площадки от остатков заводских креплений и создание переходной пластины. Вариантов тут много, самый простой путь - печать на 3D принтере под размеры конкретного ноута из PETG, в которую будут вплавлены родные или новые(в зависимости от ушатанности) вставки. При его отсутствии - можно отрезать от куска АБС подходящей толщины, можно даже нарезать резьбы в латунной пластинке, зависит от фантазии и наличия материалов. И дальше эта пластина по всей площади вклеивается в корпус и в неё уже прикручивается петля. Ну а то что делает ТС в подавляющем большинстве случаев развалится через несколько дней либо требует сильного прослабления затяжки петель.
Давайте попробую объяснить. Для маршрутизации траффика до контейнера нам вполне достаточно динамических маршрутов, которые автоматически будут созданы в момент создания бриджа.
Ну а дальше мы просто создаём WG интерфейсы и пиры для каждого inbound в контейнере
создаём таблицы маршрутизации
Добавляем dummy lookup rule (возможно в актуальных версиях ROS уже не нужно, раньше без этого ipv6 маршрутизация не работала)
Добавляем маскарадинг
Дальше нам нужно повесить на интерфейсы WG какие-нибудь IP адреса, любые, из приватного диапазона(по ним будет идти маршрутизация только до приложения в контейнере). Например так. Опять же, в целом можно без этого, т.к. маршрутизировать мы будет тупо по интерфейсу, но некрасиво.
Наконец добавляем правила, по которым траффик будет заворачиваться в соотв. таблицу маршрутизации
Здесь мы отправляем всё, что будет в соотв. адрес листе в соотв. ему таблицу маршрутизации. Если нужно заворачивать несколько адрес листов в один интерфейс или как-то более гибко рулить всем этим безобразием - можно добавить свои цепочки и делать в них jump. Напр. как-то так:
В этом примере я создал для ipv6 отдельную цепочку prerouting_warp, в которой заворачиваю траффик в таблицу warp и помечаю соединение(можно собрать любое количество нужных правил). При этом проверяю, что коннект не идёт на адреса из списка, подключение до которых ни в коем случае не должно происходить через VPN - в качестве защиты от своих кривых рук. Ну и дальше двумя правилами закидываю в эту цепочку траффик для адресс листов youtube и facebook. Можно так, можно как в предыдущем примере - в зависимости от подхода и решаемой задачи. Как больше нравится и как удобнее.
Ну и вишенкой на торте - создаём маршруты в дикий интернет для наших новых таблиц маршрутизации
Так уже же выложил. Посмотрите переписку чуть выше.
"listen": "172.20.0.2",где 172.20.0.2 - это ip, который мы назначили на veth, к которому присоединён контейнер.
Наверное заработает, я лично не пробовал. Проблем вижу две - во первых, банально сложнее дебажить, т.к. даже шелл внутри контейнера с xray-core не открывается, уж не знаю почему). А во-вторых, dokodemo-door - это в любом случае один интерфейс, соотв. мы можем иметь только один аутбаунд(если не морочиться с маршрутами на уровне самого xray). А вот WG-интерфейсов можно наплодить сколь угодно много. Простота, единообразие, и возможность при минимальном изменении конфига утащить контейнер куда угодно(хоть на другой комп в ЛВС, хоть на удалённую площадку). При этом в приложении к использованию дома я вообще не вижу никакого пенальти по производительности(скорее всего если начать пытаться рулить сотнями одновременных подключений и гигабитными каналами разница вылезет, но у кого есть реально такие задачи - тот точно не будет разворачивать сервис в недодокере на роутере)
Хех. Лично мне больше понравился n1, как-то он для дома выглядит покомпактнее. Хотя если нужен хотсвап дисков - n2 конечно лучше. И если честно - не вижу смысла в спец ОС для NAS, по крайней мере в приложении к домашней хранилке. Обычный дебиан справится не хуже.
В общем случае вам нужны две ключевые пары из публичного и приватного ключа. Генерятся они любым удобным способом, главное чтоб публичная часть ключа соответствовала приватной. По конфигам раскалдываются каким-то таким образом
При этом на самом деле PrivkeyA в конфиге сервера по большому счёту не должен быть нужен, не знаю зачем он его хранит - может это последствия генерации конфига через x-ui. Короче общая логика тут крест-накрест. С каждой стороны(и на сервере и на клиенте) есть конфиг интерфейса WireGuard, где живёт приватный ключ. К нему будут подключаться с публичным ключём те, у кого сконфигурен соотв. пир. И есть конфига пира с публичным ключом, к котому он сам в свою очередь будет подключаться. По сети идёт обмен именно публичными ключами, которые сравниваются с приватными.
Скопирую сюда свой постик на другом ресурсе
На микроте ставим пакет с контейнерами, ребутаемся, включаем контейнеры
/system/device-mode/update container=yesНа железке после этого нужно будет нажать кнопку mode за ограниченное время, удалённо включить контейнеры не выйдет, т.к. потанцевальная дыра в безопасности. Дальше создаём VETH для нашего контейнера, создаём отдельный бридж для контейнеров, навешиваем туда ip адреса(я тут добавляю и ipv6 и ipv4 адрес. На самом деле для схемы с роутингом через WG интерфейс достаточно только v4, но у меня все контейнеры настроены единообразно, так что для общего понимания оставлю)Последние два правила если что рождены в попытке заставить работать схему с byeDPI, для xray это тоже не нужно(при условии что вы отправляете траффик на ipv4 адрес. Если у вас ipv6-only VPS - то нужно, всё нужно) Дальше втыкаем в микрот флешку, из интерфейса форматируем её в EXT4(Обязательно! Иначе при распаковке контейнера порушатся разрешения фалов и ничего не взлетит) Конфигурим местный докер
Аттеншн! Тут ram-high=384.0MiB - это конфиг для AX3 с гигом оперативы. У AС3 её всего 256Мб и с пустым конфигом и установленным пакетом wifi-qcom доступно примерно 145Мб(а с подробным конфигом и под нагрузкой - что-то около 70Мб). У AC2(128Мб) при таких же вводных доступно и того меньше - всего примерно 30Мб. Для AC2 вероятно придётся вообще перейти на легаси Wifi драйвер, иначе с ресурсами ну совсем грустно. Соотв. выставляем параметр с запасом, так чтоб и самому роутеру хватило. При превышении лимита процессы в контейнере начнут нещадно троттлиться, т.е. работать будет, но с дикими тормозами. А вот если память у роутера закончится - скорее всего он тупо крашнется. Не доводим и не включаем старт контейнера при загрузке пока не отладим всё. Скачиваем образ
После этого можно попробовать его стартануть и убедиться что всё найс и ничего не сыпется. Дальше нужно приготовить конфигу xray (файлик config.json) Либо выдёргиваем его из /usr/local/x-ui/bin/config.json (не с сервера разумеется, а с заранее где-то настроенной клиентской инсталляции x-ui. В самом конфиге придётся поправить ip-шники при этом, очевидно), либо пишем ручками. Должно получиться что-то такое
Тут у меня конфига на два входа и к ним два выхода - в WARP и в свой VLESS VPN Подкидываем эту конфигу на флешку по пути /usb1/xray/ Добавляем маунт поинт и привязываем его к контейнеру
После чего можно рестартовать контейнер.
Всё, дальше совсем легко. Любым удобным способом настраиваем Wireguard подключения к нашему контейнеру, добавляем таблицы маршрутизации, настраиваем удобный нам вариант заворота траффика. Мануалов про эту часть в сети полно.
ИМХО xray удобнее цеплять через wireguard. Xray поддерживает его в качестве инбаунда и не нужен второй контейнер. Особенно актуально становится когда в xray заведено несколько профилей VPN, тогда вместо 2+ доп. контейнеров просто добавляем нужное количество входных wireguard интерфейсов и настраиваем маршрутизацию 1к1 по выходным интерфейсам. Да, wireguard туннель, не выходящий за пределы роутера выглядит довольно странным решением, но это работает, потерь по производительности нет а по ресурсам гораздо выгоднее.
Благодарю, не знал
Сам. Это проще чем может показаться. В том же Solidworks есть шикарная встроенная обучалка, которая позволит сносно моделить уже через несколько дней. Тонкости оформления чертежей по ЕСКД оно конечно не раскроет - но оно нам и не надо). И если есть навыки обращения со штангенциркулем - всё обязательно получится.
Проблема именно в том что пробовал, потому и осуждаю. В несостоятельности термоклея вы можете убедиться самостоятельно, вплавив в клеевой стержень резьбовую втулку, вкрутив винт и выдернув оную втулку буквально от руки( в крайнем случае пассатижами если нет удобного длинного винта под рукой, но точно не прикладывая особых усилий). Если у вас ваши методы работают долгие годы - вы вероятно либо очень везучий человек, либо просто не сталкивались со случаями, когда крепление петель идёт недоделанным с завода, либо когда в силу уронения об кафель родным посадкам наступает полный и безотлагательный карачун. Волею случая на этих выходных у жены сломалась петля на её MSI b4 modern(как раз вариант с изначально некомпетентной конструкцией).
Как можно заметить на фото - спасать тупо нечего, крепление уничтожено
https://imgur.com/a/cwgtY6q
Поэтому на помощь приходит её величество переходная пластина(благо модель я сохранил. Правая петля отлетела спустя 5 месяцев после покупки и после ремонта живёт уже третий год)
https://imgur.com/a/shi66qy
Перфорация нужна для увеличения площади контакта с клеевой массой.
Зачищаем от ошмётков родных креплений, вклеиваем по месту на благословенный двухкомпонентный поксипол и о чудо - держится даже на двух винтах из четырёх и никуда не убегает.
https://imgur.com/a/AgNY5at
Да, знаю, не аккуратно, заляпал материнку(которую обломался скидывать), но для себя - не страшно.
Как бонус - заменяем ножку на распечатку, которая тоже треснула в момент подрыва петли.
https://imgur.com/a/aVXGwm2
Суть же всех этих приседаний в том, что я получаю крепление прочнее заводского, в то время как вы восстанавливаете процент от заводской прочности. Термоклей - не считается, поверьте.
Я натурально зарегался чтобы ответить, до сего дня мне было полностью ОК в RO режиме. Термоклей - это очень, очень плохой способ ремонта, даже самые жёсткие его сорта не имеют достаточной жёсткости для удержания вплавляемых резьбовых вставок м2-м2.5(а именно такие и применяют в ноутбуках). Впрочем, эпоксидка так же не походит. Есть ровно один хороший способ ремонта таких поломок - зачистка площадки от остатков заводских креплений и создание переходной пластины. Вариантов тут много, самый простой путь - печать на 3D принтере под размеры конкретного ноута из PETG, в которую будут вплавлены родные или новые(в зависимости от ушатанности) вставки. При его отсутствии - можно отрезать от куска АБС подходящей толщины, можно даже нарезать резьбы в латунной пластинке, зависит от фантазии и наличия материалов. И дальше эта пластина по всей площади вклеивается в корпус и в неё уже прикручивается петля. Ну а то что делает ТС в подавляющем большинстве случаев развалится через несколько дней либо требует сильного прослабления затяжки петель.