Что нужно знать, прежде чем перейти на VPN

Рассказываем о всевозможных особенностях и подводных камнях VPN с юридической и технической точек зрения

Что нужно знать, прежде чем перейти на VPN

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

Что нужно знать, прежде чем перейти на VPN

Околотехнические аспекты

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

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

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

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

Microsoft в Windows 7 и более свежих системах ввела функцию VPN Reconnect. Для всех остальных платформ придется использовать особые настройки маршрутизации или программки-«предохранители» {kill switch}. Они отслеживают состояние VPN-подключения и в случае его обрыва в первую очередь блокируют весь трафик и/или завершают работу выбранных приложений, а потом пытаются восстановить VPN-соединение. Аналогичная функциональность есть в некоторых коммерческих VPN-клиентах.

Вторая, менее очевидная и пока что нечасто встречающаяся «протечка» VPN касается IPv6. Несмотря на то что в реальных сетях связи IPv6 встречается редко, почти во всех современных ОС поддержка этого протокола включена по умолчанию, тогда как VPN работает чаще всего с IPv4.

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

Да, можно загнать весь трафик внутрь VPN, но это требует и поддержки на стороне сервера, и настроек на стороне клиента. После опубликованного летом 2015 года исследования VPN-провайдеры зашевелились и стали искать решения для своих клиентов.

В том же исследовании говорится и о третьем нюансе — «DNS-протечках». По-хорошему при подключении к VPN все DNS-запросы должны тоже уходить внутрь виртуальной сети и там обрабатываться собственными DNS-серверами. Ну или как минимум при установке подключения должны прописываться более-менее доверенные сервера вроде Google Public DNS или OpenDNS. Альтернативный вариант — использовать совместно с VPN сервисы вроде DNSCrypt. Последний также шифрует и подтверждает подлинность DNS-запросов и ответов, что может быть полезно и в обычной жизни.

На практике это делается не всегда, и нередко используются DNS-сервера, выданные публичной сетью. Очевидно, что ответ от них может быть некорректным, и вместо реального адреса запрашиваемого домена пользователь получит поддельный — отличный шанс для фарминга! Побочный эффект от «DNS-протечки» — удар по анонимности, то есть возможность выяснить адреса DNS-серверов пользователя и таким образом получить информацию о его интернет-провайдере и примерном местоположении.

С Windows ситуация хуже, чем можно было бы предположить. Если Windows 7 поочередно опрашивала известные ей DNS-сервера и терпеливо ждала ответа, то Windows 8/8.1 для ускорения параллельно опрашивает все известные DNS-сервера на всех известных сетевых подключениях. Если в течение секунды не ответил основной сервер, то тут же используется ответ другого. А DNS-запрос через VPN вполне может опоздать. Хорошая новость состоит в том, что отключить эту излишнюю «заботу» можно. Плохая — для этого придется вручную поработать с реестром.

В Windows 10 все еще печальнее. В этой операционной системе DNS-запросы тоже рассылаются сразу «во все стороны», а используется тот, от которого первым приходит ответ. И хороших новостей в этом случае не будет: отключить данную полезнейшую функцию средствами ОС уже нельзя.

Другая потенциально опасная брешь кроется в WebRTC. Эта технология изначально придумана для прямой связи между двумя сетевыми узлами прямо в браузере и используется в основном для аудио- и видеосвязи. «Протечка» заключается в том, что модуль WebRTC обращается сразу ко всем сетевым подключениям и может использовать любое из них.

Точно так же неподконтрольными могут оказаться другие модули типа Java Plugin или Adobe Flash, да и вообще любое ПО. Впрочем, это больше вредит анонимности, а мы, напомним, все еще рассматриваем случай защиты пользователя при подключении к публичным сетям.

Юридические аспекты

Использование VPN-соединений является сигналом для соответствующих служб: «А с чего это вдруг кто-то решил что-то спрятать?»

Самый первый и очевидный аспект — это различия в законодательствах стран. Ведь VPN-клиент может находиться в одной стране, а VPN-сервер в другой, пусть и условно дружественной. Или же трафик может просто проходить транзитом через третьи страны. И даже если вы ничего не нарушаете, это не помешает теоретически сохранить «слепок» всех переданных и полученных данных на любой из сторон для дальнейшего изучения.

В целом не очень приятно, когда защищенный трафик расшифровывается даже несколько лет спустя. Более того, даже само использование VPN-соединений уже является сигналом для соответствующих служб: «А с чего это вдруг кто-то решил что-то спрятать?»

Бывает и так, что формально использование VPN не запрещено, однако технически доступ к таким технологиям все равно ограничивается. В общем, смотрите пример из предыдущей части повествования или любые материалы о PRISM.

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

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

В США, очевидном лидере в области IT, ситуация еще интереснее. Новые стандарты шифрования утверждаются NIST (The National Institute of Standards and Technology, Национальный институт стандартов и технологий США), причем в нескольких вариантах: для внутреннего использования понадежнее, а для экспорта — послабее. Хитрость в том, что для получения госзаказов — а это всегда самый лакомый кусок прибыли для любой компании — производители ПО и оборудования обязаны соблюдать эти стандарты.

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

Производители сетевого оборудования при экспорте в другие страны по умолчанию отключают в своей продукции ряд алгоритмов шифрования

Собственно говоря, NIST в 2013 году уже обвиняли в том, что семью годами ранее он разрешил АНБ США включить в состав нового стандарта уязвимую версию генератора псевдослучайных чисел — ключевого компонента современной криптографии. В теории это позволило бы значительно упростить расшифровку информации, «защищенной» с применением такого генератора.

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

Советы
Подпишитесь на нашу еженедельную рассылку
  • For all other countries