согласен, очень круто было бы иметь возможность передавать программе переменные в виде конфиг файла, например yaml, а уж обвязку для запуска множественных туннелей мы напишем сами :)
у таких тестов часто проблема с тем, как юзер заворачивает трафик в туннель, вы уверены что это скорость была именно через контейнер? тем более для ас2 это баснословные результаты))
скорее всего вы завернули по домену только фронт спидтеста, а сервера для измерения скорости нет, поэтому всё идет напрямую через вашего провайдера
предлагаю для начала посмотреть на график скорости интерфейса контейнера и сравнить это с показателями с вашего скриншота
зачем писать ишью если у вас наверняка и клиенты на других платформах не могут подключиться с теми же параметрами к тем же серверам?
потому что вы об этом не упомянули.
постоянно всем пишу прежде чем что-то засунуть в контейнер какую-либо конфигурацию, чтобы в случае чего не думать на него, сначала добейтесь рабочей конфигурации на других более простых устройствах пк/мобила/etc
А может быть таки дело в mtu внутри контейнера... как его изменить? как минимум до 170 мегабит должно дожимать как эти же контейнеры с полной реализацией awg в user-space, а mihomo так максимум 200 мегабит прожимает на ax3)
Потестил на warp'е, через контейнер на ARM64 hAP AX3 жмет чуть более сотки, напрямую через микрот нативный wg жмет в полный канал 300 мегабит По-ходу нужна оптимизация)
хочется именно для таких случаев пробивания чтобы программа понимала с каким портом src приходит запрос от микротика и чтобы с ним же шел запрос к серверу, для реализации следующего алгоритма: если пир потух, вырубаем его, ставим рандомный порт у интерфейса wg (=0), в пире адрес сервера заменяем на адрес контейнера, врубаем пир - контейнер пробивается (ВАЖНО) с этим же src портом на реальный сервер,
скрипт проверки чекает что пир ожил и меняет в нем адрес сервера напрямую с передергиванием пира, это даст максимальную производительность wg с пробивными плюшками)
- либо просто дать возможность передать src порт как необязательный параметр в переменную
и что еще важно нужно кикнуть существующий коннект от контейнера, т.е. либо сервис в контейнере сам перестает соединяться с сервером когда нет клиента в лице микротика, потому что он займет тот же порт, либо принудительно скриптом автоматизации останавливать контейнер, удалять коннект если он будет и уже потом запускать встроенный пир напрямую на сервер.
Примерно то же самое я хотел сделать на своем контейнере, но пока лень меня побеждает)) делаю это все вручную раз в неделю
В коде на Go не шарю, возможно не нужно вмешиваться в изменение трафика при дефолтных полях awg как у меня, по сути поле только одно, которое используется при первоначальном коннекте к серверу, но может быть это все таки тяжесть маршрутизации udp трафика через контейнер...
Круто! Благо современные модели Mikrotik'ов позволяют вытворять почти что угодно в контейнерах) и даже проброс usb устройств в сам контейнер возможен, но никаких драйверов в ядро системы ROS само собой установить нельзя
Берем обычный Mikrotik Cloud Hosted Router и получаем безопасность, веб/winbox панель для удобного мониторинга, удобное управление по API и никакого оверизобретения костылей в красноглазом стиле DevOps.
пусть тогда и магазин встает на сторону покупателя и жалуется куда там нужно, что их тоже надули поставщики, а то как всегда лапки кверху и никто не виноват.
Как-то читал где-то статейку, что чел восстановил с подобного "нового" диска куски видеозаписей с камер наблюдения в каких-то китайских магазинах) так что да, мысль хорошая, могли толком ничего сильно не затирать, большие объемы - большая трата времени, хотя и так сильно заморочились.
Что мешает браузеру локально заботиться о безопасности? нет, надо же всю инфу сначала слить неведомо куда и кто её там будет защищать, тоже не известно... мало сливов из компаний в нашей стране, так и вы еще обогащаете эти сливы, а ответственности за это перед пользователями ни-ка-кой. удобненько устроились, однако.
это правильно я понимаю, что малварю достаточно будет заблочить ваш сесурити апи эндпоинт и вся ваша "защита" коту под хвост?
Ага, ждите в следующей редакции "мы перепишем вашу квартиру на себя"...ну так вы же eula не читали. Это же не значит что туда можно написать все что угодно?!
Качайте сразу с докерхаба, там же и скрипт автонастройки есть, микротик сам выберет автоматически нужную архитектуру https://hub.docker.com/r/wiktorbgu/amneziawg-proxy-mikrotik
у вас armv5 контейнеры на этом микротике https://help.mikrotik.com/docs/spaces/ROS/pages/84901929/Container#Container-Requirements
согласен, очень круто было бы иметь возможность передавать программе переменные в виде конфиг файла, например yaml, а уж обвязку для запуска множественных туннелей мы напишем сами :)
у таких тестов часто проблема с тем, как юзер заворачивает трафик в туннель, вы уверены что это скорость была именно через контейнер? тем более для ас2 это баснословные результаты))
скорее всего вы завернули по домену только фронт спидтеста, а сервера для измерения скорости нет, поэтому всё идет напрямую через вашего провайдера
предлагаю для начала посмотреть на график скорости интерфейса контейнера и сравнить это с показателями с вашего скриншота
зачем писать ишью если у вас наверняка и клиенты на других платформах не могут подключиться с теми же параметрами к тем же серверам?
потому что вы об этом не упомянули.
постоянно всем пишу прежде чем что-то засунуть в контейнер какую-либо конфигурацию, чтобы в случае чего не думать на него, сначала добейтесь рабочей конфигурации на других более простых устройствах пк/мобила/etc
Один минус у Socksify как и у Socks сервера в микротике это only tcp.
А может быть таки дело в mtu внутри контейнера... как его изменить? как минимум до 170 мегабит должно дожимать как эти же контейнеры с полной реализацией awg в user-space, а mihomo так максимум 200 мегабит прожимает на ax3)
Потестил на warp'е, через контейнер на ARM64 hAP AX3 жмет чуть более сотки, напрямую через микрот нативный wg жмет в полный канал 300 мегабит
По-ходу нужна оптимизация)
Использую простой конфиг с пробивным "мусором"
Какие есть предложения:
хочется именно для таких случаев пробивания чтобы программа понимала с каким портом src приходит запрос от микротика и чтобы с ним же шел запрос к серверу, для реализации следующего алгоритма:
если пир потух, вырубаем его, ставим рандомный порт у интерфейса wg (=0), в пире адрес сервера заменяем на адрес контейнера, врубаем пир - контейнер пробивается (ВАЖНО) с этим же src портом на реальный сервер,
скрипт проверки чекает что пир ожил и меняет в нем адрес сервера напрямую с передергиванием пира, это даст максимальную производительность wg с пробивными плюшками)
- либо просто дать возможность передать src порт как необязательный параметр в переменную
и что еще важно нужно кикнуть существующий коннект от контейнера, т.е. либо сервис в контейнере сам перестает соединяться с сервером когда нет клиента в лице микротика, потому что он займет тот же порт, либо принудительно скриптом автоматизации останавливать контейнер, удалять коннект если он будет и уже потом запускать встроенный пир напрямую на сервер.
Примерно то же самое я хотел сделать на своем контейнере, но пока лень меня побеждает)) делаю это все вручную раз в неделю
В коде на Go не шарю, возможно не нужно вмешиваться в изменение трафика при дефолтных полях awg как у меня, по сути поле только одно, которое используется при первоначальном коннекте к серверу, но может быть это все таки тяжесть маршрутизации udp трафика через контейнер...
Изучал бы я 10 лет назад Go вместо питона, я бы сделал то же самое)
Плюсики в карму)) так и появляются инновации на энтузиастах!
Круто! Благо современные модели Mikrotik'ов позволяют вытворять почти что угодно в контейнерах) и даже проброс usb устройств в сам контейнер возможен, но никаких драйверов в ядро системы ROS само собой установить нельзя
Берем обычный Mikrotik Cloud Hosted Router и получаем безопасность, веб/winbox панель для удобного мониторинга, удобное управление по API и никакого оверизобретения костылей в красноглазом стиле DevOps.
Прям на лицо ощущается дефицит высококвалифицированных низкооплачиваемых кадров
А я слишком хорошо автоматизировал, поэтому я теперь безработный! :)
Тайна века, просто пробрасываем порт на своем домашнем интернете на нужный сервер и пользуемся.
Некоторые и с одной не очень-то и справляются, кругом кофе да печеньки...
Испытал такие же чувства)
Очередная статья в стиле "Начал за здравие, а кончил за упокой"
пусть тогда и магазин встает на сторону покупателя и жалуется куда там нужно, что их тоже надули поставщики, а то как всегда лапки кверху и никто не виноват.
Как-то читал где-то статейку, что чел восстановил с подобного "нового" диска куски видеозаписей с камер наблюдения в каких-то китайских магазинах) так что да, мысль хорошая, могли толком ничего сильно не затирать, большие объемы - большая трата времени, хотя и так сильно заморочились.
Что мешает браузеру локально заботиться о безопасности? нет, надо же всю инфу сначала слить неведомо куда и кто её там будет защищать, тоже не известно... мало сливов из компаний в нашей стране, так и вы еще обогащаете эти сливы, а ответственности за это перед пользователями ни-ка-кой. удобненько устроились, однако.
это правильно я понимаю, что малварю достаточно будет заблочить ваш сесурити апи эндпоинт и вся ваша "защита" коту под хвост?
Ага, ждите в следующей редакции "мы перепишем вашу квартиру на себя"...ну так вы же eula не читали. Это же не значит что туда можно написать все что угодно?!