Что оператор видит внутри сотового туннеля VPN

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

Шаг 1: нарисуйте обе связи

С одной стороны — телефон и мобильная сеть: регистрация, радионесущие и любая защита, предусмотренная стандартом доступа. С другой стороны — клиент VPN и конкретный удалённый шлюз со своей аутентификацией и своими ключами.

Разные конечные точки, разный ключевой материал, разные режимы отказа. Рисуйте их как две линии, а не одну.

Шаг 2: отметьте, где заканчивается каждая

Для туннеля IPsec в туннельном режиме клиент помещает внутренний пакет в новый внешний IP-пакет, и сеть пересылает этот внешний заголовок. Спецификация ESP описывает эту инкапсуляцию напрямую: полезная нагрузка защищена, а внешняя адресация — это то, что видит путь.

phone -- cellular access protection -- radio network
phone -- ESP outer packet ------> office gateway -- inner traffic

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

Шаг 3: перечислите, что оператор всё ещё может делать

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

Наблюдение и нарушение — реальные возможности. Это не та же возможность, что чтение внутренней полезной нагрузки.

Шаг 4: сохраняйте допущения честными

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

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

Шаг 5: проследите данные за шлюз

Защита VPN заканчивается на настроенной конечной точке. Дальнейшие действия трафика защищены только тем, что работает на этом уровне, поэтому правильно проверенный сеанс HTTPS по-прежнему важен после туннеля. Открытый текст, отправленный дальше со шлюза, требует собственной оценки.

Именно об этом люди забывают, когда описывают туннель как охватывающий весь путь.

Шаг 6: определите потоки, которые действительно защищены

Проверьте клиентскую политику на исключённые приложения, раздельное туннелирование и семейства адресов. Исключённое приложение, необработанное семейство адресов или отключённый сеанс могут использовать совсем другой путь, а значок состояния не скажет, какой поток куда пошёл.

Запишите запись как четыре факта: сеть доступа, аутентифицированная конечная точка VPN, конечная точка приложения и фактически охваченный трафик. Эта запись остаётся верной, даже когда значки лгут.