- Inscrit
- 17 Fév. 2007
- messages
- 678
- Score de réaction
- 1,026
- Points
- 93
Как убедиться, что весь трафик проходит через VPN-туннель?
Если после включения все выглядит нормально, что произойдет, если машина перейдет в спящий режим, а затем возобновит работу? Или если произойдет обрыв сетевого соединения? Или если вы используете Wi-Fi и переключитесь на новую точку доступа и сеть? Или если вы подключаетесь к сети, которая полностью поддерживает IPv6? В данном руководстве показано, как можно провести комплексную проверку VPN на утечки .
Сначала убедитесь, что на компьютере настроен VPN-туннель. В Windows откройте командную строку и выполните команду ipconfig /all. Вы увидите раздел ethernet-адаптера с описанием "WireGuard Tunnel" или "TAP-Windows Adapter V9". IPv4-адрес будет иметь вид 172.x.y.z или 10.x.y.z. В macOS и Linux откройте терминал и выполните команду ifconfig. В macOS адаптер VPN-туннеля имеет имя utun0, а в Linux – wg0 или tun0.
Риски утечек отпечатков браузера и IPv6
Единственный способ узнать, весь ли трафик использует VPN-туннель, – это тестирование. Однако тестирование на предмет утечки VPN сопряжено с определенным риском. Сайты, которые вы используете для тестирования, могут видеть одни и те же отпечатки браузера как с IP-адреса, назначенного провайдером, так и с IP-адреса выхода из VPN. Любой злоумышленник, узнавший отпечатки вашего браузера, может впоследствии идентифицировать вас, даже если вы подключаетесь через VPN и/или Tor, при условии, что вы используете один и тот же браузер. В недавно опубликованном проекте руководства W3C говорится следующее:Отпечатки WebGL и утечки IPv6 гораздо серьезнее. WebGL использует графический процессор через графический драйвер ОС. В конкретной системе все браузеры с включенным WebGL будут иметь один и тот же отпечаток WebGL. При использовании VPN-сервисов рекомендуем блокировать WebGL. Например, в Firefox откройте "about:config" и установите значение "webgl.disabled" на "true". В опциях NoScript на вкладке "Embeddings" установите флажок "Forbid WebGL".
Системы, использующие тот или иной графический драйвер, могут иметь одинаковые отпечатки WebGL на оборудовании с тем или иным GPU. Поэтому переустановка данной ОС или даже переход на другую ОС, использующую тот же графический драйвер, не приведет к изменению отпечатка WebGL. Это хорошо видно на примере виртуальных машин VirtualBox, использующих виртуальный GPU по умолчанию. Например, браузеры на ВМ Debian и Lubuntu имеют одинаковый отпечаток WebGL. А вот браузеры на других ОС (разные дистрибутивы Linux, FreeBSD, Windows и macOS) имеют разные отпечатки WebGL. Однако хост и ВМ используют разные графические процессоры (реальный и виртуальный), поэтому отпечатки WebGL не пересекаются.
Нередко клиенты VPN допускают утечку трафика IPv6. Это очень серьезно, поскольку адреса IPv6, как правило, зависят от конкретного устройства. Поэтому целесообразно отключить IPv6 как в ОС, так и в маршрутизаторе локальной сети. Также целесообразно использовать VPN-клиенты, блокирующие IPv6-трафик, или блокировать IPv6 в брандмауэре. И каждый раз при первом подключении к новой локальной сети или сети Wi-Fi проверяйте возможность подключения по протоколу IPv6.
Кстати, WebGL fingerprinting – очень важная тема при разделении на несколько ВМ. Отпечатки WebGL можно легко заблокировать в браузерах, но также разумно разделять ВМ с разными отпечатками WebGL. Whonix – еще один хороший вариант, поскольку браузер Tor, используемый в этой ОС, был усилен для полного блокирования WebGL fingerprinting.
Проверка
Во время тестирования утечек через VPN можно использовать программу tcpdump для проверки трафика, не использующего VPN-туннель. В Windows вам понадобятся Wireshark и wintee. Просто поместите их копию в папку пользователя. Теперь перечислите номера сетевых интерфейсов:Windows:
Code:
tshark -D
Code:
sudo tcpdump -D
Code:
sudo tcpdump -DWindows:
Code:
tshark -i 1 -n -T text -w "C:\tshark-capture.log" -f "not host a.b.c.d" 2>&1 | wtee tcpdump.log
Code:
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log
Code:
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.logНачните с проверки своего IP-адреса. Безопаснее всего использовать веб-сайт вашего VPN-провайдера. Если они не сообщают IP-адрес, то следующим наиболее безопасным вариантом может стать сайт check.torproject.org. Если вы собираетесь проверять утечки через VPN с помощью других сайтов, рекомендуем использовать браузер Tor, так как он был усовершенствован для блокировки отпечатков WebGL и в остальном сообщает одинаковые отпечатки для всех пользователей. Но пока можно использовать браузер по умолчанию. В любом случае, вы должны увидеть IP-адрес вашего VPN-выхода.
Вам также нужен постоянный источник сетевого трафика. Во втором окне командной строки/терминала:
Windows:
Code:
ping -t a.b.c.d 2>&1 | wtee ping.log
Code:
ping -n a.b.c.d 2>&1 | tee ping.log
Code:
ping -n a.b.c.d 2>&1 | tee ping.logWindows:
Code:
ping -t a.b.c.d | cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!time! !data!)&ping -n 2 localhost>nul" 2>&1 | wtee ping.log
Code:
ping -n a.b.c.d | while read pong; do echo "$(date): $pong"; done 2>&1 | tee ping.log
Code:
ping -D -n a.b.c.d 2>&1 | tee ping.logТеперь отключите машину от сети. В Windows появится сообщение "Request timed out". В macOS и Linux вывод пинга просто прекратится. Затем снова подключите машину к сети. Если все в порядке, ответы на запросы ping должны появиться снова. Обновите сайт проверки IP в браузере. Вы по-прежнему должны видеть адрес выхода из VPN. В окне перехвата трафика по-прежнему не должно быть нелокальных захватов. В Windows может наблюдаться большое количество локального трафика. Для более тщательной проверки можно просмотреть файл tcpdump.log в текстовом редакторе.
Оборванное подключение
Проблемы с оборванным подключением проявляются несколькими основными способами. Предположим, что вы используете OpenVPN. Наиболее очевидным является то, что процесс openvpn (а не только VPN-соединение) может завершиться после потери связи с сетью. Поэтому после восстановления сетевого соединения сайт проверки IP будет сообщать IP-адрес, назначенный провайдером. И вы увидите многочисленные перехваты нелокального трафика. Кстати, Network Manager в Linux склонен к такому режиму работы, поэтому его следует избегать.Менее явный, но более коварный вариант: VPN-клиент может переподключиться после восстановления сетевого соединения, а сайт проверки IP по-прежнему будет сообщать IP-адрес вашего VPN-выхода. Вы можете не заметить прерывания связи. Но вы увидите перехват нелокального трафика, сгенерированного пингами, которые были успешными до восстановления VPN-туннеля. Достаточно одного просочившегося пакета, чтобы узнать назначенный провайдером IP-адрес.
Простой OpenVPN имеет тенденцию к сбоям, которые несколько проще, но все равно опасны. Если перерыв в работе сети длится достаточно долго, чтобы уничтожить VPN-соединение, OpenVPN не может его восстановить. Пока OpenVPN работает, весь трафик направляется через VPN-шлюз, который не работает. Таким образом, сетевое подключение отсутствует. Пинги будут неудачными, и вы не увидите захвата трафика. Маршрутизация по умолчанию не восстанавливается до тех пор, пока не будет убит процесс openvpn. Поэтому можно закрыть приложения, имеющие доступ к важным сетевым ресурсам, убить процесс openvpn, а затем снова подключить VPN. Или можно просто перезагрузиться. Но это утомительные действия, чреватые ошибками.
Аналогичный подход можно использовать и для того, чтобы посмотреть, как ваш VPN-клиент реагирует на другие возмущения. Переход в спящий режим и возобновление работы, смена точек доступа Wi-Fi, использование сети с полным подключением IPv6 – неважно. Проверка журналов tcpdump.log и ping.log должна выявить все утечки.
Если вы обнаружили, что ваш VPN-клиент работает с утечками, один из вариантов – попробовать другого VPN-провайдера и протестировать его клиент. Однако блокировать утечки в Linux легко с помощью vpn-firewall от adrelanos. Рекомендуем использовать его со встроенной службой openvpn, а не с Network Manager. В принципе, он позволяет всем приложениям использовать VPN-туннель, а на физическом интерфейсе блокирует все, кроме соединений с VPN-сервером. Вы можете использовать одну и ту же логику работы брандмауэра в Windows и macOS. В Windows можно просто использовать брандмауэр Windows. В macOS можно использовать IceFloor, который является графическим интерфейсом для брандмауэра PF в OpenBSD.
Другие виды утечек
Даже если весь трафик направляется через VPN, возможно, что DNS-запросы поступают на DNS-сервер, который управляется провайдером или связан с ним. Даже если запросы поступают через VPN-выход, противник, наблюдающий за DNS-сервером и трафиком провайдера, может сопоставить активность. Если VPN-сервер использует один и тот же IP-адрес для входа и выхода, корреляция становится тривиальной. Теперь злоумышленник знает, на какие сайты вы заходите.HTML5 Geolocation API может вызвать потенциально серьезную утечку. Он кэширует и сообщает доступные данные о местоположении. Возможно, вы указали свое местоположение, чтобы получить информацию о местной погоде. Если вы используете Wi-Fi, ваше местоположение может быть триангулировано по доступным точкaм доступа. Если вы используете смартфон, то по идентификатору базовой станции можно приблизительно определить ваше местоположение. И, возможно, у вас включен GPS. Но в этом нет никакой проблемы, пока доступна только информация об IP-адресе.
WebRTC – еще одна опасная функция HTML5. Если она включена в браузере, то сообщает локальный IP-адрес. А если работает IPv6, то он сообщает локальный IPv6-адрес, который, как правило, зависит от конкретного устройства. Поэтому для предотвращения утечек WebRTC целесообразно установить браузерный аддон "WebRTC Control". Также, как отмечалось выше, целесообразно отключить IPv6 в ОС и блокировать весь IPv6-трафик в межсетевом экране.
Посещаемые сайты также можно оценить по количеству промежуточных маршрутизаторов, проинспектировав полученные SYN-пакеты. Время жизни пакета (TTL) для SYN-пакетов по умолчанию варьируется в зависимости от ОС. Строка User-Agent браузера идентифицирует ОС. При этом значение TTL уменьшается каждый раз, когда пакет проходит через маршрутизатор. Разница между ожидаемым и наблюдаемым TTL позволяет оценить количество промежуточных маршрутизаторов.
Если вы собираетесь тестировать утечки с помощью сторонних сайтов, рекомендуем использовать браузер Tor, так как в нем реализована блокировка отпечатков WebGL, а в остальном он сообщает об отпечатках одинаково для всех пользователей. Но вы, очевидно, не захотите использовать Tor при тестировании VPN. Сначала загрузите браузер Tor для своей ОС. Делайте это при подключенном VPN, чтобы провайдер не видел. После извлечения запустите браузер Tor. Вероятно, вы можете принять все настройки по умолчанию. Перейдите к расширенным сетевым настройкам и выберите "Без прокси". Просмотрите about:config и переключите оба параметра "extensions.torlauncher.start_tor" и "network.proxy.socks_remote_dns" на "false". Затем перейдите на сайт check.torproject.org. Вы должны увидеть сообщение о том, что вы не используете Tor, а также IP-адрес вашего VPN-выхода.
Исследовать WebGL и другие фингерпринты с помощью браузера Tor нельзя. Если же вы решили провести тестирование с помощью других браузеров, то следует быть очень осторожным. Как было отмечено выше, все браузеры с поддержкой WebGL на данной системе будут иметь одинаковый отпечаток WebGL. Поэтому следует избегать использования одной и той же системы с подключенной VPN и без нее. Также не следует использовать различные службы VPN, если только вас не беспокоит, что система будет связана с обеими. Кроме того, если используете виртуальные машины, не следует использовать связанные операционные системы с VPN и без него, а также с разными VPN-сервисами.
Итог
Вот основные тесты и результаты, которые вы должны получить:- IPv6 address test: IPv6-адреса не обнаружены
- IP address test: ожидаемые IP-адреса с подключенным VPN и без него
- Geolocation test: браузер не поддерживает API геолокации
- Java test: не найден или отключен
- WebGL test: WebGL заблокирован NoScript
- WebRTC test: не включена
- Panopticlick: браузер защищен от отпечатков
- DNS Leak Test (use extended test): различные DNS-серверы с подключенной VPN и без нее
Русская адаптация Pavlu & Vergil
Original message
Как убедиться, что весь трафик проходит через VPN-туннель?
Если после включения все выглядит нормально, что произойдет, если машина перейдет в спящий режим, а затем возобновит работу? Или если произойдет обрыв сетевого соединения? Или если вы используете Wi-Fi и переключитесь на новую точку доступа и сеть? Или если вы подключаетесь к сети, которая полностью поддерживает IPv6? В данном руководстве показано, как можно провести комплексную проверку VPN на утечки .
Сначала убедитесь, что на компьютере настроен VPN-туннель. В Windows откройте командную строку и выполните команду ipconfig /all. Вы увидите раздел ethernet-адаптера с описанием "WireGuard Tunnel" или "TAP-Windows Adapter V9". IPv4-адрес будет иметь вид 172.x.y.z или 10.x.y.z. В macOS и Linux откройте терминал и выполните команду ifconfig. В macOS адаптер VPN-туннеля имеет имя utun0, а в Linux – wg0 или tun0.
Риски утечек отпечатков браузера и IPv6
Единственный способ узнать, весь ли трафик использует VPN-туннель, – это тестирование. Однако тестирование на предмет утечки VPN сопряжено с определенным риском. Сайты, которые вы используете для тестирования, могут видеть одни и те же отпечатки браузера как с IP-адреса, назначенного провайдером, так и с IP-адреса выхода из VPN. Любой злоумышленник, узнавший отпечатки вашего браузера, может впоследствии идентифицировать вас, даже если вы подключаетесь через VPN и/или Tor, при условии, что вы используете один и тот же браузер. В недавно опубликованном проекте руководства W3C говорится следующее:Отпечатки WebGL и утечки IPv6 гораздо серьезнее. WebGL использует графический процессор через графический драйвер ОС. В конкретной системе все браузеры с включенным WebGL будут иметь один и тот же отпечаток WebGL. При использовании VPN-сервисов рекомендуем блокировать WebGL. Например, в Firefox откройте "about:config" и установите значение "webgl.disabled" на "true". В опциях NoScript на вкладке "Embeddings" установите флажок "Forbid WebGL".
Системы, использующие тот или иной графический драйвер, могут иметь одинаковые отпечатки WebGL на оборудовании с тем или иным GPU. Поэтому переустановка данной ОС или даже переход на другую ОС, использующую тот же графический драйвер, не приведет к изменению отпечатка WebGL. Это хорошо видно на примере виртуальных машин VirtualBox, использующих виртуальный GPU по умолчанию. Например, браузеры на ВМ Debian и Lubuntu имеют одинаковый отпечаток WebGL. А вот браузеры на других ОС (разные дистрибутивы Linux, FreeBSD, Windows и macOS) имеют разные отпечатки WebGL. Однако хост и ВМ используют разные графические процессоры (реальный и виртуальный), поэтому отпечатки WebGL не пересекаются.
Нередко клиенты VPN допускают утечку трафика IPv6. Это очень серьезно, поскольку адреса IPv6, как правило, зависят от конкретного устройства. Поэтому целесообразно отключить IPv6 как в ОС, так и в маршрутизаторе локальной сети. Также целесообразно использовать VPN-клиенты, блокирующие IPv6-трафик, или блокировать IPv6 в брандмауэре. И каждый раз при первом подключении к новой локальной сети или сети Wi-Fi проверяйте возможность подключения по протоколу IPv6.
Кстати, WebGL fingerprinting – очень важная тема при разделении на несколько ВМ. Отпечатки WebGL можно легко заблокировать в браузерах, но также разумно разделять ВМ с разными отпечатками WebGL. Whonix – еще один хороший вариант, поскольку браузер Tor, используемый в этой ОС, был усилен для полного блокирования WebGL fingerprinting.
Проверка
Во время тестирования утечек через VPN можно использовать программу tcpdump для проверки трафика, не использующего VPN-туннель. В Windows вам понадобятся Wireshark и wintee. Просто поместите их копию в папку пользователя. Теперь перечислите номера сетевых интерфейсов:Windows:
Code:
tshark -D
Code:
sudo tcpdump -D
Code:
sudo tcpdump -DWindows:
Code:
tshark -i 1 -n -T text -w "C:\tshark-capture.log" -f "not host a.b.c.d" 2>&1 | wtee tcpdump.log
Code:
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log
Code:
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.logНачните с проверки своего IP-адреса. Безопаснее всего использовать веб-сайт вашего VPN-провайдера. Если они не сообщают IP-адрес, то следующим наиболее безопасным вариантом может стать сайт check.torproject.org. Если вы собираетесь проверять утечки через VPN с помощью других сайтов, рекомендуем использовать браузер Tor, так как он был усовершенствован для блокировки отпечатков WebGL и в остальном сообщает одинаковые отпечатки для всех пользователей. Но пока можно использовать браузер по умолчанию. В любом случае, вы должны увидеть IP-адрес вашего VPN-выхода.
Вам также нужен постоянный источник сетевого трафика. Во втором окне командной строки/терминала:
Windows:
Code:
ping -t a.b.c.d 2>&1 | wtee ping.log
Code:
ping -n a.b.c.d 2>&1 | tee ping.log
Code:
ping -n a.b.c.d 2>&1 | tee ping.logWindows:
Code:
ping -t a.b.c.d | cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!time! !data!)&ping -n 2 localhost>nul" 2>&1 | wtee ping.log
Code:
ping -n a.b.c.d | while read pong; do echo "$(date): $pong"; done 2>&1 | tee ping.log
Code:
ping -D -n a.b.c.d 2>&1 | tee ping.logТеперь отключите машину от сети. В Windows появится сообщение "Request timed out". В macOS и Linux вывод пинга просто прекратится. Затем снова подключите машину к сети. Если все в порядке, ответы на запросы ping должны появиться снова. Обновите сайт проверки IP в браузере. Вы по-прежнему должны видеть адрес выхода из VPN. В окне перехвата трафика по-прежнему не должно быть нелокальных захватов. В Windows может наблюдаться большое количество локального трафика. Для более тщательной проверки можно просмотреть файл tcpdump.log в текстовом редакторе.
Оборванное подключение
Проблемы с оборванным подключением проявляются несколькими основными способами. Предположим, что вы используете OpenVPN. Наиболее очевидным является то, что процесс openvpn (а не только VPN-соединение) может завершиться после потери связи с сетью. Поэтому после восстановления сетевого соединения сайт проверки IP будет сообщать IP-адрес, назначенный провайдером. И вы увидите многочисленные перехваты нелокального трафика. Кстати, Network Manager в Linux склонен к такому режиму работы, поэтому его следует избегать.Менее явный, но более коварный вариант: VPN-клиент может переподключиться после восстановления сетевого соединения, а сайт проверки IP по-прежнему будет сообщать IP-адрес вашего VPN-выхода. Вы можете не заметить прерывания связи. Но вы увидите перехват нелокального трафика, сгенерированного пингами, которые были успешными до восстановления VPN-туннеля. Достаточно одного просочившегося пакета, чтобы узнать назначенный провайдером IP-адрес.
Простой OpenVPN имеет тенденцию к сбоям, которые несколько проще, но все равно опасны. Если перерыв в работе сети длится достаточно долго, чтобы уничтожить VPN-соединение, OpenVPN не может его восстановить. Пока OpenVPN работает, весь трафик направляется через VPN-шлюз, который не работает. Таким образом, сетевое подключение отсутствует. Пинги будут неудачными, и вы не увидите захвата трафика. Маршрутизация по умолчанию не восстанавливается до тех пор, пока не будет убит процесс openvpn. Поэтому можно закрыть приложения, имеющие доступ к важным сетевым ресурсам, убить процесс openvpn, а затем снова подключить VPN. Или можно просто перезагрузиться. Но это утомительные действия, чреватые ошибками.
Аналогичный подход можно использовать и для того, чтобы посмотреть, как ваш VPN-клиент реагирует на другие возмущения. Переход в спящий режим и возобновление работы, смена точек доступа Wi-Fi, использование сети с полным подключением IPv6 – неважно. Проверка журналов tcpdump.log и ping.log должна выявить все утечки.
Если вы обнаружили, что ваш VPN-клиент работает с утечками, один из вариантов – попробовать другого VPN-провайдера и протестировать его клиент. Однако блокировать утечки в Linux легко с помощью vpn-firewall от adrelanos. Рекомендуем использовать его со встроенной службой openvpn, а не с Network Manager. В принципе, он позволяет всем приложениям использовать VPN-туннель, а на физическом интерфейсе блокирует все, кроме соединений с VPN-сервером. Вы можете использовать одну и ту же логику работы брандмауэра в Windows и macOS. В Windows можно просто использовать брандмауэр Windows. В macOS можно использовать IceFloor, который является графическим интерфейсом для брандмауэра PF в OpenBSD.
Другие виды утечек
Даже если весь трафик направляется через VPN, возможно, что DNS-запросы поступают на DNS-сервер, который управляется провайдером или связан с ним. Даже если запросы поступают через VPN-выход, противник, наблюдающий за DNS-сервером и трафиком провайдера, может сопоставить активность. Если VPN-сервер использует один и тот же IP-адрес для входа и выхода, корреляция становится тривиальной. Теперь злоумышленник знает, на какие сайты вы заходите.HTML5 Geolocation API может вызвать потенциально серьезную утечку. Он кэширует и сообщает доступные данные о местоположении. Возможно, вы указали свое местоположение, чтобы получить информацию о местной погоде. Если вы используете Wi-Fi, ваше местоположение может быть триангулировано по доступным точкaм доступа. Если вы используете смартфон, то по идентификатору базовой станции можно приблизительно определить ваше местоположение. И, возможно, у вас включен GPS. Но в этом нет никакой проблемы, пока доступна только информация об IP-адресе.
WebRTC – еще одна опасная функция HTML5. Если она включена в браузере, то сообщает локальный IP-адрес. А если работает IPv6, то он сообщает локальный IPv6-адрес, который, как правило, зависит от конкретного устройства. Поэтому для предотвращения утечек WebRTC целесообразно установить браузерный аддон "WebRTC Control". Также, как отмечалось выше, целесообразно отключить IPv6 в ОС и блокировать весь IPv6-трафик в межсетевом экране.
Посещаемые сайты также можно оценить по количеству промежуточных маршрутизаторов, проинспектировав полученные SYN-пакеты. Время жизни пакета (TTL) для SYN-пакетов по умолчанию варьируется в зависимости от ОС. Строка User-Agent браузера идентифицирует ОС. При этом значение TTL уменьшается каждый раз, когда пакет проходит через маршрутизатор. Разница между ожидаемым и наблюдаемым TTL позволяет оценить количество промежуточных маршрутизаторов.
Если вы собираетесь тестировать утечки с помощью сторонних сайтов, рекомендуем использовать браузер Tor, так как в нем реализована блокировка отпечатков WebGL, а в остальном он сообщает об отпечатках одинаково для всех пользователей. Но вы, очевидно, не захотите использовать Tor при тестировании VPN. Сначала загрузите браузер Tor для своей ОС. Делайте это при подключенном VPN, чтобы провайдер не видел. После извлечения запустите браузер Tor. Вероятно, вы можете принять все настройки по умолчанию. Перейдите к расширенным сетевым настройкам и выберите "Без прокси". Просмотрите about:config и переключите оба параметра "extensions.torlauncher.start_tor" и "network.proxy.socks_remote_dns" на "false". Затем перейдите на сайт check.torproject.org. Вы должны увидеть сообщение о том, что вы не используете Tor, а также IP-адрес вашего VPN-выхода.
Исследовать WebGL и другие фингерпринты с помощью браузера Tor нельзя. Если же вы решили провести тестирование с помощью других браузеров, то следует быть очень осторожным. Как было отмечено выше, все браузеры с поддержкой WebGL на данной системе будут иметь одинаковый отпечаток WebGL. Поэтому следует избегать использования одной и той же системы с подключенной VPN и без нее. Также не следует использовать различные службы VPN, если только вас не беспокоит, что система будет связана с обеими. Кроме того, если используете виртуальные машины, не следует использовать связанные операционные системы с VPN и без него, а также с разными VPN-сервисами.
Итог
Вот основные тесты и результаты, которые вы должны получить:- IPv6 address test: IPv6-адреса не обнаружены
- IP address test: ожидаемые IP-адреса с подключенным VPN и без него
- Geolocation test: браузер не поддерживает API геолокации
- Java test: не найден или отключен
- WebGL test: WebGL заблокирован NoScript
- WebRTC test: не включена
- Panopticlick: браузер защищен от отпечатков
- DNS Leak Test (use extended test): различные DNS-серверы с подключенной VPN и без нее
Русская адаптация Pavlu & Vergil
