Если соединение в России внезапно стало медленным и нестабильным, первая мысль обычно вполне бытовая: оператор, перегруженный сервер, Wi-Fi, неудачный маршрут — стандартный набор объяснений.
Последние несколько дней мы разбирали похожий набор симптомов по логам Tunnel Cat и пользовательским жалобам. Картина оказалась полезной не только применительно к нашей сети: за внешне похожим поведением скрывались две принципиально разные проблемы, которые на уровне пользователя легко спутать. Первая — резкое замедление международного трафика, вторая — подмена TLS-сертификата и MITM. Если у вас сейчас наблюдается что-то похожее, эти два сценария стоит различать отдельно: симптомы пересекаются, а смысл происходящего — совершенно разный.
Международный трафик не заблокирован. Он просто иногда перестаёт ехать
Первый характерный паттерн: соединение успешно устанавливается и какое-то время работает нормально — TCP жив, TLS установлен, данные идут. А потом скорость резко падает, иногда через несколько секунд, иногда через несколько минут, в отдельных случаях почти до нуля.
Это важное отличие от обычной блокировки адреса или подсети, где всё довольно бинарно: маршрут либо работает, либо нет. Здесь соединение формально продолжает существовать, но его свойства меняются уже после начала передачи данных — и именно на этот признак стоит смотреть в логах и замерах: нормальный старт с последующей выраженной деградацией.
По нашим наблюдениям, российские операторы сейчас кратно замедляют международный трафик — не отрезают его полностью, а именно замедляют, причём неравномерно во времени. На одном из маршрутов это видно особенно хорошо: подключение к датацентрам Яндекса через туннели из США временами становится невозможным вообще, а там, где раньше проходило порядка 80 Мбит/с, сейчас — примерно 8–12.
Для диагностики это неприятный режим. Если адрес просто перестал отвечать, неисправный маршрут можно быстро найти и исключить. Если же первые пакеты проходят нормально, а затем канал превращается в нечто среднее между модемом 1998 года и тишиной, причина уже не так очевидна.
Почему именно так происходит, мы пока не знаем — есть две гипотезы, и обе остаются именно гипотезами. Первая — DPI: оборудование сначала пропускает соединение в обычном режиме, затем по каким-то признакам считает поток нестандартным и начинает анализировать его внимательнее, а более тяжёлая обработка приводит к падению пропускной способности. Такой механизм хорошо объяснял бы характерную задержку между началом соединения и его деградацией.
Вторая гипотеза менее техническая: постепенно расширяется допустимый уровень ограничений международного трафика — условно, «а если внешний канал прикрутить ещё немного, всё продолжит работать? А если ещё?». По сетевым измерениям отличить политическое или регуляторное решение от технической особенности DPI невозможно, поэтому утверждать здесь что-то определённое было бы неправильно. Но сам наблюдаемый эффект от этого не меняется: международный трафик заметно деградировал, и деградация может начинаться уже после полностью успешного установления соединения.
Это первый паттерн, который имеет смысл отделять от остальных.
Если проблема заметно чаще возникает на Windows — стоит посмотреть сертификаты
Второй паттерн внешне может выглядеть почти так же: медленная работа, нестабильное соединение, периодические разрывы. Но есть дополнительный признак — на Windows это проявляется заметно чаще.
Tunnel Cat работает на нескольких платформах, и именно сравнение между ними позволило заметить странность: на части Windows-машин нестабильность выражена гораздо сильнее, тогда как тот же тип соединения на других платформах мог работать нормально. Не у всех пользователей, не постоянно — но достаточно регулярно, чтобы перестать считать это случайностью.
В такой ситуации имеет смысл смотреть уже не только на скорость, RTT и потери пакетов, но и на то, какой именно сертификат получает клиент при установлении TLS-соединения. В нашем случае на десятках пользовательских Windows-машин в логах обнаружилась подмена TLS-сертификата: клиент устанавливает защищённое соединение, ожидает сертификат удалённой стороны — а получает посторонний.
Дальше механизм классический: между клиентом и сервером появляется третья сторона, которая принимает TLS-соединение клиента, расшифровывает его, устанавливает отдельное соединение дальше и передаёт трафик уже от своего имени. Это MITM — man in the middle, и его важно не смешивать с первым случаем: это не «DPI слишком долго разбирает поток», не потеря пакетов и не обычное ограничение полосы, а перехват защищённого соединения с подменой сертификата.
Почему MITM может выглядеть как обычная плохая сеть
Если клиент корректно проверяет сертификат, разумная реакция на такую ситуацию проста — отказаться от соединения. Именно так ведёт себя Tunnel Cat: если сертификат не тот, который должен быть, он разрывает соединение.
Но для пользователя происходящее при этом выглядит совсем не как атака на TLS. Он видит, что страницы открываются через раз, что соединение долго устанавливается, что туннель периодически отваливается и что всё почему-то особенно плохо работает на Windows — то есть почти тот же набор симптомов, который можно получить от плохого маршрута или ограничения пропускной способности. Поэтому, если диагностировать проблему только по пользовательскому описанию, два совершенно разных сценария легко смешать.
Практически полезное различие такое: если соединение сначала нормально передаёт данные, а потом последовательно деградирует, стоит смотреть на динамику пропускной способности и поведения маршрута. Если же появляются разрывы TLS, особенно с выраженной платформенной зависимостью, стоит отдельно проверить сертификаты и цепочку доверия. Внешний симптом «интернет плохо работает» сам по себе почти ничего не говорит о причине.
Замедление и MITM — принципиально разные вещи
В первом случае речь об ограничении пропускной способности. Причиной может быть DPI, другие изменения внутри операторской сети или более широкий режим ограничения международного трафика — данных для точного ответа пока недостаточно.
Во втором случае интерпретация намного однозначнее: если клиент получает не сертификат той стороны, с которой собирался установить TLS-соединение, а сертификат посредника, который расшифровывает данные и передаёт их дальше, — это MITM, целенаправленное вмешательство в приватность передаваемых данных. Пока такой сценарий зафиксирован только на Windows.
Из этих наблюдений нельзя сделать вывод о том, кто именно осуществляет перехват и как устроен весь механизм. У нас есть несколько десятков машин, конкретная подмена сертификатов в логах и соответствующая симптоматика — этого достаточно, чтобы считать явление реальным, но недостаточно, чтобы уверенно объяснять его происхождение. Здесь лучше остановиться на том, что показывают данные, а не достраивать картину по воображению.
Что с этим делать прямо сейчас
Сегодня выходят обновления Tunnel Cat, устраняющие часть наблюдаемых симптомов. Но с точки зрения диагностики интереснее другое: обновление клиента не отменяет самих сетевых явлений. Международный трафик от этого не перестаёт деградировать, а MITM не становится менее существенным только потому, что конкретный клиент умеет заметить неправильный сертификат и разорвать соединение.
Поэтому, если вы сейчас разбираете похожую проблему — туннель, VPN, собственный TLS-протокол, сервис с нестабильной связностью из России, — не стоит сводить всё к одной категории «что-то режет интернет». По крайней мере два разных паттерна уже имеет смысл проверять отдельно: нормальное начало передачи с последующим резким падением пропускной способности, и неожиданный сертификат там, где его быть не должно. На экране пользователя оба случая могут выглядеть почти одинаково. В логах — нет.
И, пожалуй, это сейчас самое неприятное изменение: есть большая разница между интернетом, где отдельный ресурс просто недоступен, и интернетом, где соединение сначала работает, затем незаметно деградирует, а на части машин между клиентом и сервером внезапно оказывается кто-то третий. С первым мы давно научились жить. Со вторым, похоже, только начинаем разбираться.
ссылка на оригинал статьи https://habr.com/ru/articles/1075534/