😴 😴 😴 За последние дни мы психологически устали и работали почти без перерыва (теперь нам нужен отдых) — поэтому наше сообщение будет коротким.

Первое — мы выпустили Zapret 21 — наше самое крупное обновление за всю историю!

Второе — доступно здесь

https://github.com/telegramdesktop/tdesktop/pull/30513

Telegram desktop не был обновлён (по крайней мере на гитхабе)

Сегодня поковыряемся и выпустим пояснения.

В крайнем случае случае можно будет собрать свой билд со всеми фиксами 👀

🚨🚨 Мы продолжаем собирать отзывы о Zapret 21 и выпускаем 21.0.0.4 где добавлены новые пресеты для ALL TCP & UDP как раз для тех у кого "ничего не работает" и "хочу тыкнуть и работает".

UPD: Исправлено в 21.0.0.5

‼️ РБК получил копию методички минцифры по выявлению VPN-сервисов. В целом всё плохо, но есть хорошие новости для пользователей iOS. Собрали главное:

▪️ Методичку рассылали в продолжение совещаний, которое минцифры проводило с крупнейшими российскими интернет-компаниями по размеру аудитории — всего более 20 площадок. На них глава министерства Максут Шадаев поручил компаниям к 15 апреля ограничить доступ к интернет-сервисам пользователям с включённым VPN;
▪️ В методичке отмечается, что поскольку больше половины пользовательских устройств — это мобильные устройства под управлением операционных систем Android и iOS, и 80% приложений, с помощью которых можно проводить выявление средств обхода, установлено именно на этих устройствах, то внедрение механизмов для поиска VPN следует начинать именно с гаджетов на указанных операционных системах.

▪️ Компании должны будут проверять, включен ли VPN на устройствах пользователей, в три этапа:
▪️ определять IP-адрес устройства и сравнивать его теми IP-адресами, которые считаются российскими, а также со списком заблокированных Роскомнадзором IP-адресов;
▪️ проверять использование средств обхода блокировок на устройстве с собственного приложения (если оно установлено на том же устройстве);
▪️ проверять использование VPN на устройствах под управлением операционных систем, отличных от Android и iOS (Windows, MacOS и др.);

Например, если страна и регион пользователя по IP-адресу не совпадёт с российскими, или совпадёт с ранее заблокированными РКН, или, если будет выявлено, что у пользователь часто менялись страны, это будет признаком для блокировки. Но такой признак всегда будет требовать подтверждения через второй или третий этап проверки, пишет РБК.

▪️ При этом в материалах указано, что осуществить второй этап проверки на устройствах iOS от Apple сложно, поскольку «на iOS доступ к системным параметрам существенно ограничен». Причина в том, что у этой операционной системы политика конфиденциальности и безопасности предполагает, что все сторонние приложения изолированы и не могут собирать или изменять информацию, хранящуюся в других приложениях. Для Android ситуация проще: там работают системы ConnectivityManager и NetworkCapabilities, которые позволяют любому приложению запросить параметры активной сети и сообщить, что текущий интернет-трафик идет через VPN.

▪️ Помимо сложностей с iOS в материалах министерства описаны еще ряд ситуаций, когда выявление VPN затруднено или невозможно:

▪️ VPN на роутерах. Если средство обхода блокировок настроено на пользовательском маршрутизаторе, на самом устройстве отсутствуют локальные артефакты и выявить VPN невозможно;
▪️ VPN в виртуальных машинах. Если средство обхода блокировок развернуто внутри виртуальной машины или контейнера на устройстве пользователя, выявление также затруднено;
▪️ Прокси-серверы. Если они расположены у обычных интернет-провайдеров и имеют IP домашнего провайдера, то их невозможно определить по базам;
▪️ Split tunneling. Режим, при котором через VPN направляется трафик только выбранных приложений, а остальной идет напрямую. В этом случае проверка по одной активной сети недостаточна;
▪️ CDN (сети доставки контента — специальные верверы, которые расположены ближе к клиенту и ускоряют загрузку контента) и глобальные сервисы могут искажать местоположение устройства без использования VPN;
▪️ Новые VPN-сервисы. Они появляются быстрее, чем обновляются репутационные базы IP-адресов.

▪️ В методичке также рекомендуется не проводить на устройстве пользователя непрерывный мониторинг состояния VPN: «Это будет негативно влиять на расход трафика и потребление заряда батареи».

Мы провели своё расследование. Айфонам приготовиться!

Формулировка «на iPhone VPN не отслеживается» технически неверна. Правильнее говорить так:

на iPhone обычному приложению сложнее получить жёсткий и официальный признак VPN, чем на Android, но сделать достаточно надёжный вывод о наличии VPN во многих случаях всё равно можно.

CFNetworkCopySystemProxySettings() сам по себе не «читает TUN-пакеты» и не «сканирует VPN как отдельное приложение».

Он делает более приземлённую вещь: возвращает системные сетевые настройки, в том числе настройки прокси. А уже по устройству сетевого стека, по списку интерфейсов и по косвенным признакам в этом словаре приложение может понять, что трафик идёт через туннель, то есть через виртуальный сетевой интерфейс VPN.

Это не прямое «я увидел VPN-процесс», а сетевой вывод по конфигурации ядра и маршрутизации.

Когда приложение само является VPN-клиентом или имеет соответствующие права через NetworkExtension, оно может официально управлять VPN-конфигурацией и знать её состояние через NEVPNManager и NEVPNConnection. Но такой доступ не у всех приложений, а у тех, кому он реально выдан и кто работает с VPN-функциями легально.

Обычное приложение может не видеть «название VPN-приложения», но способно посмотреть на состояние сетевых интерфейсов и понять, что поверх обычного Wi‑Fi или мобильной сети появился туннельный интерфейс.

Есть ещё более низкоуровневый путь. На Apple-платформах доступна стандартная функция getifaddrs(), которая возвращает список сетевых интерфейсов процесса. Это уже не CFNetwork, а более базовый уровень BSD-сетей.
➖➖➖➖➖➖➖➖
На Android ситуация грубее и прямолинейнее. У Google это почти официально признанный сценарий: приложение может через ConnectivityManager получить NetworkCapabilities и проверить TRANSPORT_VPN.

То есть на Android система прямо даёт разработчику более удобный признак: текущая активная сеть относится к типу VPN.

Для обычного приложения на Android сам факт VPN действительно виден довольно легко, а вот IP самого VPN-сервера, то есть удалённого шлюза, обычно не выдаётся напрямую обычному приложению через публичные API.

У Android есть очень удобный для разработчика механизм: NetworkCapabilities.hasTransport(TRANSPORT_VPN). Это означает буквально следующее: система умеет сообщить приложению, что данная сеть использует транспорт VPN. Кроме этого, у Android есть LinkProperties. Это объект, который хранит свойства сетевого канала.

Если VPN поднят как системная сеть, приложение часто может увидеть саму сеть типа VPN. Но если конкретное приложение выведено в обход VPN, то его собственный трафик может идти по обычной сети, а не по туннелю.

Если VPN использует не чистый TUN-туннель, а ещё и задаёт HTTP-прокси через VpnService.Builder.setHttpProxy(), тогда приложение может через LinkProperties.getHttpProxy() получить ProxyInfo. А в ProxyInfo уже может быть виден конкретный хост и порт прокси.

Короче говоря split tunneling даёт понять что:
- понять, что VPN на устройстве вообще поднят
- понять, идёт ли его трафик через VPN или напрямую
- увидеть внешний IP, с которого пришёл запрос на сервер
- увидеть DNS или прокси-настройки в некоторых сценариях

😨 😱 😱 😨

Звучит надёжно 😎😎😎