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