Ці можа аператар VPN бачыць, якія сайты вы наведваеце?

Спытайце, што бачыць VPN, і адказ залежыць ад таго, дзе вы стаіце на шляху. На ўзроўні сесіі аператар мае падзеі аўтэнтыфікацыі і колькасць байтаў. На ўзроўні пакетаў — адрасы прызначэння і часы. На ўзроўні DNS — магчыма, самі назвы. Кожны ўзровень адказвае на сваё пытанне, і ніякі адзін перамыкач не пераносіць вас паміж імі.

Пазначце ўзровень, перш чым рабіць заяву

Адно і тое ж злучэнне стварае розныя запісы ў кожнай кропцы, і сцвярджэнне пра прыватнасць мае сэнс толькі тады, калі называе кропку. Чытайце табліцу слупок за слупком: што існуе на гэтым узроўні, што аператар там бачыць і што тыя ж запісы ўсё яшчэ не могуць яму сказаць.

Чытаць адзін узровень як усю карціну — так пачынаюцца і перабольшанні, і фальшывае супакаенне. Правайдэр, які кажа, што не вядзе журнал прагляду, можа быць дакладным пра журнал URL і пры гэтым захоўваць запісы сесій, а здымак пакетаў, які паказвае толькі адрасы, не ператвараецца ў гісторыю прагляду без адваротнага пошуку і здагадак.

Калі ацэньваеце палітыку, знайдзіце сказ, які апісвае кожны ўзровень. Калі палітыка не раздзяляе іх, спытайце, якія запісы існуюць, замест таго каб прымаць агульнае сцвярджэнне пра шыфраванне.

Інвентар сесій: што захоўвае стандартны сервер OpenVPN

Адразу пасля ўсталявання сервер OpenVPN не перахоплівае трафік. Звычайны вынік — інвентар сесій: уліковы запіс, які прайшоў аўтэнтыфікацыю, адрас крыніцы, з якога ён прыйшоў, часы пачатку і завяршэння, выдадзены адрас тунэля і агульная колькасць байтаў у кожным кірунку. Гэта інвентар сесій, а не спіс пунктаў прызначэння.

Параметры журнала могуць дадаць дэталі. Вышэйшы ўзровень шматслоўнасці піша больш пра рукапацісканне, а файл стану можа пералічваць падключаных кліентаў, але нішто з гэтага не робіць сервер празрыстым проксі. Каб атрымаць URL, трэба завяршыць TLS або запускаць явны проксі, і абодва змяняюць дамоўленасць аб даверы, а не ўключаюць схаваную функцыю.

Вось чаму дакладная версія заявы пра адсутнасць журнала прагляду вужэйшая, чым гучыць. Сервер не ведае старонкі, але ведае, што сесія існавала і прыкладна колькі даных праз яе прайшло. Ці захоўваецца гэты запіс сесіі і як доўга — асобнае пытанне палітыкі.

Унутраныя і знешнія пакеты — розныя доказы

Здымак пакетаў — гэта спосаб убачыць, што насамрэч ідзе праз тунэль. На серверы назвіце інтэрфейс тунэля і запішыце ў файл, які можна прааналізаваць лакальна:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Гэты файл змяшчае расшыфраваны ўнутраны трафік: адрас тунэля кліента як крыніцу, адрас і порт прызначэння, памеры пакетаў і часы. У ім няма шляху HTTP або цела адказу, калі толькі TLS не завяршаўся дзесьці, і гэта адчувальныя даныя, захоўванне якіх — рашэнне палітыкі, а не зручнасць адладкі.

Здымак на фізічным інтэрфейсе паказвае іншае. Там вы бачыце знешнія пакеты, накіраваныя да канчатковай кропкі VPN, з зашыфраванай нагрузкай унутры. Паяўленне старонніх адрасоў у гэтым файле — нармальная з'ява, калі існуе віртуальны адаптар, бо прылада тунэля нясе ўнутраныя патоку, а шыфраваны транспарт — знешнія.

Спытайце, на якое пытанне мае адказаць здымак. Выкарыстанне тунэля праграмай бачнае на віртуальным адаптары; дасяжнасць тунэля да канчатковай кропкі — на фізічным. Выкарыстанне любога з гэтых файлаў як поўнай карціны дае высновы, якіх даныя не падтрымліваюць.

DNS — там, дзе назвы становяцца бачнымі

DNS застаецца практычным выключэннем. Рэзалвер бачыць назвы, якія яго просяць развязаць, таму той, хто ім кіруе, даведваецца, якія сайты кліент шукае, нават калі наступныя злучэнні шыфраваныя. Здымак тунэля паказвае адрасы; рэзалвер паказвае назвы.

Праверце, які адрас рэзалвер выкарыстаў, каб дасягнуць знешняга сэрвісу. Адказ — гэта адрас выхаду рэзалвера, і параўнанне яго з выхадам VPN скажа вам, ці прайшоў запыт праз тунэль:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Калі гэты адрас супадае з лакальным злучэннем, а не з выхадам тунэля, пошук абыйшоў VPN, і назва была бачная на лакальным шляху. Паўтарыце праверку пасля абнаўлення кліента, бо новая версія можа змяніць рэзалвер, які ўсталёўвае профіль.

Шыфраваны DNS пераносіць бачнасць, а не выдаляе яе. Сетка больш не бачыць запыт, але рэзалвер бачыць, і пытанне даверу проста пераходзіць у іншыя рукі. Назва сервера TLS у рукапацісканні — яшчэ адзін частковы сігнал: часта застаецца нават тады, калі нагрузка непразрыстая, таму адрасы прызначэння — не адзіныя метаданыя, якія можа назіраць перанакіравальны сервер.

Тры тыпы запісаў і хто іх можа чытаць

Улік сесій, запісы па назвах і доказы ўцечкі — гэта тры розныя прадукты з трыма рознымі абавязацельствамі. Журналы сесій танныя і малаадчувальныя, і яны адказваюць, хто падключыўся і калі. Запісы па назвах патрабуюць рэзалвера з журналам або явнага проксі і ствараюць абавязацельства раскрыцця перад закранутымі людзьмі. Доказ уцечкі — гэта кліенцкі тэст, які параўноўвае тое, што выдае рэзалвер, з выхадам тунэля.

Запішыце, які з гэтых трох вы вядзеце, хто можа яго чытаць і як доўга ён застаецца. Сцвярджэнні, што сэрвіс не вядзе журналаў, апісваюць адзін узровень і застаюцца праўдзівымі толькі ў гэтых межах. Адзін і той жа правайдэр можа быць дакладным пра сесіі і памыляцца пра DNS.

Трымайце тэст узнаўляльным: той жа запыт да рэзалвера, той жа інтэрфейс здымка і тое ж параўнанне. Заява пра прыватнасць, якую нельга праверыць на названым узроўні, — гэта лозунг, а не аперацыйны факт.