Для організації з’єднань OpenVPN використовує свій оригінальний протокол над TCP/UDP, що в свою чергу застосовує SSL/TLS для обміну ключами. Програма використовує бібліотеку OpenSSL для шифрування як корисних даних, так і сервісних, що необхідні для створення підключень і підтримки з’єднань. Остання, в свою чергу, дозволяє задіяти увесь набір алгоритмів шифрування, що доступні в бібліотеці.
Клієнти для OpenVPN існують для великої кількості операційних систем і платформ, в т.ч. мобільних та ОС для роутерів. У цьому сенсі це майже універсальне рішення.
Автентифікувати підключення OpenVPN-сервер може наступними способами:
- За допомогою логіна та пароля із клієнтськими сертифікатами/без сертифікатів. Це забезпечується сторонніми модулями.
- За допомогою попередньо згенерованого єдиного ключа для сервера та клієнта (PSK, тобто з’єднання встановлюється симетричним алгоритмом шифруванням).
- Аутентифікація за допомогою сертифікатів (TLS client/server mode). Найбільш надійний варіант, адже в клієнта та сервера є свій унікальний набір ключів/серифікатів, що підписані одним центром сертифікації.
У останньому варіанті аутентифікації, сервер та клієнт мають свій ключ, випущений сертифікат та кореневий (СА) сертифікат. Для підняття рівня безпеки, клієнт також може мати додатковий пароль.
Аутентифікація OpenVPN клієнта сервером складається із наступних кроків:
1. Клієнт ініціює підключення до сервера.
2. Сервер у відповідь надає власний сертифікат для його перевірки клієнтом:
а) Клієнт, використовуючи власну копію СА сертифікату, перевіряє сертифікат наданий сервером
b) Якщо перевірка закінчується невдачею (наприклад, власний сертифікат сервера не був підписаний копією CA-сертифікату клієнта), підключення припиняється.
с) У разі, якщо клієнт використовує списки CRL (список відкликаних сертифікатів), представлений сервером сертифікат на має бути в ньому описаний.
3. Якщо клієнт маю свою пару ключів (сертифікат і приватний ключ), тоді:
a) Клієнт надає свій сертифікат серверу
b) Сервер перевіряє його справжність власною копією CA-сертифікату
c) Якщо попередня перевірка завдає невдачі - сервер розриває процес підключення
d) У разі, якщо сервер використовує списки CRL, представлений клієнтом сертифікат на має бути перерахований в ньому.
4. Якщо клієнт налаштований відсилати логін/пароль, то він це робить через вже активну TLS-сесію.
5. Якщо сервер налаштований на обробку логіну/паролю, надісланих від клієнта, тоді:
a) Клієнт має обов’язково надати додатковий логін/пароль, якщо це не опціонально
b) Викликається програма/плагін, яка відповідальна(ий) за перевірку наданих клієнтом даних.
c) У разі, якщо перевірка зазнає невдачі, клієнт буде сповіщений про це і процес підключення зупиниться.
6. Якщо на сервері активована опція ccd (client-config-dir), тоді:
a) Якщо ім’я клієнта зазначене як таке, що не має права підключатись до сервера, з’єднання буде завершене.
b) Якщо використовується опція 'ccd-exclusive', клієнт повинен мати ccd-запис, інакше підключення буде завершене.
7. Аутентифікація з обох сторін завершена.
Найбільш поширені випадки використання OpenVPN:
1. Вихід в мережу з білої IP-адреси OpenVPN-сервера (client-server VPN). Увесь трафік буде надходити в зашифрованому вигляді по віртуальній приватній мережі, котру надає сервер, і далі NAT, створений за допомогою Iptables/UFW, транслюватиме ці запити в мережу Інтернет. Це може бути корисно для шифрування даних в відкритих Wi-Fi мережах різних публічних місць (кафе, магазини, бібліотеки, готелі), для маскування своєї справжньої IP-адреси для доступу до закритих ресурсів у вашій країні і т.п. Часто в готелях, аеропортах відкрито лише 2 порти для підключень: 443 та 80 TCP, тому ми налаштуємо 2 процеси OpenVPN: перший буде обслуговувати 1143 порт UDP, який по своїй природі працює швидше за TCP, та 443 TCP для випадків, якщо підключення по UDP заборонені.
2. Організація виходу в віддалену локальну мережу через OpenVPN сервер, що знаходиться в цій же мережі та має білу IP-адресу. Різниця між цим та першим випадком полягає в додатковому маршруті на клієнтських машинах, котрий надсилає OpenVPN сервер клієнту та в дещо змінених правилах Iptables.
3. Об'єднання двох віддалених локальних мереж в одну.
У цій статті ми розглянемо лише перші два випадки, які в кінцевому рахунку не дуже відрізняються один від одного
1. USING IP OF OPENVPN SERVER FOR ACCESSING INTERNET
1.1. KEYS/CERTIFICATE GENERATION FOR SERVER
Для аутентифікації сервера з клієнтом ми скористаємось TLS режимом роботи OpenVPN, як найбільш надійним варіантом. Для цього потрібно створити кореневий сертифікат, закритим ключем якого підпишемо ключі для сервера та кожного клієнта. Тобто створимо свою власну інфраструктуру відкритих ключів (PKI).
Установимо необхідні пакети для генерації усіх необхідних ключів та сертифікатів:
# apt-get update
# apt-get install openvpn easy-rsa
У старіших релізах Ubuntu набір скриптів та сертифікатів easy-rsa входив в пакет openvpn, а наразі easy-rsa виділений в окремий пакет. Опціонально можна скористатись git-репозиторієм easy-rsa.
Створимо темплейт-директорію easy-rsa у власній домашній:
$ make-cadir ~/openvpn-ca
$ cd ~/openvpn-ca
Для генерації сертифікатів змінимо параметри по-замовчуванню на необхідні, наприклад:
$ vim vars
...
export KEY_COUNTRY="NL"
export KEY_PROVINCE="NH"
export KEY_CITY="Amsterdam"
export KEY_ORG="My Organization"
export KEY_EMAIL="me@myhost.mydomain"
export KEY_OU="MyOrganizationalUnit"
...
export KEY_NAME="server"
...
Ці дані насправді необхідні виключно для власника сервера. Змінна KEY_NAME має мати стале значення впродовж всього процесу налаштування.
Копіюємо значення змінних файлу vars до змінних середовища:
$ cd ~/openvpn-ca
$ source vars
Очищуємо, про всяк випадок, директорії від старих сертифікатів/ключів:
$ ./clean-all
І вже зараз можемо перейти до процесу створення кореневого сертифікату:
$ ./build-ca
Generating a 2048 bit RSA private key
..........................................................................................+++
...............................+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [NL]:
State or Province Name (full name) [NH]:
Locality Name (eg, city) [Amsterdam]:
Organization Name (eg, company) [My Organization]:
Organizational Unit Name (eg, section) [Community]:
Common Name (eg, your name or your server's hostname) [My Organization CA]:
Name [server]:
Email Address [me@myhost.mydomain]:
Змінні будуть підставлені зі згаданого вище файлу vars, котрі, за необхідності, можна змінити в процесі. Або ж можна прости тиснути підтвердження.
Володіючи CA сертифікатом, можемо створити решту необхідних сертифікатів/ключів. Створимо ключ та сертифікат для сервера:
$ ./build-key-server server
Поки не будемо вводити ніяких додаткових паролів. На два останні питання даємо стверджувальну відповідь:
...
Certificate is to be certified until May 1 17:51:16 2026 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Отож ми створили сертифікат та ключ для сервера. Далі згенеруємо параметри для протоколу обміну ключами Діффі-Геллмана:
$ ./build-dh
Суть цього протоколу заключається в тому, що обидві сторони з'єднання отримують спільний ключ для симетричного кодування без його безпосередньої передачі. Через відкритий канал передаються лише проміжні дані для одночасної генерації спільного ключа на клієнті та сервері і, перехопивши їх, зловмисник не зможе розгадати основний секрет.
Насправді алгоритм RSA також може за допомогою асиметричного шифрування передати спільний ключ для подальшого симетричного шифрування, але алгоритм Діффі-Геллмана додає більшої безпеки цьому процесу, адже в такому разі зловмисник, що якимось чином заволодів закритим RSA-ключем сервера (він же приватний ключ), не зможе розшифрувати дані, котрі були перехоплені до цього.
Власне тому алгоритм обміну ключами Діффі-Геллмана забезпечує властивість цілковитої прямої секретності (Perfect Forward Secrecy, PFS) в недовговічних режимах TLS.
І останнє, що необхідно зробити для серверної частини OpenVPN - створити додатковий ключ HMAC для TLS-аутентифікації:
$ openvpn --genkey --secret keys/ta.key
Він буде розміщений як на сервері, так і на клієнті. Про це трішки далі.
Варто зауважити, що офіційна документація радить використовувати окремий сервер для генерації сертифікатів, процес їх створення має відбуватись від імені не root користувача та з мінімумом необхідного програмного забезпечення. Це все для максимального рівня безпеки.
1.2. KEYS/CERTIFICATE GENERATION FOR CLIENT
Ключ та сертифікат для клієнта можна створити на клієнтській машині і вже потім їх підписати на сервері, проте для зручності ми зробимо це все одразу на сервері.
Виконаємо наступне:
$ cd ~/openvpn-ca
$ source vars
$ ./build-key client1
Якщо є бажання додати пароль підключення, генерацію ключів варто проводити з build-key-pass:
$ cd ~/openvpn-ca
$ source vars
$ ./build-key-pass client1
Знову ж на запит створення challenge password відповідаємо "ні" та два рази "так" на запити підписання та коміту сертифіката.
Трохи пізніше ми згенеруємо ovpn файл з усіма необхідними ключами та параметрами, котрий можна легко імпортувати в будь-який популярний OpenVPN-клієнт.
1.3. OPENVPN SERVER CONFIGURATION
Скопіюємо всі згенеровані ключі до директорії OpenVPN серверу:
$ cd ~/openvpn-ca/keys
$ sudo cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn
Для створення конфігураційного файлу скористаємось шаблоном, що розповсюджується разом із пакетом openvpn:
$ gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | sudo tee /etc/openvpn/server.conf
Відредагуємо його відповідно до наших потреб:
# vim /etc/openvpn/server.conf
Перш за все перевіримо який порт та протокол вказані для роботи сервера:
port 1194
proto udp
Порт 1194 закріплений за OpenVPN організацією IANA, тому не варто перейматись, що цей порт буде потребувати інший сервіс чи конфліктуватиме з демоном, що вже працює. UDP - це кращий вибір, адже за цільністю і послідовністю пакетів слідкуватиме TCP, котрий вже працюватиме в OpenVPN-тунелі. Саме через велику кількість таймерів протоколу та через більшу кількість метаданих, TCP може дуже сильно впливати на швидкість роботи тунеля в мережах поганої якості.
Оберемо тип мережевого інтерфейсу, для емуляції:
dev tun
tun-інтерфейс - це пристрій 3 рівня мережі OSI. OpenVPN також вміє емулювати tap-інтерфейс, що працює рівнем нижче і оперує ethernet-фреймами. tap-інтерфейс необхідно використовувати у bridge-конфігураціях, наприклад, коли потрібно об'єднати декілька ethernet-мереж. Мобільні ж клієнти для ОС Android не вміють працювати з tap-інтерфейсом.
Шлях до сертифікатів та ключа для сервера:
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
Шлях до ключа Деффі-Хелмана:
dh dh2048.pem
Це та значення вище - це значення по замовчуванню, вони вже встановлені в файлі конфігурації.
Діапазон адрес, які будуть роздаватись клієнтам, значення по-замовчуванню. І я не бачу причин, чому він нас не може влаштовувати на даному етапі:
server 10.8.0.0 255.255.255.0
Список IP-адрес та імен клієнтів, що їм відповідають. Необхідний для того, щоб видавати клієнтам ті ж адреси після кожного перевантаження серверу чи перепідключення клієнтів:
ifconfig-pool-persist ipp.txt
У мене цей список порожній, адже я користуюсь одним ключем для багатьох одночасних підключень:
duplicate-cn
Це не бажано для випадків, коли сервером користуються декілька людей і їхні сертифікати можна буде відкликати адміністратором сервера без їхньої згоди (різні ж бувають ситуації).
Вкажемо для клієнта, що маршрут до VPN-сервера має бути маршрутом по замовчуванню для всіх з'єднань. Ну ми ж вирішили, що хочемо представлятись в мережі від імені зовнішньої білої адреси VPN-сервера:
push "redirect-gateway def1 bypass-dhcp"
Інакше буде лише окремий маршрут на підмережу, яку обслуговує VPN-сервер. Знову ж, все залежить від конкретних потреб.
Конфігурація адрес DNS-серверів для OpenVPN-підключення на стороні клієнта:
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
Також опціонально, якщо DNS-сервери по-замовчуванню на клієнтах задовольняють вашим потребам. Запити на них, якщо попередня push-інструкція була активована, будуть також відправлятись через маршрут VPN-сервера.
Між іншим, раніше OpenDNS-сервери перенаправляли запити на рекламні сторінки у разі, якщо запитані домени не було знайдено. Враховуючи таку історію, можливо, варто обрати кращу альтернативу.
Укажемо тайм-аути для підключення. Перше число вказує на те, як часто перевіряти доступність клієнта, а друге - після скількох секунд з'єднання необхідно вважати закритим. Всі значення рахуються в секундах:
# default 10 120
keepalive 50 200
Говорять, що занизькі тайм-аути можуть призводити до посиленого використання батареї мобільного телефону.
Укажемо ключ для TLS-аутентифікації (HMAC) та напрямок роботи ключа:
tls-auth ta.key 0 # This file is secret
key-direction 0
Ця директива додає додатковий підпис HMAC до всіх пакетів установки з’єднання SSL/TLS (SSL/TLS handshake) для перевірки їх цілісності на рівні каналу управління. Будь-який UDP-пакет, що не має коректного підпису HMAC буде відкинуто без подальшої обробки. А, отже, HMAC-підпис надає додатковий рівень захисту від DoS-атак, флуду на порт OpenVPN, сканування портів, з’єднань від несанкціонованих вузлів (вузлів, що не мають цього ключа). Хоча такі з’єднання все рівно не пройдуть аутентифікацію, підпис HMAC знищить такі пакети на початковому рівні, не витрачаючи потужності CPU на непотрібні подальші криптооперації. http://wiki.dieg.info/hmac
Для каналу управління цей ключ pre-shared, тобто має бути попередньо згенерований і вже після розміщений як на клієнті, так і на сервері.
Для клієнта key-direction буде рівний 1, це зазначимо вже потім.
Укажемо мінімальну версію TLS, з якою можна проводити з’єднання:
tls-version-min 1.2
Якщо версія OpenVPN нижча за 2.3.2 - то це працювати не буде, у такому випадку мінімальна версія - TLSv1.0.
Останні версії OpenVPN (версії 2.x, при умові використання TLS режима) в основному використовують 2 канали:
• Канал управління (control channel). Це канал не передає багато даних і необхідний лише для передачі параметрів з'єднання, ключів для каналу даних (data channel). І саме тут всі ці дані передаються по захищеному TLS-протоколу.
• Канал даних (data channel). Через цей канал і прямує увесь корисний трафік. Шифрується цей канал матеріалом/параметрами, що отримуються він каналу управління.
Обидва ці канали працюютьв межах єдиного TCP чи UDP порту.
Обмежимо перелік можливих наборів TLS-шифрів, що підтримує сервер (перевірити чи вони доступні в конкретній версії сервера можна виконавши openvpn --show-tls):
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
Це необхідно для убезпечення від атак, коли клієнт-зловмисник навмисно хоче використовувати найпростіший алгоритм. Звісно ці шифри мають підтримувати як сервер, так і клієнти.
Власне цей набір TLS-шифрів - це перелік симетричних/асиметричних алгоритмів, протоколів обміну ключами і т.п., що буде використовуватись для передачі службої інформації (канал управління, control channel). Наприклад, перший шифронабір TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 вказуватиме на використання наступних алгоритмів:
• ECDHE (Elliptic curve Diffie–Hellman Exchange) - протокол Діффі-Геллмана на еліптичних кривих. Власне це варіація звичайного протокол Діффі-Геллмана, але з використанням еліптичної криптографії.
• RSA (Rivest, Shamir and Adleman) - криптографічна система з відкритим ключем. Використовується зазвичай для аутентифікації сервера чи клієнта, тобто визначення, що кожна сторона є справді тим, ким себе видає. Часто в обхід протоколу Діффі-Геллмана для передачі симетричного ключа на сервер використовується RSA, тобто ключ шифрується публічним ключем сервера.
• AES (Advanced Encryption Standard) - симетричний алгоритм блочного шифрування, використовується вже після обміну ключами та аутентифікації. Вже власне він і шифрує дані симетричним ключем, що був отриманий по ECDHE чи RSA алгоритмам. У даному конкретному випадку буде використовуватись AES в режимі GCM (Galois/Counter Mode - режим лічильника з аутентифікацією Галуа).
• SHA256. Геш-функція, котру необхідно використовувати в HMAC (Hash-based message authentication code) для каналу управління. Це механізм перевірки цілісності інформації (data integrity), що передається або зберігається в ненадійному середовищі: якщо в процесі передачі третя сторона змінить дані - про це одразу стане відомо отримувачу, котрий може самостійно вирахувати значення HMAC на власній строні. HMAC - це різновид MAC (Message Authentication Code) алгоритму. HMAC та MAC потребують спільного ключа для роботи і у випадку каналу управління він має бути pre-shared, а для каналу даних він генерується динамічно для кожної сесії. Перший також потребує указання типу геш-функції, значенням котрої по-замовчуванню є SHA1. Для каналу даних OpenVPN тип геш-функції вказується аргументом до параметру auth.
Тож шифронабори можуть бути різними і скажімо замість ECDHE використовуватись звичайний DHE. У разі, якщо шифронабори не будуть погоджені (всі варіанти клієнт вважатиме неприйнятними) з'єднання буде розірване. Ми ж обрали найнадійніші варіанти на даний момент.
Укажемо криптографічний шифр, що будемо використовувати після установки з’єднання для каналу передачі даних (data channel):
cipher AES-256-CBC
Список всіх можливих шифрів, що підтримує OpenVPN, можна побачити виконавши openvpn --show-ciphers. Укажемо використання 256 бітного хеш-алгоритму SHA256 для HMAC аутентифікації каналу даних:
auth SHA256
Цей ключ буде генеруватись динамічно для кожного нового сеансу з'єднання з використанням даних, що надійшли з каналу управління.
Схожим чином можна перевірити, які інші алгоритми аутентифікації підтримуються - openvpn --show-digests.
Опція для компресії трафіку. Має невисокі показники стиснення трафіку, але і не сильно навантажує систему:
comp-lzo
Вкажемо OpenVPN працювати на мінімальних правах після ініціалізації процесу, адже йому не потрібні права root-користувача на постійній основі:
user nobody
group nogroup
Не будемо перечитувати файли ключів після SIGUSR1 сигналу чи --ping-restart перевантаження:
persist-key
Ця опція часто комбінується з попередньою, адже користувач nobody не зможе перечитати файли ключів на диску через брак прав.
Указання не вимикати і піднімати TUN/TAP-інтерфейс знову у разі перевантаження OpenVPN-сервера (SIGUSR1 сигнал для процеса чи --ping-restart перевантаження) чи його короткої тимчасової недоступності:
persist-tun
Це може бути корисно у разі, коли сервер використовується як шлюз по-замовчуванню і, при тимчасовій недоступності сервера, трафік не піде напряму через мережу Інтернет.
Ну і нарешті відредагуємо правила логування:
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
mute 20
Статус роботи серверу буде записаний до openvpn-status.log, логування буде вестись без перезапису файла в /var/log/openvpn.log і для зменшення однотипних повідомлень ми їх лімітуємо до 20 однакових (опція mute).
Повний конфіг виглядатиме наступним чином:
# cat /etc/openvpn/server.conf
# Port and protocol
port 1194
proto udp
# Emulated network interface
dev tun
# Server's certificates/key
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
# Diffie-Hellman key
dh dh2048.pem
# OpenVPN client's address pool
server 10.8.0.0 255.255.255.0
# Persist list of IPs and client's names
ifconfig-pool-persist ipp.txt
# With this option we can use one key/cert
# on many clients at the same time
duplicate-cn
# All traffic from clients goes to vpn interface
push "redirect-gateway def1 bypass-dhcp"
# Push DNS-settings to client
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
# Timeouts
# default 10 120
keepalive 50 200
# TLS authentication secret
tls-auth ta.key 0 # This file is secret
key-direction 0
# Minimal TLS version for connection
tls-version-min 1.2
# TLS cipheres. We are using only most secure ones.
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
# Encryption algorithm for traffic
cipher AES-256-CBC
# HMAC auth
auth SHA256
# Traffic commpression
comp-lzo
# Redusing daemon's privileges after initialization.
user nobody
group nogroup
# Persistence of client's interface/key
# after server restarting
persist-key
persist-tun
# Logging parameters
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
# No more than 20 the same messages
mute 20
1.4. FIREWALL SETTINGS/MASQUARADING
Майже все. Наразі додамо правила UFW (фронтенд до Iptables) для маскарадингу трафіку з підмережі 10.8.0.0/24 на інтерфейс eth0 (або інший, до якого призначена біла IP-адреса):
# vim /etc/ufw/before.rules
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
# Don't delete these required lines, otherwise there will be errors
*filter
...
Змінимо політику по-замовчуванню для FORWARD-пакетів:
# vim /etc/default/ufw
...
DEFAULT_FORWARD_POLICY="ACCEPT"
...
Також для можливості пересилання трафіку між інтерфейсами необхідно активувати опцію net.ipv4.ip_forward в /etc/sysctl.conf:
# vim /etc/sysctl.conf
...
net.ipv4.ip_forward=1
...
# sysctl -p
Закриємо всі порти окрім необхідних:
# ufw allow 1194/udp
# ufw allow OpenSSH
Та перевантажимо фаєрвол:
# ufw disable
# ufw enable
Або ж можна просто перевантажити сервіс:
# systemctl restart ufw
1.5. START OPENVPN SERVER
Ubuntu 16.04 по-замовчуванню поставляється з системою ініціалізації systemd, ознайомитись з нею можна прочитавши, наприклад цю статтю. Конфігураційний файл має назву /etc/openvpn/server.conf, тож процес запускається виходячи з цього імені:
# systemctl start openvpn@server
Перевіримо статус процесу:
# sudo systemctl status openvpn@server.service
● openvpn@server.service - OpenVPN connection to server
Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-01-16 23:56:22 UTC; 2min 37s ago
Docs: man:openvpn(8)
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
https://community.openvpn.net/openvpn/wiki/HOWTO
Main PID: 2424 (openvpn)
CGroup: /system.slice/system-openvpn.slice/openvpn@server.service
└─2424 /usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/server.conf --writepid /run/openvpn/server.pid
Jan 16 23:56:22 ubuntu-do systemd[1]: Starting OpenVPN connection to server...
Jan 16 23:56:22 ubuntu-do systemd[1]: openvpn@server.service: PID file /run/openvpn/server.pid not readable (yet?) after start: No such file or directory
Jan 16 23:56:22 ubuntu-do systemd[1]: Started OpenVPN connection to server.
Та чи піднято інтерфейс OpenVPN-сервера:
# ip addr show tun0
15: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
valid_lft forever preferred_lft forever
Якщо все і справді працює - додаємо демон в автозавантаження:
# systemctl enable openvpn@server
1.6. CONFIG GENERATION FOR CLIENT
Згенеруємо конфігурацію для клієнта та разом з необхідними ключами об'єднаємо все в один ovpn-файл. Створимо структуру директорій для файлів клієнта:
$ mkdir -p ~/client-configs/files
$ chmod 700 ~/client-configs/files
Скопіюємо приклад налаштування, що надає OpenVPN-пакет:
$ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf
І додати/підправити/залишити лише наступні значення:
$ vim ~/client-configs/base.conf
client
dev tun
proto udp
remote public_ip_of_vpn_server 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
remote-cert-tls server
cipher AES-256-CBC
auth SHA256
# 0 is on server and 1 on client
key-direction 1
comp-lzo
verb 4
mute 20
# script-security 2
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
Не буду зациклюватись на опціях клієнта, адже вони майже аналогічні опціям серверу. Варто зауважити, що вони мають відповідати опціям, що виставлені на сервері (такий самий інтерфейс, cipher, auth, алгоритм компресії трафіка і т.п.). Опція remote вказує на адресу і порт роботи VPN-сервера; nobind наказує обирати динамічний порт для роботи клієнта. resolv-retry infinite запускає перепідключення у разі розриву з'єднання з сервером. Замість infinite можна вказати цифру, котра вказуватиме як довго намагатись перепідключитись. Наприклад resolv-retry 5 вказує на те, що протягом 5 секунд клієнт намагатиметься перестворити підключення.
Останні 3 закоментовані лінії - це оновлення DNS-налаштувань. Якщо клієнт працює на ОС Linux/Android - то їх можна розкоментувати. Хоча, можливо, їх наявність для всіх операційних систем не критичною при підключенні.
Враховуючи сертифікат і ключ для клієнта, котрий ми створили раніше, ми можемо перейти до генерації ovpn-профілю. Для цього створимо скрипт, який власне збере всі змінні:
$ vim ~/client-configs/make_config.sh
#!/bin/bash
# First argument: Client identifier
KEY_DIR=~/openvpn-ca/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf
cat ${BASE_CONFIG} \
<(echo -e '<ca>') \
${KEY_DIR}/ca.crt \
<(echo -e '</ca>\n<cert>') \
${KEY_DIR}/${1}.crt \
<(echo -e '</cert>\n<key>') \
${KEY_DIR}/${1}.key \
<(echo -e '</key>\n<tls-auth>') \
${KEY_DIR}/ta.key \
<(echo -e '</tls-auth>') \
> ${OUTPUT_DIR}/${1}.ovpn
Ну і нарешті згенеруємо ovpn-профіль:
$ cd ~/client-configs
$ bash make_config.sh client1
$ ls ~/client-configs/files
client1.ovpn
Тепер безпечним шляхом скопіюємо профіль на необхідні клієнтські пристрої і перевіримо чи відбувається підключення:
# apt-get install openvpn
# openvpn --config client1.ovpn
Tue Jan 17 13:27:07 2017 OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2016
Tue Jan 17 13:27:07 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Tue Jan 17 13:27:07 2017 Control Channel Authentication: tls-auth using INLINE static key file
Tue Jan 17 13:27:07 2017 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jan 17 13:27:07 2017 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
...
Tue Jan 17 13:27:07 2017 UDPv4 link remote: [AF_INET]public_ip_of_vpn_server:1194
Tue Jan 17 13:27:07 2017 TLS: Initial packet from [AF_INET]public_ip_of_vpn_server:1194, sid=37e337ef 07e1628d
Tue Jan 17 13:27:08 2017 VERIFY OK: depth=0, C=NL, ST=NH, L=Amsterdam, O=My Organization, OU=Community, CN=My Organization CA, name=server, emailAddress=me@myhost.mydomain
Tue Jan 17 13:27:08 2017 Validating certificate key usage
Tue Jan 17 13:27:08 2017 ++ Certificate has key usage 00a0, expects 00a0
Tue Jan 17 13:27:08 2017 VERIFY KU OK
Tue Jan 17 13:27:08 2017 Validating certificate extended key usage
Tue Jan 17 13:27:08 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Jan 17 13:27:08 2017 VERIFY EKU OK
Tue Jan 17 13:27:08 2017 VERIFY OK: depth=0, C=NL, ST=NH, L=Amsterdam, O=My Organization, OU=Community, CN=My Organization CA, name=server, emailAddress=me@myhost.mydomain
Tue Jan 17 13:27:08 2017 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jan 17 13:27:08 2017 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jan 17 13:27:08 2017 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jan 17 13:27:08 2017 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Jan 17 13:27:08 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Jan 17 13:27:08 2017 [blabla.info] Peer Connection Initiated with [AF_INET]public_ip_of_vpn_server:1194
Tue Jan 17 13:27:10 2017 SENT CONTROL [blabla.info]: 'PUSH_REQUEST' (status=1)
Tue Jan 17 13:27:10 2017 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.10 10.8.0.9'
...
Tue Jan 17 13:27:10 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Jan 17 13:27:10 2017 ROUTE_GATEWAY 10.128.43.1/255.255.255.0 IFACE=eth0 HWADDR=74:d4:35:87:65:c7
Tue Jan 17 13:27:10 2017 TUN/TAP device tun0 opened
...
Tue Jan 17 13:27:10 2017 /sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
Tue Jan 17 13:27:10 2017 /sbin/ip route add 10.8.0.1/32 via 10.8.0.9
Tue Jan 17 13:27:10 2017 GID set to nogroup
Tue Jan 17 13:27:10 2017 UID set to nobody
Tue Jan 17 13:27:10 2017 Initialization Sequence Completed
З виводу вже непогано помітно, що відбувається. У разі, якщо підключення пройшло успішно, на клієнті будуть приблизно такі маршрути:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 tun0
public_ip_of_vpn_server 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
Перше на що треба звернути увагу - це те що першим маршрутом по-замовчуванню став маршрут, що надав OpenVPN-сервер (10.8.0.5 gateway), а зовнішня адреса OpenVPN-сервера 'public_ip_of_vpn_server' роутиться на попередній шлюз 192.168.1.1.
Аналогічно можна імпортувати ovpn-профіль через графічний фронтенд Network Manager:
Для Андроїд я користуюсь OpenVPN Client Free, так як він на мою думку найбільш зручний, хоч і з рекламою. До плюсів його можна також віднести можливість увімкнення маршрутів VPN лише для окремих програм. Офіційний OpenVPN Connect клієнт також пристойний, але не такий зручний як попередній. OpenVPN for Android, як на мене, виявився найбільш ненажерливий до батареї. Всі загадані клієнти підтримують імпорт ovpn-профілю.
На MacOS для підключення до OpenVPN я користуюсь Tunnelblick. Для iOS також є офіційний клієнт OpenVPN Connect, а для Windows як мінімум цей має працювати.
1.7. OPTIONAL PART: OPENVPN INSTANCE ON 443 TCP PORT
Як я вже згадував, в деяких публічних місцях для підключень відкриті лише 2 порти: 80 та 443 TCP. І це звісно буде перешкодою для підключення до стандартного 1143 UDP-порту. Тож для обходу таких проблем я пропоную підняти додаткову копію OpenVPN серверу на тому ж хості, що працюватиме на 443 порту TCP. А використовувати його вже будемо лише за необхідності.
Зупинимо вже запущену копію OpenVPN, перейменуємо для зручності конфігураційний файл, що обслуговує UDP та скопіюємо його як темплейт для TCP інстансу:
# systemctl stop openvpn@server
# cd /etc/openvpn
# mv server.conf server_udp_1194.conf
# cp server_udp_1194.conf server_tcp_443.conf
Останній необхідно відредагувати до наступного вигляду:
# vim /etc/openvpn/server_tcp_443.conf
# Port and protocol
port 443
proto tcp
# Emulated network interface
dev tun
# Server's certificates/key
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
# Diffie-Hellman key
dh dh2048.pem
# OpenVPN client's address pool
server 10.9.0.0 255.255.255.0
# Persist list of IPs and client's names
ifconfig-pool-persist ipp.txt
# With this option we can use one key/cert
# on many clients at the same time
duplicate-cn
# All traffic from clients goes to vpn interface
push "redirect-gateway def1 bypass-dhcp"
# Push DNS-settings to client
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
# Timeouts
# default 10 120
keepalive 50 200
# TLS authentication secret
tls-auth ta.key 0 # This file is secret
key-direction 0
# Minimal TLS version for connection
tls-version-min 1.2
Єдине на що тут варто звернути увагу - це на протокол tcp, порт 443, нову підмережу для клієнтів 10.9.0.0/24 та той факт, що ми будемо використовувати все той же набір сертифікатів, що і для UDP-з'єднання. Про всі інші опції можна почитати вище.
Додатково, нам необхідно створити UFW/Iptables правило на трансляцію (masquerading) адрес нової підмережі:
# vim /etc/ufw/before.rules
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
# Don't delete these required lines, otherwise there will be errors
*filter
...
Додане правило я навів жирним шрифтом.
Розблокуємо 443 TCP-порт та перевантажимо фаєрвол:
# ufw allow 443/tcp
# ufw disable
# ufw enable
Запустимо два інстанси та додамо їх до автозавантаження:
# systemctl start openvpn@server_udp_1194
# systemctl start openvpn@server_tcp_443
# systemctl enable openvpn@server_udp_1194
# systemctl enable openvpn@server_tcp_443
# systemctl disable openvpn@server
Попередньо згенерований ovpn-профіль також варто скопіювати та підправити значення порту та протоколу.
Звісно, може бути, що це не найелегантніше рішення - підняття двох інстансів OpenVPN.
1.7. REVOKING CLIENT CERTIFICATES
У випадку, коли кожен користується своїм набором ключів, є можливість заборонити підключення окремим клієнтам, відізвавши його сертифікат. Для цього перейдемо в попередню директорію, що була створена раніше:
$ cd ~/openvpn-ca
$ source vars
Скористаємось скриптом revoke-full, передавши аргументом ім'я клієнта, доступ якому необхідно заборонити:
$ ./revoke-full client3
Результатом роботи скрипта буде файл crl.pem в директорії keys. Скопіюємо його до директорії налаштувань сервера:
$ sudo cp ~/openvpn-ca/keys/crl.pem /etc/openvpn
Та активуємо опцію, що буде перевіряти відізваних клієнтів:
# vim /etc/openvpn/server.conf
...
crl-verify crl.pem
...
Перевантажуємо OpenVPN і насолоджуємось своєю всесильністю:
# systemctl restart openvpn@server
Для того, щоб відізвати кожного наступного клієнта, необхідно знову викликати скрипт revoke-full, передавши ім'я наступного клієнта у якості аргумента, та знову скопіювати crl.pem до директорії з налаштуваннями OpenVPN. І вже після цього знову перевантажити сервер.
2. ACCESS TO LOCAL NETWORK BEHIND OPENVPN SERVER
2.1. OPENVPN SERVER SETUP/CONFIGURATION/START
Отже, початкові дані такі: є два сервери, що знаходяться в одній локальній мережі 10.133.0.0/16, IP-адреса першого сервера 10.133.11.198, а другого - 10.133.11.200. До того ж в першого сервера є публічна адреса - public_ip_of_vpn_server. Завдання полягає в отриманні доступу до локальної мережі та всіх її ресурсів через Інтернет.
Отже, на перший сервер (10.133.11.198) необхідно встановити OpenVPN-сервер, згенерувати всі необхідні сертифікати та ключі для сервера (як в пункті 1.1). Конфігураційний файл для OpenVPN-сервера буде дещо інший, ніж в попередніх випадках:
# vim /etc/openvpn/server.conf
# Port and protocol
port 1194
proto udp
# Emulated network interface
dev tun
# Server's certificates/key
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
# With this option we can use one key/cert
# on many clients at the same time
duplicate-cn
# Diffie-Hellman key
dh dh2048.pem
# OpenVPN client's address pool
server 10.8.0.0 255.255.255.0
# Push routes to the client to allow it to reach
# other private subnets behind the server
push "route 10.133.0.0 255.255.0.0"
# Timeouts
# default 10 120
keepalive 50 200
# TLS authentication secret
tls-auth ta.key 0 # This file is secret
key-direction 0
# Minimal TLS version for connection
tls-version-min 1.2
# TLS cipheres. We are using only most secure ones.
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
# Encryption algorithm for traffic
cipher AES-256-CBC
# HMAC auth
auth SHA256
# Traffic commpression
comp-lzo
# Redusing daemon's privileges after initialization.
user nobody
group nogroup
# Persistence of client's interface/key
# after server restarting
persist-key
persist-tun
# Logging parameters
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
# No more than 20 the same messages
mute 20
Тут треба звернути увагу на те, що було прибрано надсилання адрес DNS-серверів до клієнта (dhcp-option DNS), прибрані установки маршруту OpenVPN як основного для клієнтів (redirect-gateway def1) та додано створення додаткового маршруту для клієнтів для обслуговування локальної мережі через адресу OpenVPN-серверу (push "route 10.133.0.0 255.255.0.0").
Перевантажуємо сервер, додаємо його в автозавантаження:
# systemctl restart openvpn@server
# systemctl enable openvpn@server
2.2. FIREWALL SETTINGS/MASQUARADING
У цьому випадку трансляцію необхідно робити через інтерфейс, котрому призначена адреса локальної мережі 10.133.11.198. У моєму випадку це інтерфейс eth1. Додамо відповідне правило для маскарадингу:
# vim /etc/ufw/before.rules
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth1
-A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE
COMMIT
# END OPENVPN RULES
# Don't delete these required lines, otherwise there will be errors
*filter
...
Як бачимо різниця між першим і цим випадком мінімальна.
Знову ж, змінимо політику по-замовчуванню для FORWARD-пакетів:
# vim /etc/default/ufw
...
DEFAULT_FORWARD_POLICY="ACCEPT"
...
Аналогічні (майже) iptables-правила виглядатимуть наступним чином:
# iptables -t nat -s 10.8.0.0/24 -A POSTROUTING -o eth1 -j MASQUERADE
# iptables -A FORWARD -i eth1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT
Для можливості пересилання трафіку між інтерфейсами потрібно активувати опцію net.ipv4.ip_forward в /etc/sysctl.conf:
# vim /etc/sysctl.conf
...
net.ipv4.ip_forward=1
...
# sysctl -p
І в решті решт перевантажимо ufw:
# systemctl restart ufw
2.3. KEYS/CERTIFICATE/PROFILE GENERATION FOR CLIENT
Все абсолютно так само, як виконували раніше в пунктах 1.2 та 1.6.
2.4. OPENVPN CLIENT CONNECTION/PING TESTS
Як і раніше підключаємось:
# openvpn --config client_name.ovpn
Якщо підключення відбулось успішно, маршрути будуть виглядати наступним чином:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.133.0.0 10.8.0.5 255.255.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
Як бачимо, маршрут на мережу OpenVPN не став маршрутом по-замовчуванню (мережу як і раніше обслуговує шлюз 192.168.1.1) та запити до мережі 10.133.0.0/16 наразі відправляються на шлюз в мережі VPN, завдяки чому і є доступ до них:
# ping -c 2 10.133.11.198
PING 10.133.11.198 (10.133.11.198) 56(84) bytes of data.
64 bytes from 10.133.11.198: icmp_seq=1 ttl=64 time=43.7 ms
64 bytes from 10.133.11.198: icmp_seq=2 ttl=64 time=43.6 ms
--- 10.133.11.198 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 43.654/43.706/43.759/0.215 ms
# ping -c 2 10.133.11.200
PING 10.133.11.200 (10.133.11.200) 56(84) bytes of data.
64 bytes from 10.133.11.200: icmp_seq=1 ttl=63 time=44.3 ms
64 bytes from 10.133.11.200: icmp_seq=2 ttl=63 time=44.2 ms
--- 10.133.11.200 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 44.255/44.303/44.352/0.216 ms
У наступній статті я розкажу, як об'єднати дві віддалені локальні мережі за допомогою OpenVPN.
P.S. На що ще варто звернути увагу? Ну перш за все на VPN сервер SoftEther, що надає одразу можливість підключення по всім (!) найпопулярнішим vpn-технологіям. За необхідності можна також звернути увагу на obfsproxy, проксі що може приховувати тип трафік від аналізаторів, на кшталт Great China Firewall. Scramble патч також покликаний вирішувати подібну проблему, планів про його включення в основний код немає, проте в Інтернеті є багато посилань як накладувати цей патч. Зауважу, що клієнти також мають вміти працювати з ним. По останньому посиланню також можна побачити, які vpn-протоколи Великий Китайський Фаєрвол може відслідковувати та блокувати.
Посилання:
OpenVPN:
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-16-04
https://en.wikipedia.org/wiki/OpenVPN
https://ru.wikipedia.org/wiki/TUN/TAP
https://community.openvpn.net/openvpn/wiki/Concepts-Authentication
https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html
https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN
https://community.openvpn.net/openvpn/wiki/Hardening
https://help.ubuntu.com/lts/serverguide/openvpn.html
https://help.ubuntu.com/community/OpenVPN
https://www.linode.com/docs/networking/vpn/set-up-a-hardened-openvpn-server
https://www.linode.com/docs/networking/vpn/configuring-openvpn-client-devices
https://www.linode.com/docs/networking/vpn/tunnel-your-internet-traffic-through-an-openvpn-server
https://blog.g3rt.nl/openvpn-security-tips.html#15-use-sha-2-for-message-authentication
http://lithium.opennet.ru/articles/openvpn/openvpn-howto.html
http://www.opennet.ru/opennews/art.shtml?num=45777
http://yakim.org.ua/articles/servers/141-sshl.html
http://yakim.org.ua/articles/servers/170-openvpn-esxi.html
https://community.openvpn.net/openvpn/wiki/BridgingAndRouting
https://github.com/ttlequals0/autovpn
https://github.com/Nyr/openvpn-install
https://www.cyberciti.biz/faq/howto-setup-openvpn-server-on-ubuntu-linux-14-04-or-16-04-lts/amp/
http://p.umputun.com/p/2014/08/12/svoi-sobstviennyi-vpn-za-3-minuty/
https://arashmilani.com/post?id=53
http://ics-openvpn.blinkt.de/FAQ.html#faq_androids_clients_title
https://www.comparitech.com/blog/vpn-privacy/hide-openvpn-traffic-with-ssh-tunnel/
https://community.openvpn.net/openvpn/wiki/TrafficObfuscation
https://www.lowendtalk.com/discussion/21539/tutorial-build-your-ultimate-scrambled-vpn
https://tunnelblick.net/cOpenvpn_xorpatch.html
https://forums.openvpn.net/viewtopic.php?t=12605
http://sysadm.pp.ua/linux/shifrovanie/openvpn-client-server.html
http://sysadm.pp.ua/linux/shifrovanie/openvpn-easy-rsa.html
http://serverfault.com/questions/418354/how-to-set-up-openvpn-to-let-the-vpn-clients-to-access-all-the-servers-inside-th
http://serverfault.com/questions/202917/openvpn-vs-ipsec-pros-and-cons-what-to-use
http://www.ques10.com/p/9848/explain-tcp-timers-1/
https://www.bestvpn.com/blog/7359/httpswww.bestvpn.comblog7359openvpn-tcp-vs-udp-difference-choose/
http://sites.inka.de/bigred/devel/tcp-tcp.html
http://security.stackexchange.com/a/65877/112175
https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html
http://wiki.dieg.info/openvpn
https://habrahabr.ru/post/188042
TLS/SSL:
https://pro-ldap.ru/tr/zytrax/tech/ssl.html
https://en.wikipedia.org/wiki/Transport_Layer_Security
RSA:
http://www.michurin.net/computer-science/rsa.html
https://uk.wikibooks.org/wiki/book
Diffie-Hellman:
https://uk.wikipedia.org/wiki/DH
https://security.stackexchange.com/questions/41205/diffie-hellman-and-its-tls-ssl-usage/41226#41226
https://security.stackexchange.com/questions/65864/why-openvpn-is-using-both-certificates-and-dh/65877#65877
MAC/HMAC:
http://crypto.stackexchange.com/a/6527/44846
https://ru.wikipedia.org/wiki/HMAC
Огромное спасибо за столь подробную guide. Очень помогла, так как сталкиваюсь впервые с настройкой такого рода.
ВідповістиВидалитиНо возник вопрос, как я понимаю известная проблема MULTI: bad source address from client [192.168.87.248], packet dropped.
Помогите решить, сервер и клиент настроены в соответствии с вашей статьей.
Спробуйте розібратись прочитавши посилання https://serverfault.com/a/695555/192282
Видалити