В заключительной части статьи о 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, сколько с применением шифрования, в особенности надежного шифрования. Очевидно, что любое государство стремится получше защитить свою информацию и побыстрее заполучить чужую, а потому законодательно регулирует в том числе и криптографию.
В США, очевидном лидере в области IT, ситуация еще интереснее. Новые стандарты шифрования утверждаются NIST (The National Institute of Standards and Technology, Национальный институт стандартов и технологий США), причем в нескольких вариантах: для внутреннего использования понадежнее, а для экспорта — послабее. Хитрость в том, что для получения госзаказов — а это всегда самый лакомый кусок прибыли для любой компании — производители ПО и оборудования обязаны соблюдать эти стандарты.
Стоит ли напоминать, где именно производятся, например, все самые распространенные ОС, равно как и криптографические компоненты в них, включая и модули VPN? Проблема глубже, чем наличие потенциальных бэкдоров. Проблема в том, что сами принимаемые стандарты шифрования, которые фактически становятся общемировыми, могут быть изначально уязвимыми.
Производители сетевого оборудования при экспорте в другие страны по умолчанию отключают в своей продукции ряд алгоритмов шифрования
Собственно говоря, NIST в 2013 году уже обвиняли в том, что семью годами ранее он разрешил АНБ США включить в состав нового стандарта уязвимую версию генератора псевдослучайных чисел — ключевого компонента современной криптографии. В теории это позволило бы значительно упростить расшифровку информации, «защищенной» с применением такого генератора.
Первые подозрения появились несколько месяцев спустя после публикации стандарта. Впрочем, регуляторов и так неоднократно обвиняли в сознательном усложнении описаний публикуемых стандартов и рекомендаций. Да таком, что даже профессионалы при публичном обсуждении черновиков могут далеко не сразу заметить подвох. Еще раз хотелось бы подчеркнуть, что важны не только теоретическая надежность и безопасность любой технологии, но и ее практическая реализация.
Если вы хотите воспользоваться VPN, но не желаете погружаться в технические и юридические тонкости, то эта табличка вам поможет. Главное — аккуратно следовать инструкциям провайдера по настройке соединения и не забывать о простом совете: «Доверяй, но проверяй!».
Главная 
ИТ Сервис - Харьков