Я не знаю, как там у тбанка сейчас реализовано и как будет завтра, но у меня какое-то другое приложение (то ли другого банка, то ли маркетплейса, не помню точно) с месяц показывало эту плашку про впн при подключении просто к домашнему вайфаю. Безо всяких впн и средств обхода. И недавно перестало.
Чего там разработчики за логику понакрутили - остается только догадываться.
Повторюсь. У вас цель - убрать плашку и заставить приложение работать прямо сейчас. Цель, заявленная в статье изначально, несколько иная. И она указанным в статье способом не может быть достигнута.
Из заголовка и посыла статьи сложилось впечатление, что смысл - отправить приложения, которые собирают информацию о наличии тоннеля, в песочницу, чтобы ограничить им такую возможность. Что на текущий момент средствами ОС Android нереализуемо.
Если смысл просто пустить приложение в обход тоннеля, не заботясь о том, известно ли приложению о наличии тоннеля - ну ок, сегодня засовывание приложения в рабочий профиль работает, завтра перестанет 🤷 Это ж все упирается в реализацию детекта в самом приложении, и в общем случае приложению для детектирования тоннеля трафик куда-то слать необязательно.
Что касается сетевого анализатора для телефона - да, есть такой, PCAPdroid называется. Вот только он свой VpnService имплементирует, чтобы собирать трафик без использования root-доступа. Другими словами, с ним у вас банковское приложение не запустится.
Не понимаю, что вы собираетесь проверить с помощью сетевого анализатора. Факт отправки трафика в тоннель и факт получения информации о наличии тоннеля в системе в общем случае тоже не связаны.
ТС добавил в статью ссылку на само исследование (которое делали не в Шкоде). Выше в комментариях я привел цитату из него со скришотом графика АЧХ. Это не похоже на то, что делалось специально, либо же это сделано в какой-то одной модели, и из-за нее поехала статистика общая (график усредненный для всех моделей, коих там всего 6 штук, видимо самых продаваемых). Тон сигналов в самолете стандартизирован, их там всего 2, они лежат в диапазоне около 540Гц (хотя пишут, что у Эирбаса они как раз 800-1000Гц, но источника инфы у меня нет). На этой и соседних частотах никакого падения уровня аттенюации нет, исследовались в целом не программные методы автоматического отключения шумодава, а работа его как такового.
К самой методике исследования лично у меня вопросов нет. У меня до сих пор остались вопросы к результатам. Нет сводной таблицы по всем моделям на всех видах тестирования.
Собственно, про исследование разных шумодавов там не очень подробно (в плане метрик, там уже готовые результаты), хоть и выводы любопытные (эпл давит лучше всех, например). Что касается ачх, то вот:
Figure 3 shows the average third-octave band attenuation spectrum across all headphones for the test signals. It can be seen that for signals which contained broadband noise, there is an increase in attenuation above 2 kHz, corresponding to approximately 6 dB. However, for tones-in-tones signals, this increase is not observed. There is a local dip of approximately 3 dB in the attenuation curve for tone-in-tone and mixed signals in the 800 Hz band. When controlling for differences between headphones it was found that tone-in-tone signals were attenuated by 4.9 dB less than mixed signals and 8.9 dB less than noise-in-noise signals (p< 0.05). There was no statistically significant association between impulsivity of the sounds or the decay time of the sounds.
То есть на частоте 800Гц средний шумодав аж в 2 раза хуже давит тональный сигнал, чем на соседних частотах.
Если честно, это удивляет. Жалко, что в исследовании только методика измерений и средний результат, нет подробных метрик по всем устройствам. Я не исключаю проблем со статистикой.
Если так, то "пусть в известное место себе эту звенелку засунет" - типичные и, что характерно, резонные мысли среднестатичтического пешехода на такой дорожке.
То есть, в целом, эту проблему звонок не решает.
Но как часть мер по безопасности движения - пусть лучше будет, чем нет.
The company intends to make the underlying research findings and insights publicly available.
Это текст из оригинальной статьи. А у вас тут написано:
Skoda не продаёт этот звонок, но результаты исследований находятся в свободном доступе.
Так вот приведите, пожалуйста, ссылку на эти результаты исследований британских ученых, которые Шкода только собирается опубликовать.
Потому как к "слепой зоне" есть вопросы. Инфографика в виде АЧХ с провалом на 780Гц - это, конечно, красивый маркетинговый булщит, но хочется увидеть, что они там реально наизмеряли для разных производителей ANC.
Оу, благодарю за линк. Последний раз поддержку в опенврт я смотрел лет 5 назад, а там как раз указано что поддерживается с версии 22.03.0. У меня устаревшие данные стало быть, как-то умудрились разработчики запилить поддержку BCM53xx. И за линк на flowtable тоже) Интересно.
> Да потому что эта функция нужна в РФ, да в Китае МБ. Нене, я про hairpin NAT, это когда машины из локальной сети могут получить доступ к внутренним сервисам при обращении на внешний адрес роутера (при условии проброшенных портов, естественно). Если включать HW NAT offloading, то просто перестает работать вот это правило: `-A POSTROUTING -s $lan_subnet -d $lan_subnet -o $lan_bridge_if -j MASQUERADE` Сами пакеты проходят через проброшенные порты, но вот после рукопожатия (когда обработка потока уходит в железо) напрочь отключается SNAT и сервер начинает получать от роутера пакеты с адресом клиента в локальной сети, а не с адресом роутера.
Впрочем, возможно дело именно в MASQUERADE, который сам по себе довольно тяжелый и требует получать информацию о текущем адресе на интерфейсе, а таблицам в железке неоткуда угадывать этот адрес. Надо будет попробовать просто SNAT вместе с HW offloading.
Вот в том и вопрос про асусы. Они используют Broadcom, который этот наш опенсорс в гробу видел. Как я понимаю (поправьте если не прав), у этих всяких чипов, заточенных на сети, есть разные типы offloading, не только NAT. И в той же OpenWRT можно на, например, Медиатеках, выбирать, какое именно ускорение включать, а какие вещи оставить ядру.
За костыли спасибо, прикольное. Для сабжа как раз подходит, для hairpin NAT как я понял все равно придется отключать HW разгрузку, там все пакеты с/на внутренний бридж надо маскарадить. Но вообще странно, вродебы такая простая и нужная вещь, а её не реализовали на уровне железа.
Ой, а скажите, в последних моделях асусов HW offloading все еще конфликтует с обработкой сетевых соединений в ядре? А то у меня на RT-AC88U (знаю, знаю, EOL и Мерлин уже два года не выпускал прошивки, как раз собираюсь обновляться по железу) - доходит до банального, либо hairpin NAT, либо NAT offloading и температура на 2-3 градуса ниже (77 вместо 80). Поскольку я все равно уже созрел отказаться от асуса, то вопрос чисто праздный.
Я не знаю, как там у тбанка сейчас реализовано и как будет завтра, но у меня какое-то другое приложение (то ли другого банка, то ли маркетплейса, не помню точно) с месяц показывало эту плашку про впн при подключении просто к домашнему вайфаю. Безо всяких впн и средств обхода. И недавно перестало.
Чего там разработчики за логику понакрутили - остается только догадываться.
Повторюсь. У вас цель - убрать плашку и заставить приложение работать прямо сейчас. Цель, заявленная в статье изначально, несколько иная. И она указанным в статье способом не может быть достигнута.
Из заголовка и посыла статьи сложилось впечатление, что смысл - отправить приложения, которые собирают информацию о наличии тоннеля, в песочницу, чтобы ограничить им такую возможность. Что на текущий момент средствами ОС Android нереализуемо.
Если смысл просто пустить приложение в обход тоннеля, не заботясь о том, известно ли приложению о наличии тоннеля - ну ок, сегодня засовывание приложения в рабочий профиль работает, завтра перестанет 🤷 Это ж все упирается в реализацию детекта в самом приложении, и в общем случае приложению для детектирования тоннеля трафик куда-то слать необязательно.
Что касается сетевого анализатора для телефона - да, есть такой, PCAPdroid называется. Вот только он свой VpnService имплементирует, чтобы собирать трафик без использования root-доступа. Другими словами, с ним у вас банковское приложение не запустится.
Не понимаю, что вы собираетесь проверить с помощью сетевого анализатора. Факт отправки трафика в тоннель и факт получения информации о наличии тоннеля в системе в общем случае тоже не связаны.
"Перестал просить отключить VPN" и "перестал получать информацию о наличии VPN" - утверждения со слабой причинно-следственной связью.
ТС добавил в статью ссылку на само исследование (которое делали не в Шкоде). Выше в комментариях я привел цитату из него со скришотом графика АЧХ.
Это не похоже на то, что делалось специально, либо же это сделано в какой-то одной модели, и из-за нее поехала статистика общая (график усредненный для всех моделей, коих там всего 6 штук, видимо самых продаваемых).
Тон сигналов в самолете стандартизирован, их там всего 2, они лежат в диапазоне около 540Гц (хотя пишут, что у Эирбаса они как раз 800-1000Гц, но источника инфы у меня нет). На этой и соседних частотах никакого падения уровня аттенюации нет, исследовались в целом не программные методы автоматического отключения шумодава, а работа его как такового.
К самой методике исследования лично у меня вопросов нет. У меня до сих пор остались вопросы к результатам. Нет сводной таблицы по всем моделям на всех видах тестирования.
Благодарю!
Собственно, про исследование разных шумодавов там не очень подробно (в плане метрик, там уже готовые результаты), хоть и выводы любопытные (эпл давит лучше всех, например). Что касается ачх, то вот:
То есть на частоте 800Гц средний шумодав аж в 2 раза хуже давит тональный сигнал, чем на соседних частотах.
Если честно, это удивляет. Жалко, что в исследовании только методика измерений и средний результат, нет подробных метрик по всем устройствам. Я не исключаю проблем со статистикой.
Если так, то "пусть в известное место себе эту звенелку засунет" - типичные и, что характерно, резонные мысли среднестатичтического пешехода на такой дорожке.
То есть, в целом, эту проблему звонок не решает.
Но как часть мер по безопасности движения - пусть лучше будет, чем нет.
Это текст из оригинальной статьи. А у вас тут написано:
Так вот приведите, пожалуйста, ссылку на эти результаты исследований британских ученых, которые Шкода только собирается опубликовать.
Потому как к "слепой зоне" есть вопросы. Инфографика в виде АЧХ с провалом на 780Гц - это, конечно, красивый маркетинговый булщит, но хочется увидеть, что они там реально наизмеряли для разных производителей ANC.
А у кого преимущество на такой дорожке?
А еще постучать на "недоступный" STUN этого TG и узнать, с какого выходного адреса он доступен.
Оу. My bad, сложно следить за всей этой конъюнктурой.
Гарем чтоли?
С каких пор Ашманов - противник анонимности?
Его заявления говорят об обратном.
У них еще md5 от пароля в куках хранилось.
Оу, благодарю за линк. Последний раз поддержку в опенврт я смотрел лет 5 назад, а там как раз указано что поддерживается с версии 22.03.0. У меня устаревшие данные стало быть, как-то умудрились разработчики запилить поддержку BCM53xx.
И за линк на flowtable тоже) Интересно.
> Да потому что эта функция нужна в РФ, да в Китае МБ.
Нене, я про hairpin NAT, это когда машины из локальной сети могут получить доступ к внутренним сервисам при обращении на внешний адрес роутера (при условии проброшенных портов, естественно). Если включать HW NAT offloading, то просто перестает работать вот это правило:
`-A POSTROUTING -s $lan_subnet -d $lan_subnet -o $lan_bridge_if -j MASQUERADE`
Сами пакеты проходят через проброшенные порты, но вот после рукопожатия (когда обработка потока уходит в железо) напрочь отключается SNAT и сервер начинает получать от роутера пакеты с адресом клиента в локальной сети, а не с адресом роутера.
Впрочем, возможно дело именно в MASQUERADE, который сам по себе довольно тяжелый и требует получать информацию о текущем адресе на интерфейсе, а таблицам в железке неоткуда угадывать этот адрес. Надо будет попробовать просто SNAT вместе с HW offloading.
Вот в том и вопрос про асусы. Они используют Broadcom, который этот наш опенсорс в гробу видел. Как я понимаю (поправьте если не прав), у этих всяких чипов, заточенных на сети, есть разные типы offloading, не только NAT. И в той же OpenWRT можно на, например, Медиатеках, выбирать, какое именно ускорение включать, а какие вещи оставить ядру.
За костыли спасибо, прикольное. Для сабжа как раз подходит, для hairpin NAT как я понял все равно придется отключать HW разгрузку, там все пакеты с/на внутренний бридж надо маскарадить. Но вообще странно, вродебы такая простая и нужная вещь, а её не реализовали на уровне железа.
Ой, а скажите, в последних моделях асусов HW offloading все еще конфликтует с обработкой сетевых соединений в ядре? А то у меня на RT-AC88U (знаю, знаю, EOL и Мерлин уже два года не выпускал прошивки, как раз собираюсь обновляться по железу) - доходит до банального, либо hairpin NAT, либо NAT offloading и температура на 2-3 градуса ниже (77 вместо 80).
Поскольку я все равно уже созрел отказаться от асуса, то вопрос чисто праздный.
MitM днс-запросов? А DoH, DoT к тому же сервису не режутся часом?
Я понял про правило. Вы мой вопрос проигнорировали. Как это поможет бороться с кази-нелегалами, которые существуют вне правового поля РФ?
Минфин уже предложил.