У статті ми розбираємо продовження теми Просунуте використання OpenVPN, його використання та виправлення помилок.
295 
Багато хто використовує OpenVPN для приховання справжнього IP та обходу блокувань доступу до веб-сайтів. Але цим можливості технології VPN не обмежені. За своїм поняттям (Virtual Private Network) за допомогою OpenVPN можна налаштовувати віртуальні приватні мережі, таким чином організуючи закритий із-за простір зі зручним доступом до локальних ресурсів тим, хто до цих мереж підключений. Причому «локальними» ці ресурси є всередині віртуальної приватної мережі, тобто насправді віддалений комп’ютер може бути підключений до Інтернету на іншому кінці світу через два NAT’а, але ми можемо підключатися до його веб-сервера або файлового сховища безпосередньо всередині віртуальної мережі. Тобто такий підхід дозволяє вирішувати й інші завдання: доступ до ресурсів комп’ютера, що знаходиться за NAT (що не має статичного публічного IP), шифрування даних, вихід в Інтернет приховуючи свій справжній IP та інші.
Тепер пропоную вивчити OpenVPN та розглянути різні фішки не зовсім стандартного використання OpenVPN: обхід перехоплюючих порталів, обхід обмежень NAT, використання переваг віртуальної приватної мережі. До речі, якщо вам потрібен VPS сервер, щоб ви могли встановити на нього OpenVPN і повторювати те, що я показую, спробуйте цей. Це можливість створити захищене оточення, в якому учасники можуть звертатися до ресурсів один одного, обминаючи всі проблеми та обмеження NAT. Також можна вигадати не зовсім стандартні способи використання OpenVPN — для обходу Wi-Fi хот-спотів, наприклад. Головна мета зробити так, щоб ви думали про OpenVPN ширше. Це можливість створити захищене оточення, в якому учасники можуть звертатися до ресурсів один одного, минаючи обмеження NAT.
Якщо ви дивилися Інструкцію з налаштування сервера та клієнта OpenVPN, то могли звернути увагу, що вона дуже велика. До речі, якийсь час тому я доповнив і виправив цю інструкцію (у частині установки на Debian, Ubuntu, Linux Mint, Kali Linux). Щоб зробити життя трохи простіше, я написав скрипт OpenVPNassistent, який допомагає автоматизувати процес створення конфігураційних файлів та ключів для сервера та клієнтів OpenVPN. Причому цей скрипт створює конфігураційні файли з вбудованими сертифікатами (для сервера їх 5, а кожного клієнта по 4. Скрипт, наскільки це можливо, автоматизує все процеси.
Скрипт підтримує роботу у похідних Debian (Ubuntu, Kali Linux, Linux Mint), а також у похідних Arch Linux (BlackArch, Manjaro). Я його тестував у Kali Linux, Arch Linux/BlackArch, Ubuntu.
Скачаємо скрипт:
Запускаємо:
При запуску скрипт перевірить, чи встановлений OpenVPN, якщо не встановлений, запитає дозвіл і встановить. Далі перевірить, чи створено Центр Сертифікації (CA) – якщо ні, то запропонує створити його – погоджуємось.
Придумайте, введіть та (головне) запам’ятайте пароль центру сертифікації. Потім підтвердіть цей пароль:
Якщо все пройшло без помилок, то з’явиться повідомлення, що створено приватний ключ (файл .key) і створено файл запиту (.req).
Для отримання сертифіката (публічного ключа) потрібно підписати файл запиту — саме до цього скрипт відразу і переходить. У нас запитують, чи хочемо ми підписати ключ для, набираємо yes:
Вводимо пароль від центру сертифікації:
Якщо все нормально, то буде виведено:
Ці файли знаходяться в папці зі скриптом у підпапці configs. Усі сертифікати вже вбудовані всередині конфігураційних файлів – це дуже зручно, не потрібно їх розміщувати, прописувати шляхи. Причому створені конфігураційні файли універсальні ви можете з їх допомогою підключатися до OpenVPN серверу з Linux, Windows, Android.
Під час повторного запуску з’являються нюанси. По-перше, якщо ви не змінюєте імена сервера та клієнтів, то скрипт питатиме, чи потрібно перезаписувати вже існуючі файли? По-друге, якщо ви використовуєте ті ж імена файлів клієнта і сервера, то створення підписаного сертифіката для них завжди буде завершуватися помилкою, що такий сертифікат вже існує в базі даних. Ця база даних є кілька файлів у вигляді простого тексту, де перераховані раніше створені сертифікати. Це дуже схоже на баг, оскільки неможливо підписати сертифікат для того ж імені. Тому щоб «обійти» цю проблему на той випадок, якщо потрібно знову створювати сертифікати для сервера і клієнтів з тими ж іменами (server, client1, client2, client3 і т. д.), я просто видаляю Центр Сертифікації і потім створюю його по- новому.
Щоб видалити CA в Debian і похідних (разом із ключами CA, а також усіма іншими ключами, створеними в CA):
Щоб видалити CA в Arch Linux і похідних (разом із ключами самого CA, а також усіма іншими ключами, створеними в CA):
Якщо у вас там якісь свої налаштування та своя інфраструктура, то не робіть так! Якщо ж ви створюєте Центр Сертифікації тільки щоб підписати ключі для OpenVPN сервера/клієнтів, то нічого страшного в цьому немає — такий самий CA можна ініціалізувати однією командою скільки завгодно разів. Причому це жодна проблема мого скрипта – це проблема easy-rsa для якої мій скрипт є обгорткою. Тобто якщо ви будете вручну вводити команди для створення кожного сертифіката, то зіткнетеся з такими самими проблемами.
Оскільки це може спричинити плутанину, повернемося до теорії з основ роботи OpenVPN сервера та клієнтів. Для запуску OpenVPN сервера потрібні:
У попередній статті з налаштування OpenVPN, ми розміщували необхідні сертифікати, потім у конфігураційному файлі прописували шлях до кожного з цих сертифікатів, і вже потім запускали OpenVPN сервер із зазначенням на наш конфігураційний файл. Для OpenVPN, файли сертифікатів можна вбудувати (впровадити) у конфігураційний файл. Як це зробити я розповідав на додаток до тієї статті. На попередньому етапі за допомогою скрипту ми створили конфігураційні файли, в які вже вбудовані всі необхідні сертифікати, тобто нам не потрібно їх встановлювати окремо на сервер і клієнти. Достатньо лише скопіювати файл server.conf на сервер, а файли client1.ovpn, client2.ovpn і т.д. розкидати по відповідним клієнтам.
Файл server.conf можна «закинути» на сервер за допомогою утиліт scp і sftp за допомогою FTP або веб-файлового менеджера — як умієте. Причому, якщо у вас є доступ по SSH, то можете просто створити на сервері текстовий файл за допомогою nano/vim і скопіювати вставити вміст файлу server.conf, оскільки це файл у вигляді простого тексту.
Для перевірки я запускаю OpenVPN на сервері в консолі (файл server.conf розміщений у поточній папці):
З’явився напис:
Це означає, що сервер OpenVPN успішно запущено.
Тепер на стороні клієнта я запускаю (файл з налаштуваннями у мене розміщений по дорозі bin/OpenVPNassistent/configs/client1.ovpn):
Аналогічно, напис, свідчить про те, що ми успішно підключилися до сервера OpenVPN.
До речі, для виходу до Інтернету через OpenVPN мережу на сервері потрібно налаштувати маршрутизацію. Знову дивимося у вікно OpenVPN сервера:
Там численні повідомлення про те, що пакет відкинуто -packet dropped:
Можна було б подумати, що є проблеми, але насправді OpenVPN мережа працює, на клієнті можна перевірити:
Трафік йде через вузол 10.8.0.1 – це шлюз нашої віртуальної приватної мережі, тобто працює нормально. З якоїсь причини локальні пакети потрапляють на OpenVPN сервер. З одного боку, нічого особливо страшного в цьому немає, вони просто відкидаються. Але, з іншого, це неправильно — треба розібратися з маршрутизацією — повернуся до цього потім.
Якщо у вас теж все гаразд, файл server.conf можна помістити в папку /etc/openvpn/server/:
Запускаємо фонову службу OpenVPN:
Перевіряємо її статус:
І додаємо її в автозавантаження:
Я покажу як підключитися до файлу .ovpn, який був створений за допомогою мого скрипту на початку цієї статті. Завантажте в Google Play офіційний клієнт OpenVPN.
Тепер, коли все налаштовано і готове, можна нарешті перейти до веселощів (це для вас від початку статті пройшло кілька хвилин – для мене пройшло кілька днів: поки написав скрипт, налагодив на кількох системах, розібрався з різними технічними питаннями, підправив команди в налаштування OpenVPN і, нарешті, дійшов до цього місця). VPN – віртуальна приватна мережа – має свій адресний простір, за замовчуванням це 10.8.0.0/24. Кожному пристрою (комп’ютеру, телефону) з цього простору видається IP-адреса. Ці адреси належать до локальних. І звертаючись за цією адресою можна отримати доступ до ресурсів (мережевих служб, файлів) комп’ютера, який не має білого IP. Наприклад, я підключив до моєї локальної мережі новий пристрій — систему Linux із запущеним веб-сервером. Подивимося список мережевих інтерфейсів:
Можна побачити, що інтерфейс eth0 має IP адресу 10.0.2.15 — це сірий IP і неможливо підключитися до цього комп’ютера з Інтернету. До того ж сама система знаходиться за NAT.
Після ввімкнення OpenVPN створюється новий мережний інтерфейс tun0, для даної системи у нього IP адреса 10.8.0.18. Використовуючи IP-адресу інтерфейсу OpenVPN (tun0), інші учасники мережі OpenVPN можуть підключатися до цього комп’ютера. Як я сказав, на цьому комп’ютері запущено веб-сервер. Спробуємо його відкрити на телефоні, який підключений до цієї мережі OpenVPN через зовсім іншого провайдера і взагалі може знаходитися за тисячі кілометрів:
Як можна побачити, це справді працює. Це може бути веб-сервер, файловий сервер (FTP та інші), робочі оточення для спільної роботи (наприклад, виконані у вигляді веб-програм, запущених на веб-сервері). При цьому доступ до цього робочого середовища матимуть лише учасники VPN мережі — від усіх інших воно буде повністю ізольовано. Будь-який з учасників мережі може ділитися будь-якими ресурсами, і будь-який інший учасник може підключатися за допомогою сірого IP, присвоєного всередині мережі OpenVPN. Щоб це працювало, потрібен лише один білий (зовнішній) IP – для самого сервера OpenVPN. Для цих цілей звичайної ВПСки (VPS – Virtual Private Server) з мінімальною конфігурацією по залізу вистачить за очі.
Найпростіший спосіб доступу до мережних служб всередині локальної мережі — за IP адресою, як це показано вище. Проблема в тому, що в мережі OpenVPN IP-адреси не прив’язані жорстко до клієнтів і після перепідключення клієнти можуть отримати інший IP. Можна налаштувати OpenVPN сервер видавати одним і тим самим клієнтам однакові IP, але для цього необхідне дотримання однієї умови. Щоб було зрозуміло, поясню, що для підключення різних клієнтів до одного OpenVPN серверу можна використовуючи одну і ту ж пару публічно-приватний ключ, тобто іншими словами, той самий конфігураційний файл. Це не заборонено, але не рекомендується і для активації цієї можливості необхідно чітко вказати директивою в конфігураційному файлі. За такого способу підключення сервер не зможе розрізняти клієнтів. Тобто при використанні однакових ключів (конфігураційних файлів) різними клієнтами неможливо налаштувати статичні IP адреси в OpenVPN.
Отже, умовою налаштування статичних IP адрес для клієнтів OpenVPN є використання різних ключів. Саме за таким принципом – у кожного клієнта унікальний ключ – створюються конфігураційні файли моїм скриптом, який я презентував на самому початку. Отже, якщо ви створили конфігураційні файли клієнтів за допомогою скрипта, тепер ви зможете налаштувати статичні IP адреси. Налаштування потрібно лише на стороні сервера OpenVPN — в налаштуваннях клієнтів нічого не потрібно змінювати.
Припустимо, я хочу, щоб у client1 була IP адреса 10.8.0.10, у інших:
Мені потрібно на сервері створити директорію, в якій будуть налаштування для кожного клієнта. Цією папкою я вибрав /etc/openvpn/ccd/, створюємо її:
У цій папці потрібно створити текстові файли, які мають такі ж імена, як клієнти OpenVPN, в яких зберігатимуться їх особливі налаштування. До речі, ім’я клієнта можна переглянути в його конфігураційному файлі, воно розміщене в сертифікаті cert і йде в поле Subject, наприклад:
У цьому випадку ім’я клієнта client1, отже, потрібно створити файл /etc/openvpn/ccd/client1.
У цьому файлі достатньо вказати рядок виду:
Якщо у вас звичайні налаштування, то як МАСКИ_ПІДСЕТКИ у вас завжди буде 255.255.255.0. Отже, для першого клієнта, якому я хочу надати IP адресу 10.8.0.10, у файл /etc/openvpn/ccd/client1 я записую:
Те саме можна зробити командою:
І для всіх інших клієнтів:
Щоб сервер OpenVPN підхоплював нові налаштування для клієнтів, у файл /etc/openvpn/server/server.conf
Додати рядок (я його вставив перед сертифікатами):
Щоб зміни набули чинності:
Ну і переконайтеся, що ми нічого не зіпсували:
Наша система Linux з веб-сервером має ім’я client3, подивимося на її IP після перепідключення:
Тепер вона має адресу 10.8.0.30, і саме така адреса матиме ця система при кожному підключенні до сервера OpenVPN. Отже, веб-сервер завжди матиме IP 10.8.0.30 – можна додати до закладок.
Увага: для мобільних клієнтів OpenVPN використовується Topology net30 – можливо, це через якісь обмеження мобільних телефонів. Тому встановити IP описаним вище методом не вдасться Android. IP адреси для Android (можливо, у Windows така сама ситуація) повинні закінчуватися на цифри з наступного списку (перша цифра з кожної пари призначена для сервера, друга для клієнта):
Наприклад, якщо для клієнта client2 ми хочемо встановити IP-адресу 10.8.0.14, то для сервера потрібно писати 10.8.0.13, наприклад:
Повторюся, можливо, це правило обов’язково і для Windows клієнтів — принаймні, раніше було саме так. У Linux все шикарно працює як описано вище.
У статті “Швидкий, простий і робочий спосіб обходу Captive Portal (hotspot з авторизацією на web-інтерфейсі)” як теоретичний спосіб обходу, я згадував можливість налаштування OpenVPN на 53 UDP порту. Також я написав, що це не вийшло. На той раз у мене не було свого OpenVPN сервера, тому я знайшов OpenVPN з тестовим періодом і з можливістю вибрати порт 53 UDP. Але спроби підключитися до сервера OpenVPN закінчилися невдачею.
Тепер у мене знову з’явилася можливість потестувати вже інший hotspot з авторизацією на web-інтерфейсі і це дійсно працює в ньому. Тобто якщо я просто намагаюся вийти в Інтернет, то я отримую:
Але варто включити OpenVPN, то я одразу можу користуватися Інтернет-доступом без авторизації! Тобто це дійсно працює, щоправда, мабуть не з усіма Порталами, що перехоплюють. Мабуть, деякі з них досить інтелектуальні, щоб зрозуміти, що це якісь неправильні запити DNS і що їх не потрібно пропускати.
Нагадаю, у чому суть вразливості деяких Captive Portal: принцип їхньої роботи в тому, що вони закривають усі TCP та UDP порти для пристроїв, які ще не виконали вхід. Всі – крім одного UDP порту під номером 53. Цей порт необхідний для DNS запитів і якщо його закрити, це спричиняє занадто багато проблем. Тому цей порт відкритий і через нього можна виходити у світ.
Без попередньої підготовки через цей порт ви тільки зможете на халяву робити DNS запити… Але якщо ви налаштували ваш OpenVPN відповідним чином, то через відкритий UDP порт 53 ви зможете підключатися до сервера OpenVPN, а вже він для вас виходитиме у зовнішній світ і точно також, цим же шляхом повертати отриману інформацію. Це працює стабільно і, за суб’єктивними відчуттями, коли мережа завантажена, трафік UDP 53 має пріоритет…
Тобто працює навіть краще, ніж якби я купив доступ і сидів через цей же хотспот на TCP трафіку (я порівнював і так і так). Хоча, можливо, свою роль відіграє OpenVPN. Я помічав, що при гарному підключенні, коли я сиджу через OpenVPN, пінги краще, ніж коли я використовую Інтернет-підключення звичайним чином.
Отже, для цього потрібен тільки OpenVPN сервер, налаштований для роботи за протоколом UDP (за умовчанням) з номером порту 53 (його потрібно вибрати під час створення конфігураційних файлів). Можливо, працює не для всіх хотспотів — продовжуватиму тестувати.
Можливо це надто окремий випадок, але все одно розповім про цікаву ситуацію. Припустимо, що IP-адреса OpenVPN сервера 185.117.153.79. Тоді маршрутизація на комп’ютері буде налаштована приблизно так:
Саме через трафік до адреси 185.117.153.79 відбувається підключення до OpenVPN серверу. Якби для цієї адреси не було зроблено виняток, тоді неможливо було б підключитися до OpenVPN серверу і комп’ютер залишився б без Інтернет-доступу взагалі.
В принципі, нічого страшного, але що робити, якщо я, наприклад, хочу відкрити сайт suip.biz, у якого IP адреса 185.117.153.79? Щоразу, коли я відкриваю цей сайт, трафік спрямовується безпосередньо – минаючи OpenVPN мережу. За звичайних умов це може бути нормально, але якщо OpenVPN використовується для анонімності або для обходу порталу, що перехоплює (це мій випадок), то виходить, що я взагалі не можу відкрити сайт suip.biz. Вихід із ситуації дуже простий. Пригадаємо, що сервер OpenVPN доступний як частина віртуальної приватної мережі за IP адресою 10.8.0.1.
Тому у файлі /etc/hosts
Достатньо додати рядок:
І тепер доступ до цього сайту буде відбуватися через мережу OpenVPN — тобто він буде без проблем відкриватися (але поки я підключений до OpenVPN — після відключення потрібно видалити/закоментувати цей запис). Так само, якщо мені потрібно підключитися до SSH сервера OpenVPN:
Коли я підключений до OpenVPN, я можу використовувати локальний IP віртуальної приватної мережі:
Я підключуся до цього ж сервера, але при цьому трафік не йтиме «крім» – все всередині VPN!
Якщо ви для захоплення виберіть звичайний інтерфейс, наприклад wlan0 або eth0, всі дані будуть зашифровані – їх неможливо аналізувати.
Щоб передані через OpenVPN дані було видно нормально, для захоплення потрібно вибрати інтерфейс tun0.
Кстати, если перед вами задачи провести оценку качества/безопасности VPN, то захват надо делать именно на обычном интерфейсе — если вы там видите читаемые данные вроде таких:
Значить, ваше VPN з’єднання просто не зашифроване. До речі, це не стосується теми OpenVPN, але як з’ясували дослідники з безкоштовних Android додатків VPN – 84% з них розкривають IP-адресу користувача. І серед платних VPN теж багато тих, які допускають просочування даних.
Але набагато цікавіше було б дізнатися, скільки з них моніторять та логують трафік…
На сьогодні все, я сподіваюся вам буде корисна дана інформація. Далі буде…
295 
462