Особенности блокирования операторами трафика tethering-режима Android
Дэниэл Покок (Daniel Pocock), мэйнтейнер некоторых пакетов в Debian и Fedora, опубликовал интересный разбор организации работы tethering-режима в новых выпусках платформы Android. Tethering позволяет использовать телефон в качестве точки доступа для организации выхода в Сеть внешних устройств через установленное на смартфоне интернет-соединение. При установке очередного обновления прошивки Android, Дэниэл столкнулся с проблемами при работе устройств через tethering-соединение, при том, что при открытии тех же ресурсов со смартфона проблем со скоростью и доступом не наблюдалось.
Казалось бы, что не должно быть разницы при работе со смартфона или со внешнего устройства через этот же смартфон, так как интернет-соединение одно и для оператора трафик локального запроса и запроса через режим tethering неотличим. На самом деле, оказалось, что операторам предоставлена возможность различать трафик со смартфона и через режим tethering, в чём Дэниэл усматривает существенное ущемление приватности и ограничение прав пользователя. Некоторые операторы явно понижают качество сервиса для tethering-трафика, предполагая, что 3G-соединение смартфона недопустимо использовать для раздачи интернета на другие устройства. Компания Vodafone Italy, клиентом которой является Дэниэл, вообще заблокировала возможность использования tethering. Проблема также проявляется в прошивках CyanogenMod.
Технически разделение локального и tethering-трафика осуществляется через создание для tethering-соединения другого сетевого интерфейса с отдельным IP-адресом. При этом такое поведение рассматривается разработчиками как штатная функциональность, а не ошибка. Дэниэл не согласен с такой трактовкой и считает, что операторы связи заинтересованы в утечке данных о типе соединения и добились внесения данной возможности для получения своей экономической выгоды путем навязывания продаж USB-модемов как отдельного сервиса.
shell@android:/ # ip route 0.0.0.0/1 dev tun0 scope link default via 100.66.150.89 dev rmnet_usb0 83.224.66.138 via 100.87.31.214 dev rmnet_usb1 83.224.70.94 via 100.87.31.214 dev rmnet_usb1 100.66.150.88/30 dev rmnet_usb0 proto kernel scope link src 100.66.150.90 100.66.150.89 dev rmnet_usb0 scope link 100.87.31.212/30 dev rmnet_usb1 proto kernel scope link src 100.87.31.213 100.87.31.214 dev rmnet_usb1 scope link 128.0.0.0/1 dev tun0 scope link 192.168.42.0/24 dev rndis0 proto kernel scope link src 192.168.42.129
shell@android:/ # ip rule show 0: from all lookup local 32765: from 192.168.42.0/24 lookup 60 32766: from all lookup main 32767: from all lookup default
shell@android:/ # ip route show table 60 default via 100.87.51.57 dev rmnet_usb1 100.87.51.57 dev rmnet_usb1 192.168.42.0/24 dev rndis0 scope link
Для устройств, на которых открыт доступ root, в качестве решения проблемы Дэниэл предлагает осуществить привязку tethering-соединения к основному сетевому интерфейсу, через который организован выход в интернет локальных приложений смартфона:
# Находим правило, перенаправляющее трафик из tethering-подсети (в нашем случае 32765): shell@android:/ # ip rule show 0: from all lookup local 32765: from 192.168.42.0/24 lookup 60 32766: from all lookup main 32767: from all lookup default
# Удаляем перенаправление shell@android:/ # ip rule del pref 32765 # Меняем правила NAT-трансляции, переделав их на основной интерфейс rmnet_usb0 # вместо по умолчанию используемого rmnet_usb1: shell@android:/ # iptables -t nat -I natctrl_nat_POSTROUTING -s 192.168.0.0/16 -o rmnet_usb0 -j MASQUERADE shell@android:/ # iptables -I natctrl_FORWARD -i rmmnet_usb0 -j RETURN
Дополнение: можно воспользоваться более простым способом, поправив при помощи sqlite содержимое базы /data/data/com.android.providers.settings/databases/settings.db, заменив значение поля tether_dun_required на 0.
