Какво криптира тунелът и какво оставя четимо

Тунелът ви работи, един раздел показва зелен катинар, а обикновена HTTP страница в друг раздел все още предупреждава, че връзката не е сигурна. Тази комбинация обърква хората, защото двете защити покриват различни разстояния. VPN защитава трафика между собствените си крайни точки, а след изхода трафикът отново става обикновен. HTTPS защитава една връзка чак до уебсайта. Подреждането на тези два факта обяснява повечето въпроси за това какво всъщност скрива VPN.

Какво всъщност покрива тунелът

Между клиента и VPN партньора наблюдателят вижда криптирани байтове, а не четима заявка. Това покрива отсечката, която тунелът пресича, а тя обикновено е частта, която не контролирате. То не се простира до връзката между VPN изхода и уебсайта, защото тунелът е приключил при изхода. Байтовете отново стават четими от момента, в който тунелът прекрати. Нищо в това не е грешна конфигурация.

Изходът е машина, която декриптира и препраща, а точно за това служи VPN. Всичко, което препраща, е видимо за нея във вида, в който го е получила, затова обикновената HTTP заявка остава открит текст от изхода нататък.

Четете това като свойство, а не като дефект. Криптирането е ограничено до път, а пътят свършва там, където започва услугата.

Ключове, nonce и цялост с прости думи

Текущият трафик се защитава със симетрична криптография и двете страни извеждат или получават ключовия материал по време на ръкостискането. Удостовереното криптиране, описано в общи линии от RFC 5116, дава поверителност и цялост в една конструкция. Получателят отхвърля променени байтове, вместо просто да не успее да ги прочете, и точно това хората забравят, когато мислят, че криптирането означава разбъркване.

Ключовете идват от този обмен, а не от паролата, въведена при вход. Паролата удостоверява самоличност, а след това протоколът установява сесийния материал. Ефимерният обмен на ключове дава пряка поверителност, затова записан сеанс остава нечетим, дори дългосрочен ключ да изтече по-късно.

Голямо число в спецификация не отговаря на нито един от тези въпроси, а сравняването на числа между несвързани алгоритми не е класация. Питайте вместо това какво осигурява обменът на ключове.

Къде свършва тунелът

Крайната точка, която прекратява тунела, може да чете това, което препраща. Това важи еднакво за корпоративен шлюз, търговски доставчик и самостоятелно хостван сървър. Това е дизайнът, а не дефект в него. Силната криптография не може да спре компрометирана крайна точка да чете открит текст, който пристига при нея, защото крайната точка е мястото, където защитата спира.

HTTPS продължава след тази точка, затова един сайт може да е сигурен във враждебна мрежа дори без VPN. Двете защити се припокриват в първата отсечка и само една от тях продължава след изхода.

Ето защо отслабването на проверката на сертификата, за да проработи връзка, не е тест на тунела. То изключва друга защита и ви оставя с по-малко, отколкото сте започнали.

Защо анонимността е друг продукт

Адресите, времето и обемът остават наблюдаеми извън тунела. Наблюдателят може да види, че трафикът тече към VPN крайна точка, приблизително колко и кога. Съдържанието може да е нечетимо, докато моделът все още носи информация.

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

Изберете доставчик по политиката му за регистриране и юрисдикцията, ако това е изискването, а след това прочетете самата политика. Маркетинговите страници рядко отговарят на този въпрос по начин, който някой може да провери.

Проверявайте тунела и сайта поотделно

Първо проверете тунела, за да знаете коя защита тествате. След това проверете собствения транспорт на сайта и сравнете двата резултата, вместо да предполагате, че едното означава другото. Тунел, който пренася обикновен HTTP, и сайт, който сервира HTTPS, правят точно това, за което са конфигурирани.

Изпълнявайте проверките срещу хост, който ви е разрешено да тествате, и четете изхода, а не обобщението.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Когато тунелът е включен и сайтът е HTTPS, имате две защити в първата отсечка и една във втората. Когато сайтът е обикновен HTTP, втората отсечка е четима за всеки в нея, включително изходът, който е препратил заявката. Да знаете коя от двете липсва, е цялата диагноза и това изисква две команди, а не нов клиент.