О тревожном настоящем и неясном будущем

Данная статья включает в себя краткое техническое введение в принципы работы технологий сетевого обмена данными, описание принципа работы предлагаемых нами сегодня прокси, обзор краткосрочных и долгосрочных перспектив внедрения различных изменений, которые могут непосредственно повлиять на нашу и вашу работу. После прочтения данной статьи у вас, надеюсь, сложится комплексное понимание того, как будет принципиально трансформироваться наш и ваш бизнес в интернете в ближайшие годы. Я постараюсь доступно объяснить, на каких аспектах необходимо начинать заострять внимание уже сейчас, а для каких сложностей решение имелось задолго до их обнаружения на горизонте.

Техническое введение

Для того, чтобы объективно рассуждать об интернете и его будущем, нужно понимать, как он принципиально работает: что делает браузер, чем управляет операционная система, чем занят роутер и как запрос упаковывается в кабель или радиосигнал.

Вообще говоря, любое взаимодействие в природе основано на протоколах передачи данных. У людей, например, принято сначала здороваться, а потом уже садиться пить пиво. Или, например, постучаться, а потом уже дергать дверную ручку. Очевидно, что вбитая в голову упорядоченность и автоматическое следование основополагающим алгоритмам позволяют не задумываться об элементарных вещах, расценивая их по умолчанию разумеющимися. Однако, если обратить пристальное внимание на все эти бытовые мелочи, выяснится, что строгий порядок в небольших делах позволяет поддерживать строгий порядок в более важных и заметных вещах. Например, если нарушить алгоритм и не поздороваться с товарищем, дальнейший диалог может не задаться и какая-то перспективная идея моментально ускользнет. Либо, к примеру, если невежливо завалиться к кому-то без стука, вряд ли это произведет положительное впечатление и будет позитивно влиять на следующие за этим обсуждения.

Логично предположить, что раз интернет придумали люди, то и логика его функционирования со временем стала напоминать человеческую – выделились уровни взаимодействия (маленькие и большие дела), протоколы обмена данными оформились на всех логических и физических уровнях (сначала поздороваться, потом пить пиво). Вот теперь можно перейти к описанию.

Разделение на уровни в сетевых технологиях описывается моделью OSI, включающей в себя логические и физический уровни. Физический уровень – это то, что можно потрогать руками: кабель, роутер, специалист интернет-провайдера. Логический уровень – Фиксики, живущие в компьютере, питающиеся интернет-пакетами и рисующие на мониторе кнопку “бабло”.

Еще два понятия: инкапсуляция – это сверху вниз, от седьмого уровня к первому, от приложения к кабелю. Декапсуляция – это наоборот, от первого к седьмому, от электрического сигнала к главной странице lteboost.com.

Приведу доступное описание всех уровней модели OSI по порядку декапсуляции:

1. Физический уровень. Здесь разруливается все, что связано с физическими соединениями: Ethernet-кабель, Bluetooth-соединение. ИК-порт, в конце концов. Тут я не могу выделить конкретно какие-то протоколы, просто берется в одном месте и физически отправляется в другое место, где принимается (успешно или нет) и передается на уровень выше. В качестве данных на этом уровне выступает бит – 1 или 0, присутствие или отсутствие электрического сигнала.
2. Канальный уровень. На этом уровне биты собираются в кадры, которые проверяются на ошибки и передаются согласно таблице маршрутизации, составленной из MAC-адресов. MAC-адрес – это уникальный (не всегда, но в одной сети обязательно) идентификатор железа: сетевой карты, Wi-Fi свистка, Bluetooth-мыши. Из широко известных протоколов здесь можно выделить ARP – определение IP-адреса по MAC-адресу в локальной сети. Этим уровнем управляет драйвер сетевой карты роутера или компьютера.
3. Сетевой уровень. На этом уровне происходит передача кадра от устройства с одним IP-адресом устройству с другим IP-адресом. При этом кадр может быть передан как напрямую в локальной сети, так и через роутер, если речь про интернет. Самый известный протокол на этом уровне – IP: адреса, подсети, маски, вот это все. Этим и следующими уровнями управляет операционная система.
4. Транспортный уровень. Кадры здесь собираются в пакеты и передаются на уровень выше. Здесь же фигурируют протоколы TCP и UDP, например.
5. Сеансовый уровень. Здесь производится управление сессиями, в рамках которых туда-обратно передаются пакеты. Открывается сокет, с которым взаимодействуют уровни выше. Из протоколов здесь есть вам знакомый SOCKS.
6. Представительский уровень. На этом уровне пакеты собираются в данные, понятные приложениям. Зашифрованное расшифровывается, закодированное декодируется.
7. Прикладной уровень. HTTP, POP3, IMAP, BitTorrent, SSH, Telnet, FTP, DNS – все тут. То, под что непосредственно пишутся всякие скрипты на питоне и прочие поделки на сишарпе. То, чем занят браузер. То, через что воруются игры. То, через что заливаются файлы на сервер.

Пройдемся по уровням на примере:

Вы открываете браузер, открываете сайт lteboost.com. Первым делом браузер отправляет DNS-запрос, чтобы выяснить IP адрес сервера. DNS-сервер расположен по IP-адресу 1.1.1.1. DNS-запрос, созданный на уровне 7, делится на пакеты на уровне 6, отправляется в рамках установленного на уровне 5 сеанса, делится на кадры на уровне 4, каждый из которых направляется через домашний роутер на IP-адрес DNS-сервера (1.1.1.1) на уровне 3, на 2 уровне сетевая карта делит кадры на биты и в виде электрических сигналов на 1 уровне отправляет на ближайший свитч или роутер. На следующем устройстве (роутер или свитч) эти сигналы принимаются и разбираются до нужного уровня, чтобы определить дальнейший путь. На конечном устройстве (роутер сервера по адресу 1.1.1.1) эти сигналы принимаются и разбираются на уровне 1, собираются в кадры на уровне 2, отправляются на следующее устройство на уровне 3, собираются в пакеты на уровне 4, которые в рамках установленной на уровне 5 сессии передаются в нужный сокет, далее на 6 уровне пакеты собираются в данные и согласно протоколу 7 уровня получаются в приложении. Туда-сюда разок сгоняли и получили IP-адрес сайта lteboost.com. Теперь браузер соберет GET-запрос через протокол HTTP, точно так же отправит ниже, где он будет раздроблен до электрических сигналов, чтобы ответ был через доли секунды собран назад и выведен на экран. Это нужно прочитать и понять очень вдумчиво, потому что осознание уровней матрешки позволяет однозначно судить о различных используемых в работе технологиях (прокси разных типов).

Как сейчас работают разные прокси

Рассмотрим принцип работы двух наиболее популярных протоколов прокси – HTTP(S) и SOCKS5.

Принцип работы HTTP(S) прокси

HTTP(S) прокси функционируют на 7 (прикладном) уровне модели OSI. Вместо того, чтобы отправить запрос напрямую к серверу, программа (браузер) отправляет запрос к прокси-серверу, который, в свою очередь, от своего имени отправляет его серверу. Ответ возвращается сначала к прокси, потом к клиенту (браузеру). Прокси работает на прикладном уровне, а это значит, что прокси получает полный HTTP запрос, включающий метод, адрес, заголовки и тело. В случае HTTPS часть из списка может быть зашифрована, но сути это не поменяет, потому что используемые в нашей работе прокси трафик не расшифровывают, достаточно понять, куда трафик слать дальше.

Принцип работы SOCKS5 прокси

SOCKS5 прокси функционируют на 5 (сеансовом) уровне модели OSI. Прокси получает пакеты и устанавливает TCP-соединение на 4 уровне модели OSI от имени клиента. Этот тип прокси не имеет понятия об адресе и заголовках, а функционирует исключительно на уровне пакетов. Данные прокси имеет смысл использовать, когда речь идет о протоколах помимо HTTP(S) (не в браузере). С некоторыми условиями этот протокол может поддерживать UDP, но помимо поддержки сервером еще и клиент обязан отдельно отправить информацию о UDP-роутинге через TCP напрямую к серверу прокси. В этом на данный момент нет большого смысла, публичный (платный) софт и наши прокси это не поддерживают, реализация UDP через прокси потребует не столько усилий с нашей стороны, сколько поддержки этого разработчиками соответствующего ПО.

Что и когда может поменяться и что с этим всем делать

Так бывает в жизни, что завтра не совсем похоже на сегодня, но какие-то предварительные оценки заранее дать можно. Конкретно речь пойдет о протоколе QUIC, который предлагается к использованию в стандарте HTTP/3 (на текущий момент 99% сервисов используют HTTP/2 и ниже).

Кто такой этот ваш QUIC

QUIC – стандарт 4 (транспортного) уровня модели OSI, который, предположительно, будет основой для стандарта HTTP/3. Протокол QUIC основан на протоколе UDP, но доделан Google для того, чтобы гарантировать корректное функционирование клиент-серверной связи, избавиться от пожилых ограничений TCP и вообще ускорить работу интернета.

Для обычных пользователей это, несомненно, положительная история, но внимательный читатель из аудитории нашего канала уже начал подозревать, что и SOCKS5, и HTTP(S) прокси не только работают через транспорт TCP, но и находятся уровнями гораздо выше транспортного. Несомненно, старое с новым обычно не стыкуется, но обо всем по порядку.

Как быть

Сразу можно дать ответ на простой вопрос – сразу все не сломается. Предыдущие стандарты в обязательном порядке будут поддерживаться еще очень долгое время, и достаточно будет отключить новый протокол для клиента (браузера, софта), чтобы все продолжило функционировать корректно.

Если подумать над гораздо более глубоким вопросом про курицу и яйцо, можно прийти к выводу, что сначала все-таки было яйцо, но не факт, что куриное. Если экстраполировать эту логику относительно семейства протоколов HTTP и того, что с ними происходило позднее, становится очевидно, что сначала будет продукт (HTTP/3), а потом все остальное (прокси, софт). Достаточно подождать, и, я уверен, мы увидим побочные продукты имеющихся прокси-решений, которые так или иначе будут работать с HTTP/3. Тем более, что решение уже существует, но об этом ниже.

Необходимо уточнить, что не существует принципиальных ограничений для реализации UDP-прокси. Более того, стабильные реализации таких прокси существуют уже более десяти лет, но для нашей работы не представляют большого интереса, поэтому одновременно не предлагаются клиентам и не развиваются так ощутимо, как их TCP аналоги.

Напомню, что QUIC предлагается в качестве транспорта, а это 4 уровень OSI. Путем нехитрых математических операций выясняем, что существует еще три уровня, на которых мы можем что-то сделать с трафиком, чтобы достичь изначальной цели – сокрытия исходного IP адреса. Это делается очень просто – например, с помощью WireGuard, функционирующего на сетевом (3) уровне модели OSI. WireGuard не заботится о том, что там внутри, у него есть кадр и получатель – дальше дело техники.

Если бы сегодня все мажорные сервисы одновременно начали использовать исключительно QUIC, мы бы перешли на WireGuard и предоставили инструкции, как работать дальше.

Когда

Взглянем на даты: QUIC был впервые представлен в 2012 году (9 лет назад), попал в стандарт HTTP/3 в 2018 году (4 года назад), стал поддерживаться браузерами в 2019-2020 годах (3 года назад), был включен по умолчанию в браузерах в 2020-2021 годах (2 года назад) и был финально предложен для стандарта в июне 2022 года.

Протоколу потребовалось девять лет, чтобы пройти путь от рождения до предположения, что он пойдет в стандарт. Можно легко предположить, сколько времени потребуется для того, чтобы ощутимая часть сервисов перешла на него полностью. Согласно Wikipedia, только 26% сайтов из топ-10 миллионов поддерживают HTTP/3, а в Safari этот протокол до сих пор выключен. Речь идет не про недели и месяцы, а про годы.

Помимо обновления транспорта множество сложностей для быстрого перехода вызывает безопасность. Крупные компании заботятся об уязвимостях в используемом ПО, а принципиальное коренное изменение серверного ПО требует множества доработок, которые требуется спроектировать, реализовать, протестировать на безопасность и опубликовать, чтобы сервис продолжал функционировать корректно для всех пользователей одновременно.

О чем действительно нужно беспокоиться

В данной статье рассматривается именно вопрос сокрытия исходного IP адреса от сервера с целью снятия различных ограничений. Я считаю, что это наименьшая из обозримых проблем, потенциально встающих поперек нашего бизнеса. Несомненно, наш сервис специализируется исключительно на прокси-серверах, но влияющие на всю индустрию проблемы доставляют сложности и нам, поэтому необходимо их обсудить.

Hardware attestation

Не является секретом, что помимо IP адреса существует еще не менее десятка идентификаторов, которые, очевидно, собираются и анализируются сервисами. Например, Google уже несколько лет активно использует SafetyNet для активной аттестации устройств на Android на предмет целостности системы. Любое вмешательство в устройство вызовет отказ SafetyNet и соответствующего сервиса, который его показания использует.

На этом моменте некоторые читатели попытаются возразить, мол, однажды на своем телефоне по инструкции с помощью модуля для Magisk починили SafetyNet, чтобы на кастомной прошивке работал Google Pay. И да, и нет. Эти модули делают несколько вещей, но ключевым фактором здесь является то, что аттестация становится программной. Модуль “обманывает” SafetyNet, чтобы последний думал, что телефон не поддерживает аттестацию через железо, и пока что это работает. Близится тот день, когда все устройства с программной аттестацией будут признаны небезопасными, и это перестанет работать.

Усложнение технологий

Увеличение эффективности и мощности мобильных чипов является неотрицательным трендом последних лет. В связи с этим растет потенциал использования более сложных инструментов внутри приложений, которые призваны защитить внутреннюю логику от внешнего вмешательства. Условно, если сегодня для написания софта требуется хороший специалист, завтра потребуется команда уникальных. Уникальных специалистов не так много, разработка станет дороже, а то и вовсе перестанет быть целесообразной.

Вывод

На текущий момент относительно прокси действительно серьезных поводов для беспокойства мы не видим. Да, есть некоторые перспективы, с которыми придется разбираться, но всему свое время. На текущий момент уже есть как минимум одно очевидное решение, которое мы можем в перспективе предложить нашим клиентам, столкнувшимся с неизбежными изменениями. Со своей стороны мы готовы приложить нужные усилия для того, чтобы продолжать предоставлять качественные услуги нашим клиентам, но дополнительно усилия потребуются еще и от тех, кто разрабатывает ПО. Об активных действиях говорить пока рано, но мы провели свой анализ и максимально доступно ознакомили вас с его выводами.