Все решения VPN, которые ранее мы обсуждали, имеют одну общую черту: они основаны на открытом исходном коде, что должно облегчить проверку их на наличие уязвимостей. В действительности, однако, есть много других проблем, кроме кода.
Наиболее очевидной проблемой является периодические отключение VPN соединения, что в результате, совершенно неожиданно, направляет трафик через сеть общего пользования. Такая ситуация может иметь место, например, в том случае, когда пользователь подключен к общедоступной сети Wi-Fi или другой доступной мобильной сети. В худшем случае, пользователь может быть уведомлен об этом, а VPN-подключение не будет автоматически восстановлено.
В системах Windows 7 и выше, компания Microsoft представила функцию VPN Reconnect. Если вы используете альтернативную платформу, вы должны использовать опцию настройки подключения или функцию «kill switch», которая отслеживает состояние VPN-подключения. Если связь будет разорвана, весь сетевой трафик блокируется, работа всех запущенных приложений завершается, и система попытается повторно подключиться к сети VPN. Некоторые коммерческие клиенты VPN предлагают аналогичную функциональность.
Вторая проблема, связанная с VPN, которая является менее очевидной и возникает реже, применение протокола IPv6. Так как он редко используется, все основные операционные системы имеют его по умолчанию включенным, в то время как VPN чаще всего используют IPv4.
Что же в таком случае может случиться? Так вот, если IPv6 поддерживается в сети общего пользования, а клиент соединится с ресурсом, работающим с той же версии протокола, сетевой трафик может быть по умолчанию направлен через общественную сеть, работающую на протоколе IPv6. Самым простым средством защиты было бы полное отключение поддержки IPv6 на уровне операционной системы.
Конечно, можно направлять весь трафик в VPN, но это требует поддержки этой функции со стороны сервера и определенных настроек на стороне клиента. Исследования, проведенные в 2015 году, дали пищу для размышлений поставщикам решений VPN, которые начали искать подходящие решения для своих клиентов.
Исследование также показало существование третьей проблемы: утечки DNS. В идеальном случае, когда пользователь подключается к VPN, ни один запрос DNS не должно выйти за пределы VPN – все запросы должны быть обработаны соответствующими DNS-серверами. Если это не так, следует позаботиться о добавлении в настройки сети других надежных DNS, например, Google Public DNS или OpenDNS. Вы можете также использовать решения VPN поставляемое в комплекте с такими услугами как DNSCrypt. Последний вариант используется для шифрования и проверки подлинности запросов/ответов DNS-серверов, что может быть полезно во многих других ситуациях.
В реальной жизни эти рекомендации выполняются довольно редко, а люди используют DNS-серверы общедоступной сети. Конечно, ответы, полученные с этих серверов, могут быть неправильными и даже ложными, что является отличной возможностью для киберпреступников, использующих дыры в серверах DNS для перенаправления трафика на совершенно другой сервер.
Другой ущерб, вызванный утечкой DNS – это нарушение частной жизни: человек из вне может обнаружить адреса DNS-серверов и, следовательно, узнать имя поставщика услуг интернета и более-менее точное местоположение пользователя.
Лица, использующие системы Windows в большой опасности. В то время как Windows 7 будет пытаться проверить все DNS-серверы один за другим, и будет ждать ответ, Windows 8/8.1 быстрее справится с этой ситуацией путём одновременной отправки запросов всем известным DNS-серверам на всех известных соединениях. Если желаемый сервер не возвращает ответ в течение одной минуты, будет использоваться ответ другого сервера. Однако, в случае VPN ожидание ответа от сервера DNS может занять гораздо больше времени. К счастью, вы можете вручную отключить эту опцию. К сожалению, это тоже плохая новость – так как потребует проведения кропотливых манипуляций в реестре системы.
В Windows 10 всё еще хуже. Эта операционная система также отправляет DNS-запросы всем и использует ответ, который был возвращен раньше. К сожалению, в данном случае нет никаких хороших новостей: эту «чрезвычайно полезную опцию» нельзя отключить даже на уровне системы.
Существует также несколько уязвимостей в WebRTC. Эта технология, доступная в браузере, первоначально была создана для обеспечения прямого соединения между двумя узлами сети и в настоящее время используется, в основном, для трансляции аудио и видео. Утечка здесь очень вероятна, потому что WebRTC ссылается на все доступные сетевые подключения одновременно, и использует то, которое ответит первым.
Такое же отсутствие контроля можно найти в других плагинах, таких как Java или Adobe Flash, если не во всех программах. Это представляет собой серьезную угрозу для конфиденциальности пользователей.
