Openvpn authenticate decrypt packet error cipher final failed

Тут собраны ссылки на основные примеры настройки OpenVPN сервера и клиента. Дан рабочий конфиг. Приведены основные ошибки при соединении клиента и сервера и

Настройка OpenVPNСтолкнулся с необходимостью поднять OpenVPN. Случай мой оказался не стандартным. Cервер должен быть на Windows, клиентами же выступают пром. gsm-модемы. с линуксом  на борту. Задача не простая, тут собран мой опыт по настройке OpenVPN, и варианты граблей с которыми мне пришлось в этом процессе столкнуться. Начну пожалуй с ресурсов которые мне в этом помогли:

Примеры настройки OpenVPN

Основные ресурсы с примерами настройки openVPN сервера и клиентов:

    • прежде всего официальный мануал:https://openvpn.net/index.php/open-source/documentation/manuals/openvpn-20x-manpage.html

теперь ряд русскоязычных ресурсов:

    • http://compkaluga.ru/articles/172/ — грамотный туториал с указанием основных возможных ошибок
    • http://www.sysadmin.in.ua/info/index/22/27/39 — простая и доходчивая статья, но в настройках допущена ошибка —

      # Эти параметры в среде windows — не дадут клиенту подключиться к серверу. их следует закоментировать или убрать.
      user nouser
      group nogroup

пойдем дальше

  • Эта статья незаслуженно низко находится в выдаче поисковиков http://interface31.ru/tech_it/2011/09/organizaciya-vpn-kanalov-mezhdu-ofisami.html — очень грамотная и доступная подробно разбирает процесс настройки сервера и клиента, а так же вопросы настройки маршрутизации трафика. Т.е. если у вас задача объединить несколько офисных сетей — то обязательна к изучению. Однако, вопрос генерации ключей дан вскользь, для этого стоит посмотреть один из мануалов дальше.
  • http://habrahabr.ru/post/233971/ — подробный разбор запуска на Linux системах. В конце материала описана процедура настройки для windows систем.
  • http://habrahabr.ru/sandbox/58689/ — по сути краткая шпаргалка по заведению openVPN на windows. полезна в том случае если подробный разбор вы уже изучили, но подзабыли отдельные детали процесса.А вот на это я бы обратил внимание:

    — Далее во избежание проблем с созданием сертификата клиента очищаем index.txt папке ssl

  • http://geektimes.ru/post/197744/ Основная особенность этого мануала заключается в том что дан пример настройки OpenVPN под Windows, но без tls аутентификации — соответственно конфиг проще, ключей поменьше. Но и уровень безопасности пожиже. Однако главной фишкой для меня стало вот это: «Теперь о конфиге клиента. Можно не передавать файлы сертификатов, а вписать сразу в конфиг, только делать это лучше не с блокнота, а с AkelPad’а или Notepad++ например.» ну и дальше читайте на странице.От себя должен сказать, что у меня такой файл конфига клиента с вшитыми ключами создать пока не вышло. Но обязательно буду пытаться, о результатах доложу здесь же.
  • http://yakm.ru/Nastroyka-OpenVPN.html тут дан пример простенького конфига с одним секретным ключём на две машины. Т.е. использую данный конфиг, вы можете поднять сервер и подключить к нему одного клиента. Для более сложных конфигураций надо всё-таки генерить все ключи.
  • http://yakm.ru/Nastroyka-OpenVPN-chast-2.html продолжение туториала выше, где собран простенький но полноценный конфиг. Однако вопрос генерации ключей разобран вскользь.
  • http://www.freeproxy.ru/ru/vpn/windows-7/openvpn.htm простой но очень важный туториал по правильной установке и запуску OpenVpn в среде Windows. Особо хотелось бы обратить внимание на необходимость запускать openvpnGUI — от имени администратора. Без этой малости — ни один клиент не сможет подключиться к успешно работающему серверу.
  • http://forum.ixbt.com/topic.cgi?id=14:40906:1#1 — огромная конференция по вопросам работы с OpenVPN. Наверное тут разобраны все возможные вопросы. Однако вкурить всю ветку форума — задача поистине титаническая.
  • http://suli-company.org.ua/it/unix/1063-prostaya-nastroyka-openvpn-s-fiksirovannymi-adresami-klientov.html еще один очень подробный разобор. В основном он посвещен настройки openVPN на Linux. Но разбор конфигов очень подробный. Дан частичный адаптированный русский перевод мануала из первой ссылки. И в конце статьи вариант настройки на Windows.  + решения для нескольких проблемм:»Получено сообщение Initialization Sequence Completed, но пинг не проходит — это означает, что брандмауэр на сервере или клиенте блокирует VPN сетевой трафик на TUN/TAP интерфейсе. Решение проблемы: запретите брандмауэру клиента (если есть) фильтрацию TUN/TAP интерфейса клиента.»
  • http://samag.ru/archive/article/318 — еще один разбор настройки OpenVPN —  тут упор сделан на кросс-платформенность.

OpenVPN и роутеры

Сети связывать лучше посредством специальных устройств, нежели выделять для этого дела отдельный компьютер. Хорошая новость — есть огромное количество роутеров которые со спец прошивкой — поддерживают OpenVPN, если у вас возник вопрос «Какой роутер поддерживает OpenVPN» то поискать ответ можно тут:

http://www.dd-wrt.com/site/support/router-database

Для себя, опытным путем, я выбрал роутер Asus RT-N10U, и настроил его под свой конфиг. Главное преимущество — возможность перепрошить его прямо в окне браузера.  А дальше читайте в статье.

Конфиг OpenVPN Сервера, на Windows 7:

Ну и собственно мой конфиг. Он прямо скажем не идеален, но вполне годен.

port 1194
proto udp
dev tap2
dev-node «vpn»
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
client-to-client #разрешить общение клиентов между собой подробнее см.ниже
topology subnet
route-method exe
route-delay 5
route 10.8.0.0 255.255.255.0
#PUSH START те данные которые мы передаем на клиент.
#push «dhcp-option gateway 10.8.0.1» — имело бы смысл с windows клиентами, у нас linux
push «persist-key»
push «persist-tun»
#PUSH END
duplicate-cn #позволяем нескольким клиентам пользоваться одним ключом
keepalive 10 120
#cipher AES-128-CBC #закоментировали алгоритм шифрования будет использован по умолчанию
comp-lzo
persist-tun
persist-key
persist-local-ip
persist-remote-ip
status openvpn-status.log
log c:\OpenVPN\log\openvpn.log
verb 5

Настройка Клиента IRZ RUH2:

В нашем случае это GSM router IRZ RUH2, здесь  я не даю подробной инструкции, просто конфиг, который у меня отлично работает. Ключи на модем я добавлял через upload в администрировании.

client
proto udp
dev tap2
remote 111.111.111.111 1194
ca ca.crt #ключи
key client.key
cert client.crt
route-method ipapi #если клиент Linux, exe если Windows
route-delay 5 #пауза для применения настроек 5-10 секунд
route 10.8.0.0 255.255.255.0 10.8.0.1 #прописываем на клиенте маршрут
route-gateway 10.8.0.1 #Шлюз
comp-lzo #сжатие
nobind #
persist-key #
persist-tun
verb 5
mute 20

Некоторые ошибки при настройке OpenVPN

Authenticate/Decrypt packet error: packet HMAC authentication failed

В моем случае эта ошибка разрешилась с помощью изменения Hash Algorithm  на SHA1 у клиента, т.е. приведение к тому же значению что и на сервере.

Authenticate/Decrypt packet error: cipher final failed

— ошибка алгоритма шифрования. вероятно в настройках клиента и сервера указаны разные варианты cipher.  Как вариант можно не указывать его вообще, тогда будет взят вариант по умолчанию (bf-cbc)

Не возможно подключиться к интерфейсу, если служба уже запущена

Идем в службы и выключаем её

При запуске сервера OpenVPN ошибкa: не возможно добавить маршрут в таблицу маршрутизации

Решение: Не хватает прав доступа, необходимо запустить сервер от имени администратора.

Клиент находит сервер, подключается, но не пингуется, или не может подключиться.

— Необходимо на сервере внести в правила фаервола исключение для нашего сервиса.

Клиент находит сервер, но не пингуется.

— Необходимо настроить маршрутизацию т.е. запустить запросы в нашу vpn сеть через наш tap интерфейс. В нашем случае мы можем запустить консоль Windows от имени админиcтратора и там вручную добавить маршрут к примеру:
route -p add 10.8.0.0 mask 255.255.255.0 10.8.0.1
-p — добавляем маршрут на постоянной основе, без этого аргумента при перезагрузки маршрут исчезнет.
10.8.0.0 mask 255.255.255.0 — задаем диапазон адресов для которых будет действовать маршрут, все пакеты идущие на адреса с 10.8.0.1 до 10.8.0.255.
10.8.0.1 — шлюз, gateway, на который будем слать пакеты. В нашем случае это сервер VPN соединения.

Ошибка: Initialization Sequence Completed With Errors ( see http://openvpn.net/f…#dhcpclientserv )

вылечилось добавлением openVPN в исключения фаервола.

Соответственно, для Windows систем, от XP до 7ки это можно сделать, выполнив в консоли следующую команду от имени администратора:

netsh firewall add allowedprogram program = C:OpenVPNbinopenvpn.exe name = «OpenVPN Server» ENABLE scope = ALL profile = ALL

Продолжение темы настройки openVPN:

  • Настройка OpenVPN на роутере DD-WRT Asus RT-N10U
  • Клиенты OpenVPN не видят друг друга

Обычно довольно легко настроить VPN с использованием OpenVPN. Это одна из самых привлекательных функций OpenVPN по сравнению с другими решениями VPN. Однако иногда необходимо устранить неполадки в нерабочей настройке или настроить существующую настройку для повышения производительности.

Устранение неполадок и настройка OpenVPN часто игнорируются. Файлы журнала OpenVPN на стороне клиента и сервера предоставляют много информации, но вы должны знать как их читать. При настройке файлов конфигурации клиента и сервера также допускается довольно много ошибок. В этой главе вы узнаете, как интерпретировать файлы журнала OpenVPN и как обнаруживать и исправлять некоторые из этих распространенных ошибок.

Наконец, существует большая разница между рабочей установкой и установкой, которая работает хорошо. Возможно, ваша установка OpenVPN работает правильно, но пользователи все равно могут жаловаться на низкую производительность. Получение максимальной производительности от установки OpenVPN может показаться черной магией. В этой главе вы узнаете немного этой черной магии.

В этой главе будут рассмотрены следующие темы:

  • Как читать файлы журнала
  • Исправление распространенных ошибок конфигурации
  • Устранение проблем с маршрутизацией
  • Как оптимизировать производительность с помощью ping и iperf
  • Анализ трафика OpenVPN с использованием tcpdump

Как читать файлы журнала

Поначалу отладка нерабочих настроек может показаться сложной задачей. С чего начать? К счастью, OpenVPN предоставляет отличные средства ведения журналов и отладки. Однако с увеличением степени детализации журналов становится все труднее читать эти файлы журналов. Уровень детализации журнала OpenVPN по умолчанию равен 1, но рекомендуется установить степень детализации 3. Это часто дает администратору достаточно информации для обнаружения проблем с настройкой, в то же время сводя к минимуму потери производительности.

Установка детальности на 5 или выше рекомендуется только для целей отладки, так как это сильно повлияет на производительность.

Каждый пример в этой книге до сих пор включал устанку verb 3. Во-первых, мы рассмотрим файлы журнала клиента и сервера для рабочей настройки с такой детальностью. Важно понимать и, возможно, даже хранить файлы журналов работающего соединения. При попытке найти ошибку в нерабочей настройке, очень полезно сравнивать файлы журнала нерабочего случая с файлами рабочей настройки.

Запустите сервер, используя файл конфигурации по умолчанию basic-udp-server.conf:

[root@server]# openvpn --config basic-udp-server.conf

Пока не подключайтесь к клиенту. Файл журнала сервера теперь будет содержать следующее:

 1 14:53:27 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
            [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
            built on Dec 2 2014
 2 14:53:27 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
            LZO2.03
 3 14:53:27 Diffie-Hellman initialized with 2048 bit key
 4 14:53:31 WARNING: this configuration may cache passwords in
            memory -- use the auth-nocache option to prevent this
 5 14:53:31 Control Channel Authentication: using
            '/etc/openvpn/movpn/ta.key' as a OpenVPN static key
            file
 6 14:53:31 Outgoing Control Channel Authentication: Using 160
            bit message hash 'SHA1' for HMAC authentication
 7 14:53:31 Incoming Control Channel Authentication: Using 160
            bit message hash 'SHA1' for HMAC authentication
 8 14:53:31 Socket Buffers: R=[16777216->131072]
            S=[16777216->131072]
 9 14:53:31 TUN/TAP device tun0 opened
10 14:53:31 TUN/TAP TX queue length set to 100
11 14:53:31 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
12 14:53:31 /sbin/ip link set dev tun0 up mtu 1500
13 14:53:31 /sbin/ip addr add dev tun0 10.200.0.1/24
broadcast 10.200.0.255
14 14:53:31 GID set to nobody
15 14:53:31 UID set to nobody
16 14:53:31 UDPv4 link local (bound): [undef]
17 14:53:31 UDPv4 link remote: [undef]
18 14:53:31 MULTI: multi_init called, r=256 v=256
19 14:53:31 IFCONFIG POOL: base=10.200.0.2 size=252, ipv6=0
20 14:53:31 Initialization Sequence Completed

Метки времени в начале каждой строки были сокращены для ясности.

Давайте посмотрим на этот файл журнала построчно:

  • Строки 1 и 2 указывают версию и дату сборки самого OpenVPN, а также библиотеки, от которых зависит OpenVPN.
  • Строка 3 говорит нам, что параметры Диффи-Хеллмана сервера были успешно инициализированы. Файл, указанный в строке конфигурации сервера dh /etc/openvpn/movpn/dh2048.pem был использован для этого.
  • Строка 4 — это предупреждение, которое печатается почти всегда. Разработчики обсуждали, следует ли удалить эту строку или нет. В конце концов было решено, что по соображениям безопасности лучше всего распечатать это предупреждение. Если вы не слишком озабочены безопасностью, то можете игнорировать эту строку предупреждения.
  • Строка 5 указывает, что канал управления защищен с использованием параметра конфигурации tls-auth и что OpenVPN смог успешно прочитать указанный файл.
  • Строки 6 и 7 сообщают нам, что два ключа SHA1 получены из файла tls-auth и теперь используются для подписи (хэширования) исходящего трафика и для проверки входящего трафика.
  • Строка 8 показывает размер буферов Receive (R) и Send (S), которые использует OpenVPN. Эти параметры полезны только при доработке рабочей настройки, как мы увидим позже в этой главе.
  • Строки 9 и 10 показывают что OpenVPN смог успешно открыть устройство tun и установить глубину очереди пакетов для этого устройства равной 100.
  • Строки с 11 по 13 показывают настройки IPv4, которые используются для этой конфигурации сервера. Они также указывают что не были заданы параметры IPv6. Перечисленные здесь настройки являются переводом строки конфигурации сервера server 10.200.0.0 255.255.255.0.
  • Строки 14 и 15 являются результатом указания group nobody и user nobody в файле конфигурации сервера соответственно.
  • Строки 16 и 17 показывают что OpenVPN прослушивает трафик UDP и привязан к неопределенному интерфейсу (0.0.0.0). Это результат указания proto udp и bind в файле конфигурации сервера.
  • Строка 18 говорит нам, что это мультиклиентская установка с реальными и виртуальными размерами таблицы хешей 256.
  • В строке 19 указан диапазон адресов пула, доступных клиентам OpenVPN, которые могут подключаться к этому серверу. Это также часть перевода строки конфигурации сервера server 10.200.0.0 255.255.255.0.
  • Строка 20 — это волшебная строка, которая сообщает нам, что сервер успешно запущен и инициализация завершена. Сервер теперь готов принимать соединения от входящих клиентов.

Далее мы запускаем клиент и смотрим файл журнала на стороне сервера:

[root@client]# openvpn --config basic-udp-client.conf

После этого мы также рассмотрим файл журнала на стороне клиента:

21 15:30:37 <CLIENT-IP>:39086 TLS: Initial packet from
            [AF_INET]<CLIENT-IP>:39086, sid=071ba589 7e9ff2a0
22 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=1, C=ZA,
            ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
            CN=Mastering OpenVPN, emailAddress=root@example.org
23 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=0, C=ZA,
            ST=Enlightenment, O=Mastering OpenVPN, CN=client3,
            emailAddress=root@example.org
24 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Cipher
            'BF-CBC' initialized with 128 bit key
25 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Using 160 bit
            message hash 'SHA1' for HMAC authentication
26 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Cipher
            'BF-CBC' initialized with 128 bit key
27 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Using 160 bit
            message hash 'SHA1' for HMAC authentication
28 15:30:37 <CLIENT-IP>:39086 Control Channel: TLSv1, cipher
            TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
29 15:30:37 <CLIENT-IP>:39086 [client3] Peer Connection Initiated
            with [AF_INET]<CLIENT-IP>:39086
30 15:30:37 client3/<CLIENT-IP>:39086 MULTI_sva: pool returned
            IPv4=10.200.0.2, IPv6=(Not enabled)
31 15:30:37 client3/<CLIENT-IP>:39086 MULTI: Learn: 10.200.0.2 →
            client3/<CLIENT-IP>:39086
32 15:30:37 client3/<CLIENT-IP>:39086 MULTI: primary virtual IP
            for client3/<CLIENT-IP>:39086: 10.200.0.2
33 15:30:39 client3/<CLIENT-IP>:39086 PUSH: Received control
            message: 'PUSH_REQUEST'
34 15:30:39 client3/<CLIENT-IP>:39086 send_push_reply():
            safe_cap=940
35 15:30:39 client3/<CLIENT-IP>:39086 SENT CONTROL [client3]:
            'PUSH_REPLY,route-gateway 10.200.0.1,topology subnet,
            ping 10,ping-restart 60,
            ifconfig 10.200.0.2 255.255.255.0' (status=1)

Давайте пройдемся по новым записям журнала:

  • Строка 21 указывает, что исходный пакет был получен от клиента с IP-адресом <CLIENT-IP>. Обычно полный адрес IPv4 указан здесь.
  • Строки 22 и 23 показывают процесс проверки сертификата, предоставленного клиентом OpenVPN. Важной частью в этих строках журнала является VERIFY-OK.
  • Строки с 24 по 27 перечисляют используемый шифр шифрования и дешифрования, а также хэши SHA1, используемые для хеширования входящего и исходящего трафика в канале данных. BF-CBC (Blowfish Cipher Block Chaining) — текущий шифр по умолчанию для OpenVPN.
  • В строке 28 показан шифр TLS, используемый для защиты канала управления OpenVPN. Перечисленный здесь шифр очень похож на код шифрования, используемый защищенным веб-сервером.
  • Строка 29 указывает, что клиент client3 с IP-адреса <CLIENT-IP> успешно прошел процесс аутентификации.
  • В строках с 30 по 32 указывается адрес пула, который будет назначен этому клиенту.
  • Строки с 33 по 34 показывают что клиент запросил информацию о конфигурации (PUSH REQUEST) и ответ от сервера — он отправляет push_reply.
  • Строка 35 показывает содержимое сообщения push_reply со всей информацией о конфигурации для этого клиента. Эта строка чрезвычайно полезна при отладке установки OpenVPN, поскольку она показывает большую часть информации, которую сервер OpenVPN имеет для конкретного клиента, независимо от используемого файла конфигурации.

Аналогично, вот файл журнала клиента (запишите временные метки и сопоставьте их с временными метками из файла журнала сервера):

 1 15:30:37 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
            [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
            built on Dec 2 2014
 2 15:30:37 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
            LZO 2.03
 3 15:30:37 Control Channel Authentication: using
            '/etc/openvpn/movpn/ta.key' as a OpenVPN static key
            file
 4 15:30:37 UDPv4 link local: [undef]
 5 15:30:37 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
 6 15:30:37 [Mastering OpenVPN Server] Peer Connection Initiated
            with [AF_INET]<SERVER-IP>:1194
 7 15:30:39 TUN/TAP device tun0 opened
 8 15:30:39 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
 9 15:30:39 /sbin/ip link set dev tun0 up mtu 1500
10 15:30:39 /sbi/nip addr add dev tun0 10.200.0.2/24
            broadcast 10.200.0.255
11 15:30:39 Initialization Sequence Completed

Давайте пройдемся по новым записям журнала:

  • Строки 1 и 2 очень похожи на строки из журнала сервера.
  • Строка 3 указывает, что канал управления защищен с помощью параметра конфигурации tls-auth и OpenVPN смог успешно прочитать указанный файл.
  • Строки 4 и 5 говорят нам что клиент не связывался с локальным IP-адресом и было установлено соединение UDP с сервером по IP-адресу <SERVER-IP> и порту 1194.
  • В строке 6 указано, что соединение с сервером OpenVPN, идентифицирующим себя как Mastering OpenVPN Server, было успешно установлено. Имя сервера извлекается из общего имени (common name) сертификата на стороне сервера.
  • Строка 7 говорит нам, что OpenVPN смог открыть TUN-устройство tun0.
  • Строки с 8 по 10 перечисляют информацию IPv4, которую сервер передал к этому клиенту и показывают, что IP-адрес и маска сети задаются с помощью стандартной команды Linux /sbin/ip.
  • Строка 11 снова является волшебной строкой, которая сообщает нам, что VPN-соединение было успешно установлено и теперь мы можем безопасно общаться с сервером OpenVPN. Однако, как мы увидим позже, сообщения об ошибках могут еще не появиться.

Обнаружение неработающей установки

Установка OpenVPN может не работать по многим причинам. В следующем разделе мы рассмотрим список распространенных сбоев. Во-первых, давайте посмотрим, что отображается в файлах журналов при неудачной попытке подключения. Сбои могут возникать очень рано при попытке подключения или даже после строки Initialization Sequence Completed.

Если мы используем неправильный файл tls-auth, соединение очень рано оборвется. Это как раз и является причиной использования файла tls-auth, поскольку минимизирует нагрузку на наш сервер OpenVPN, когда мошеннические клиенты пытаются получить доступ. Клиент, который пытается подключиться без указания файла tls-auth, будет отображаться в журналах сервера следующим образом:

16:40:31 Authenticate/Decrypt packet error:
         packet HMAC authentication failed
16:40:31 TLS Error: incoming packet authentication failed from
         [AF_INET]<CLIENT-IP>:49956
16:40:33 Authenticate/Decrypt packet error:
         packet HMAC authentication failed
16:40:33 TLS Error: incoming packet authentication failed from
         [AF_INET]<CLIENT-IP>:49956
16:40:37 Authenticate/Decrypt packet error:
         packet HMAC authentication failed
16:40:37 TLS Error: incoming packet authentication failed from
         [AF_INET]<CLIENT-IP>:49956
16:40:45 Authenticate/Decrypt packet error:
         packet HMAC authentication failed
16:40:45 TLS Error: incoming packet authentication failed from
         [AF_INET]<CLIENT-IP>:49956
16:41:01 Authenticate/Decrypt packet error:
         packet HMAC authentication failed
16:41:01 TLS Error: incoming packet authentication failed from
         [AF_INET]<CLIENT-IP>:49956

Об этом клиенте больше ничего не сообщается, поскольку сервер OpenVPN немедленно отклоняет попытку подключения. Из временных меток в файле журнала мы видим, что клиент увеличивает время задержки между попытками соединения с каждым неудачным соединением. Если в течение 60 секунд соединение не может быть установлено, клиент прервет:

TLS Error: TLS key negotiation failed to occur within 60 seconds
(check your network connectivity)
TLS Error: TLS handshake failed

Второй сбой соединения станет очевидным только после того, как соединение будет успешно инициализировано. Для этого мы указываем использование другого кодирующего шифра на одной стороне, но забываем сделать это на другой. В файле журнала клиента теперь будет отображаться следующее:

16:56:20 /sbin/ip link set dev tun0 up mtu 1500
16:56:20 /sbin/ip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
16:56:20 Initialization Sequence Completed
16:56:30 Authenticate/Decrypt packet error: cipher final failed
16:56:40 Authenticate/Decrypt packet error: cipher final failed

Таким образом, сначала соединение, кажется, было успешно установлено (строки с 1 по 3), но через 10 секунд шифрование и дешифрование канала данных не удается.


Заметка

Если бы в этом случае использовался графический интерфейс Windows, значок графического интерфейса стал бы зеленым, но сама VPN не работала бы!


Во время инициализации будет сообщено о большинстве проблем конфигурации на стороне сервера или клиента. О проблемах маршрутизации, которые встречаются гораздо чаще, OpenVPN обычно не сообщает. Следовательно, требуются различные методы устранения неполадок.

Исправление распространенных ошибок конфигурации

При настройке конфигурации OpenVPN есть несколько распространенных ошибок, которые легко допустить. Эти ошибки конфигурации можно условно разделить на четыре категории:

  • Сертификат (PKI) ошибки и несоответствия
  • Несоответствие опций, таких как tun по сравнению с tap, шифрование и сжатие
  • Недостаточно прав для запуска OpenVPN
  • Ошибки маршрутизации

В этом разделе мы рассмотрим первые три из этих категорий. Ошибки маршрутизации будут обсуждаться позже в этой главе.

Неправильный сертификат CA в конфигурации клиента

Файл конфигурации клиента почти всегда будет содержать три строки, подобные этой:

ca ca.crt
cert client.crt
key client.key

Эти файлы сертификатов и секретных ключей были созданы в главе 3, PKI и сертификаты и широко используются в последующих главах.
Файл CA, однако, не должен указывать центр сертификации, который использовался для подписи файла сертификата клиента. Это должен быть публичный сертификат центра сертификации, который использовался для подписи сертификата сервера. Если сертификат сервера был подписан другим центром сертификации, клиент откажется подключиться к серверу. Это можно увидеть в файле журнала на стороне клиента:

UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
VERIFY ERROR: depth=1, error=self signed certificate in certificate
chain: C=ZA, ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
CN=Mastering OpenVPN, emailAddress=root@example.org
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

В этом случае ошибки не регистрируются на стороне сервера, так как сертификат клиента считается действительным на сервере.

Единственное, что зарегистрируется на сервере, это:

<CLIENT-IP>:42472 TLS: Initial packet from
    [AF_INET]<CLIENT-IP>:42472, sid=9a1e4a84 cdbb6926
<CLIENT-IP>:51441 TLS: Initial packet from
    [AF_INET]<CLIENT-IP>:51441, sid=17d3c89b 6999ae97
<CLIENT-IP>:43513 TLS: Initial packet from
    [AF_INET]<CLIENT-IP>:43513, sid=4609202f 4c91c23d

Это показывает последовательные попытки подключения, которые сделаны клиентом OpenVPN.

Как исправить

Убедитесь, что в файле конфигурации клиента указан правильный файл CA.

Сертификат клиента не распознан сервером

Если сертификат клиента не распознан сервером — сервер откажет в доступе к нему. Это может произойти, если используется неправильный (или мошеннический) клиентский сертификат или если клиентский сертификат был отозван, а опция crl-verify указана в файле конфигурации сервера.

Следующие записи будут отображаться в файле журнала сервера, если неизвестный клиент попытается подключиться к серверу OpenVPN:

<CLIENT-IP>:57072 TLS: Initial packet from
    [AF_INET]<CLIENT-IP>:57072, sid=a175f1be 6faed111
<CLIENT-IP>:57072 VERIFY ERROR: depth=0, error=unable to get
    local issuer certificate: C=NL, O=Cookbook, CN=client1,
    name=Cookbook Client, emailAddress=janjust@nikhef.nl
<CLIENT-IP>:57072 TLS_ERROR: BIO read tls_read_plaintext error:
    error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:
    no certificate returned
<CLIENT-IP>:57072 TLS Error: TLS object -> incoming plaintext
    read error
<CLIENT-IP>:57072 TLS Error: TLS handshake failed

Сервер не может проверить сертификат клиента, так как он не распознает сертификат CA, который использовался для его подписи. Поэтому отказывается разрешить этому клиенту подключаться.

На стороне клиента никакие сообщения не печатаются в файле журнала в течение 60 секунд, после чего первоначальное рукопожатие прекращается и делается новая попытка подключения:

13:24:23 UDPv4 link local: [undef]
13:24:23 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
13:25:23 TLS Error:
TLS key negotiation failed to occur within
    60 seconds (check your network connectivity)
13:25:23 TLS Error: TLS handshake failed
13:25:23 SIGUSR1[soft,tls-error] received, process restarting
13:25:25 Control Channel Authentication: using
    '/etc/openvpn/movpn/ta.key' as a OpenVPN static key file
13:25:25 UDPv4 link local: [undef]
13:25:25 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194

Как исправить

Убедитесь, что сертификат клиента распознается сервером. Это можно сделать либо указав соответствующий сертификат CA в файле конфигурации сервера, либо добавив сертификат CA в составленный файл сертификата CA в файле конфигурации сервера:

# cat CA1.crt CA2.crt > /etc/openvpn/movpn/ca-stack.pem

Далее используйте следующее в конфигурации сервера:

ca /etc/openvpn/movpn/ca-stack.pem

Таким образом, клиентские сертификаты, подписанные CA1.crt или CA2.crt будут приняты сервером.

Конечно, если это мошенник, пытающийся подключиться, то более подходящим решением может быть черный список IP-адресов, с которых клиент подключается.

Несоответствие сертификата клиента и приватного ключа

Если сертификат и закрытый ключ на клиенте не совпадают, то OpenVPN даже не будет пытаться подключиться к серверу. Вместо этого в файле журнала будет напечатана следующая ошибка:

Cannot load private key file /etc/openvpn/movpn/client1.key:
error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch
Error: private key password verification failed
Exiting due to fatal error

Эта проблема может возникнуть, особенно, когда сертификат и закрытый ключ обновляются; Распространенной ошибкой является использование старого приватного ключа с новым сертификатом.

Как исправить

Убедитесь, что сертификат клиента и приватный ключ совпадают. Удивительно, но для этого не существует простого в использовании инструмента. Чтобы выяснить, принадлежат ли сертификат и закрытый ключ друг другу — мы можем использовать следующие команды и искать разделы modulus:

$ openssl x509 -text -noout -in client1.crt
[…]
  Public Key Algorithm: rsaEncryption
  Public-Key: (2048 bit)
  Modulus:
    00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
    c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
    a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
    de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
    e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
    36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
    bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
    f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
    51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
    a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
    b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
    01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
    41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
    60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
    f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
    ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
    3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
    67:b1

$ openssl rsa -text -noout -in client1.key
Private-Key: (2048 bit)
modulus:
    00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
    c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
    a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
    de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
    e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
    36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
    bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
    f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
    51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
    a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
    b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
    01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
    41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
    60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
    f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
    ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
    3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
    67:b1
[…]

Если мы посмотрим на модуль с открытого ключа (сертификата) и приватного ключа, то увидим что они одинаковы. Таким образом, этот сертификат и приватный ключ принадлежат друг другу.


Подсказка

При сравнении модулей часто достаточно сравнить первые несколько байтов, а затем последние несколько байтов.


Несоответствие ключей auth и tls-auth

Параметры auth и tls-auth используются для аутентификации пакетов канала управления и канала данных с использованием алгоритма подписи HMAC. Значением по умолчанию для алгоритма аутентификации HMAC является SHA1, в котором используются 160-битные ключи. Для опции tls-auth нет значения по умолчанию, так как оно не требуется. Однако этот вариант рекомендуется, поскольку он обеспечивает дополнительный уровень защиты от DDoS-атак.

Если алгоритм аутентификации, указанный в конфигурации клиента и сервера, не совпадает, то сервер не позволит клиенту начать квитирование безопасности TLS. Аналогичным образом, если файлы tls-auth на клиенте и сервере не совпадают или если с обеих сторон указан неверный параметр direction — сервер также не позволит клиенту начать квитирование безопасности TLS.

Обычно в файле конфигурации сервера указывается следующая опция:

tls-auth /etc/openvpn/movpn/ta.key 0

Соответственно, на клиенте у нас есть следующая опция:

tls-auth /etc/openvpn/movpn/ta.key 1

Здесь второй параметр определяет direction из tls-auth для используемых ключей. Этот параметр не обязателен, но он позволяет OpenVPN использовать разные ключи хеширования (или HMAC) для входящего и исходящего трафика. Ключ, используемый на клиенте для подписи исходящего трафика, должен совпадать с ключом, используемым на сервере для проверки входящего трафика, и наоборот.

Если используется неверный файл ключей tls-auth или если направление опущено или указано неверно, в журнале сервера появятся следующие записи:

Authenticate/Decrypt packet error: packet HMAC
    authentication failed
TLS Error: incoming packet authentication failed from
    [AF_INET]<CLIENT-IP>:54377

В то же время, клиент просто попытается подключиться в течение 60 секунд, прежде чем произойдет тайм-аут.

Как исправить

Убедитесь, что используется один и тот же файл tls-auth в файлах конфигурации клиента и сервера. Также убедитесь, что параметр direction указан правильно на обоих концах (если используется вообще).

Если вы все еще не уверены, какие ключи HMAC используются для входящих и исходящих соединений, то можете увеличить детализацию файла журнала, чтобы увидеть фактические ключи, используемые как клиентом, так и сервером. Давайте добавим следующее в файлы конфигурации клиента и сервера:

Теперь обе стороны будут печатать большое количество информации о регистрации при запуске.

Строки для поиска в файле журнала на на стороне сервера:

Outgoing Control Channel Authentication:
    Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
    HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Outgoing Control Channel Authentication:
    HMAC size=20 block_size=20
Incoming Control Channel Authentication:
    Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
    HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Incoming Control Channel Authentication:
    HMAC size=20 block_size=20

Строка HMAC size = 20 соответствует тому, что используется 160-битовое хеширование с помощью SHA1, так как 160 соответстуют как 20 байт.

Если на стороне клиента используются правильный файл tls-auth и параметр direction, мы найдем следующее:

Outgoing Control Channel Authentication:
    Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
    HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Outgoing Control Channel Authentication:
    HMAC size=20 block_size=20
Incoming Control Channel Authentication:
    Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
    HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Incoming Control Channel Authentication:
    HMAC size=20 block_size=20

Ключи аутентификации входящего и исходящего каналов управления зеркально отображаются на клиенте и на сервере, обеспечивая надлежащую аутентификацию TLS.

Несоответствие размера MTU

OpenVPN использует два размера максимальной единицы передачи (MTU):

  • tun-mtu: указывает настройку MTU адаптера tun и указывает максимальный размер каждого пакета внутри VPN-туннеля.
  • link-mtu: указывает максимальный размер каждого пакета вне туннеля. Он включает в себя все биты заполнения, шифрования и аутентификации, но это не фактический размер пакета при передаче по сети. Фактический размер пакета не может быть определен заранее, так как размер каждого пакета может отличаться из-за алгоритмов сжатия и шифрования.

Значение по умолчанию для параметра tun-mtu составляет 1500 байт, что также является размером MTU по умолчанию для адаптера Ethernet. При нормальных обстоятельствах мы можем использовать следующую формулу для вычисления размера link-mtu из размера tun-mtu:

link-mtu = tun-mtu + constant

Здесь constant зависит от используемых параметров конфигурации. Среди параметров конфигурации, которые влияют на эту константу, мы имеем следующие:

  • Варианты сжатия, такие как comp-lzo и comp-noadapt
  • Размер вектора инициализации (IV) параметра шифрования опции cipher
  • Опция fragment, добавляющая дополнительный байт
  • Опция no-replay, которая удаляет байт.

Если мы видим несоответствие предупреждений link-mtu — это обычно указывает на неправильную конфигурацию в других местах наших файлов конфигурации клиента и сервера. Как вы увидите в последующих примерах, несоответствие в link-mtu между клиентом и сервером может происходить довольно часто. Обычно VPN-соединение не будет работать правильно, если имеется несоответствие link-mtu.


Подсказка

Не поддавайтесь искушению исправить само предупреждение link-mtu явно установив его. Сначала исправьте другие предупреждения, которые могли вызвать появление предупреждения link-mtu.


Параметр link-mtu также имеет большое значение при настройке VPN-соединения.

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

Если на стороне сервера указан другой размер MTU по сравнению со стороной клиента, в файлах журнала появится следующее предупреждение:

WARNING: 'link-mtu' is used inconsistently,
    local='link-mtu 1441', remote='link-mtu 1541'
WARNING: 'tun-mtu' is used inconsistently,
    local='tun-mtu 1400', remote='tun-mtu 1500'

Это показывает, что для конфигурации default, издержки link-mtu на самом деле составляют 41 байт. Здесь мы добавили в файл конфигурации клиента:

На этом этапе VPN-соединение будет функционировать. Однако производительность будет ограничена, так как пакеты должны быть фрагментированы и повторно собраны. При такой настройке можно вызвать ошибку, отправив большие пакеты ICMP с установленным флагом not fragment . В Linux/FreeBSD это можно сделать с помощью следующей команды:

$ ping -M do -s 1450 10.200.0.2

В Windows мы используем следующее:

C:> ping -f -l 1450 10.200.0.2

Это приведет к 100-процентной потере пакета для команды ping, а также будет отображаться в файле журнала:

Authenticate/Decrypt packet error:
    packet HMAC authentication failed

Это сообщение об ошибке может сначала показаться странным, но оно вызвано тем, что отправляющая сторона создала и подписала пакет, размер которого превышает 1400 байт. Клиент получает только первые 1400 байтов этого пакета и проверяет подпись, которая терпит неудачу. Затем он отклоняет пакет и распечатывает ошибку.

Как исправить

Убедитесь, что, если вы хотите использовать опцию tun-mtu — она указана в файлах конфигурации клиента и сервера.

Несоответствие шифра

Шифр кодирования, который используется для канала данных OpenVPN, можно указать, используя следующую опцию со значением по умолчанию BF-CBC:

Если в файле конфигурации клиента указан другой шифр, чем в файле конфигурации сервера, то в файлах журнала с обеих сторон будет напечатано предупреждающее сообщение, но VPN-соединение будет установлено. Однако, как только любой трафик проходит по нему, он не сможет расшифровать. Мы можем видеть это в следующем фрагменте из файла журнала на стороне клиента:

WARNING: 'link-mtu' is used inconsistently,
    local='link-mtu 1557', remote='link-mtu 1541'
WARNING: 'cipher' is used inconsistently,
    local='cipher AES-256-CBC', remote='cipher BF-CBC'
WARNING: 'keysize' is used inconsistently,
    local='keysize 256', remote='keysize 128'
[Mastering OpenVPN Server] Peer Connection Initiated
    with [AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbi/nip link set dev tun0 up mtu 1500
/sbi/nip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
Authenticate/Decrypt packet error: cipher final failed

Три напечатанных предупреждения изначально показывают как другой тип, так и другой размер используемого шифра. Шифр Blowfish по умолчанию использует 128-битную стойкость, тогда как AES-256 — 256-битную стойкость, что приводит к немного большему зашифрованному пакету (link-mtu 1541 байт для Blowfish по сравнению с link-mtu 1557 байт для AES-256).

Как исправить

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


Заметка

В настоящее время невозможно передать шифр с сервера на клиент. Это в списке пожеланий разработчиков OpenVPN, но оно оказывает существенное влияние на код. Он не будет добавлено в OpenVPN до версии 2.4 или даже 2.5.

Несоответствие компрессии

OpenVPN имеет возможность сжимать весь VPN-трафик на лету. Для определенных типов трафика, таких как обычный веб-трафик, это может повысить производительность VPN, но добавляет дополнительные издержки к протоколу VPN. Для несжимаемого трафика эта опция фактически немного снижает производительность.

Параметр, используемый для указания сжатия в настоящее время, выглядит следующим образом:

comp-lzo [no|yes|adaptive]

Обратите внимание, что нам не нужно указывать второй параметр. Значение по умолчанию является адаптивным, если используется сжатие.

Как мы узнаем в Главе 10, Будущие направления , этот вариант будет заменен более общим вариантом compression, что позволит различные механизмы сжатия.

Можно передать опцию compression с сервера на клиент, но только если опция сжатия была указана в самом файле конфигурации клиента. Если файл конфигурации клиента не содержит такой опции, VPN-соединение не будет установлено. В файле журнала клиента будет показано следующее:

UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
WARNING: 'link-mtu' is used inconsistently,
    local='link-mtu 1541', remote='link-mtu 1542'
WARNING: 'comp-lzo' is present in remote config but
    missing in local config, remote='comp-lzo'
[Mastering OpenVPN Server] Peer Connection Initiated with
    [AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)

Файл журнала сервера будет содержать те же сообщения WARNING, а также будет отображать предупреждения распаковки:

client3/<CLIENT-IP>:45113 Bad LZO decompression header byte: 42

Заметка

Странно, но верно: если мы будем ждать достаточно долго, клиент будет перезагружен из-за ошибок сжатия и попытается восстановить соединение. На этот раз, однако, соединение будет успешным, так как опция comp-lzo все еще находится в памяти.


Как исправить

Убедитесь, что, если вы хотите использовать сжатие, опция comp-lzo указана в файлах конфигурации клиента и сервера. С опцией comp-lzo в файле конфигурации на стороне клиента мы теперь можем контролировать тип сжатия, используемый на стороне сервера, используя опцию push. Используйте следующее:

comp-lzo no
push "comp-lzo no"

Это отключит сжатие, но, к сожалению, это не то же самое, что вообще не указывать какой-либо метод сжатия. Надеемся, что это будет решено в будущем выпуске.

Несоответствие фрагмента

Одним из наиболее часто используемых параметров настройки является опция fragment. Подробнее об этой опции вы узнаете в разделе Как оптимизировать производительность с помощью ping и iperf далее в этой главе.

Как и параметр comp-lzo, параметр fragment указывать не нужно ни с одной стороны. Однако мы не можем указать его только с одной стороны; он должен быть настроен на обоих. Если он указан только с одной стороны, то также должен быть указан и с другой. Технически говоря, даже нет необходимости использовать одно и то же значение для параметра fragment с обеих сторон, но это рекомендуется.

Если опция fragment не указана на стороне клиента, но используется на стороне сервера, то VPN-соединение не будет работать должным образом, как видно из журнала клиента:

WARNING: 'link-mtu' is used inconsistently,
  local='link-mtu 1541', remote='link-mtu 1545'
WARNING: 'mtu-dynamic' is present in remote config but
  missing in local config, remote='mtu-dynamic'
[Mastering OpenVPN Server] Peer Connection Initiated with
  [AF_INET]194.171.96.101:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)

Опять же, это будет выглядеть так, как будто VPN подключился (Initialization sequence completed), но файл журнала заполнится сообщениями об ошибках с code=22 .

Обратите внимание, что в предупреждении фактически указан mtu-dynamic, который является устаревшим названием этой функции.

Как исправить

Убедитесь, что, если вы хотите использовать параметр fragment — он указывается в файлах конфигурации клиента и сервера.

Обратите внимание, что, в отличие от опции comp-lzo, эту функцию нельзя передать с сервера на клиент.

Несоответствие tun и tap

Наиболее распространенный вариант использования сети в стиле tap — это мостовая установка, как мы узнали из Главы 6 , Режим клиент /сервер с помощью tap-устройств. Однако не все устройства поддерживают сеть в стиле tap. В частности, все устройства Android и iOS не имеют этой возможности. Следовательно, если мы подключим такое устройство к серверу OpenVPN в стиле tap, в файле журнала сервера будут перечислены предупреждения от этих клиентов:

<CLIENT-IP>:39959 WARNING: 'dev-type' is used inconsistently,
    local='dev-type tap', remote='dev-type tun'
<CLIENT-IP>:39959 WARNING: 'link-mtu' is used inconsistently,
    local='link-mtu 1573', remote='link-mtu 1541'
<CLIENT-IP>:39959 WARNING: 'tun-mtu' is used inconsistently,
    local='tun-mtu 1532', remote='tun-mtu 1500'

Помимо этих предупреждений сервер не обнаружит ничего о подключающихся клиентах. На клиенте аналогичные предупреждения будут перечислены вместе с этим:

WARNING: Since you are using --dev tun with a point-to-point
topology, the second argument to --ifconfig must be an IP address.
You are using something (255.255.255.0) that looks more like a
netmask. (silence this warning with --ifconfig-nowarn)

Так как мы не можем передать топологию подсети в настройке стиля tap, клиент возвращается к сети по умолчанию в стиле Net30. Этот тип сети по своей сути несовместим с сетью в стиле tap, но, кроме этого, клиент не выдает никаких предупреждений или ошибок.

Даже если бы мы (ошибочно) добавили topology subnet для подавления этого предупреждения на клиенте, VPN все равно не работал бы правильно.

Как исправить

Убедитесь, что с обеих сторон используется один и тот же тип сети (tun или tap). Если вам необходимо использовать устройства Android или iOS — вы должны настроить конфигурацию сервера в стиле tun, так как эти операционные системы не поддерживают сеть в стиле tap.

Проблемы с client-config-dir

В Главе 4, Режим клиент/сервер с TUN устройствами, мы узнали о CCD-файлах и их использование в разделе Специфичная для клиента конфигурация — файлы CCD. Файлы CCD обычно используются для подключения клиентской локальной сети к сети сервера с помощью оператора iroute.

Опыт работы со списками рассылки и форумами OpenVPN показал, что опция client-config-dir подвержена ошибкам и неправильной настройке. Вот три основные причины этого:

  • Файл CCD или каталог, в котором он находится, не может быть прочитан OpenVPN после переключения на safe пользователя, такого как nobody.
  • Опция client-config-dir указана без абсолютного пути.
  • Имя файла CCD указано неверно. Обычно имя файла CCD совпадает с именем из поля /CN= сертификата клиента, без части /CN= и без какого-либо расширения!

При нормальном уровне журнала OpenVPN не жалуется, если не может найти или прочитать файл CCD. Он просто обрабатывает входящее соединение как стандартное соединение, и, таким образом, требуемый оператор iroute никогда не достигается.

Самый простой способ отладки — это временно добавить дополнительную опцию в конфигурацию сервера:

Перезагрузите сервер и клиент попытается восстановить соединение. Если сервер не может прочитать соответствующий файл CCD для подключающегося клиента — он откажет в доступе. Если это произойдет — мы знаем, что файл CCD не был прочитан. Если клиент может подключиться, то возникает другая проблема — скорее всего, проблема маршрутизации.

Другой способ увидеть что сервер OpenVPN делает с файлами CCD — это повысить уровень журнала до 4 и повторно подключить клиента, для которого указан файл CCD. Содержимое этого CCD-файла для клиента с сертификатом /CN=client1 выглядит следующим образом:

ifconfig-push 10.200.0.99 255.255.255.0
iroute 192.168.4.0 255.255.255.0

Это дает команду серверу OpenVPN назначить IP-адрес VPN 10.200.0.99 для этого клиента и для маршрутизации подсети 192.168.4.0./24 через него. Файл журнала сервера теперь содержит следующее:

<CLIENT-IP>:38876 [client1] Peer Connection Initiated with
[AF_INET]<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 OPTIONS IMPORT: reading client specific
options from: /etc/openvpn/movpn/clients/client1
client1/<CLIENT-IP>:38876 MULTI: Learn: 10.200.0.99 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: primary virtual IP for
client1/<CLIENT-IP>:38876: 10.200.0.99
client1/<CLIENT-IP>:38876 MULTI: internal route 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: Learn: 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876

Если выделенная строка отсутствует, то файл CCD не читается. Также следующие строки, начинающиеся с MULTI: показывают как сервер OpenVPN интерпретирует строки, найденные в файле CCD. Это может быть важно для дальнейшей отладки любых вопросов iroute.

Как исправить

Если процесс сервера не может прочитать файл CCD — проверьте права доступа к полному пути к файлу, включая все подкаталоги, ведущие к нему. Убедитесь, что пользователь, указанный в параметре user, имеет разрешение на чтение всех каталогов и самого файла CCD.

Убедитесь, что в опции client-config-dir указан абсолютный путь вместо относительного. Кроме того, если мы используем опцию chroot (подробности см. в man), убедитесь, что директория client-config-dir видна внутри chroot-jail.

Используйте опцию ccd-exclusive чтобы быстро определить, может ли OpenVPN читать файл CCD. Если это возможно, то увеличьте уровень журнала на стороне сервера, чтобы увидеть, как OpenVPN интерпретирует операторы, найденные в файле CCD.

Нет доступа к устройству tun в Linux

Если OpenVPN запускается с недостаточными привилегиями или если OpenVPN настроен на удаление привилегий root и переключение на другой userid (например, nobody), то доступ к устройству tun может быть потерян. Это также может произойти, если OpenVPN используется в виртуализированной среде, такой как OpenVZ или Virtual Private Server (VPS).

Если OpenVPN запущен с недостаточными привилегиями — VPN-соединение вообще не будет установлено:

UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
[Mastering OpenVPN Server] Peer Connection Initiated with
    [AF_INET]<SERVER-IP>:1194
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
    (errno=1)
Exiting due to fatal error

Проверьте userid или используйте sudo для переключения на привилегированного пользователя перед запуском OpenVPN.

Наиболее распространенный сценарий, когда доступны недостаточные привилегии, происходит после автоматического перезапуска VPN-подключения. Рассмотрим следующий файл конфигурации клиента:

client
proto udp
remote openvpnserver.example.com
port 1194
dev tun
nobind

remote-cert-tls server
tls-auth  /etc/openvpn/movpn/ta.key 1
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/client3.crt
key       /etc/openvpn/movpn/client3.key

user nobody
group nobody

Это базовый файл конфигурации с двумя строками внизу. Когда мы запускаем VPN-соединение с помощью этого файла конфигурации, соединение устанавливается правильно, но выводится предупреждение:

WARNING: you are using user/group/chroot/setcon without persist-tun
-- this may cause restarts to fail

Действительно, после перезапуска VPN-соединения (например, из-за плохого сетевого соединения) перезапуск не удастся:

[Mastering OpenVPN Server] Inactivity timeout (--ping-restart), restarting
Mon Jun 1 16:51:50 2015 sbinip addr del dev tun0 10.200.0.2/24
RTNETLINK answers: Operation not permitted
Linux ip addr del failed: external program exited with error status: 2
SIGUSR1[soft,ping-restart] received, process restarting
WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Error: private key password verification failed
Exiting due to fatal error

Здесь мы видим, что OpenVPN не удалось перезапустить, так как пользователю nobody не разрешили прочитать приватный ключ, который использовался для этого соединения. Если бы мы указали пользователя с правами доступа, мы бы увидели другую ошибку:

ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
    (errno=1)
Exiting due to fatal error

Обратите внимание, что во время перезапуска OpenVPN не может завершить работу существующего устройства tun или удалить любые системные маршруты. Это также будет иметь место, если используется persist-tun, но в этом случае он будет безвредным.

Как исправить

Добавьте следующие параметры в файл конфигурации клиента, если вы также используете параметры user и/или group:

Убедитесь, что вы запускаете OpenVPN с достаточными привилегиями.

Также убедитесь, что OpenVPN имеет правильный контекст безопасности SELinux, или попробуйте запустить OpenVPN с SELinux, установленным в разрешающий или отключенный режим:

# setenforcing permissive

Отсутствие повышенных привилегий в Windows

В некоторых старых версиях программы установки OpenVPN для Windows не были заданы правильные привилегии для приложения OpenVPN GUI.

В этом конкретном примере один сервер был передан с сервера OpenVPN всем клиентам:

push "route 192.168.122.0 255.255.255.0"

В Windows Vista и выше OpenVPN требуются повышенные привилегии чтобы иметь возможность добавлять или удалять системные маршруты. Если эти привилегии отсутствуют, VPN обычно инициализируется правильно, а значок GUI становится зеленым:

Мы даже можем пропинговать сервер OpenVPN по IP-адресу его VPN-сервера. Тем не менее, файл журнала в OpenVPN GUI покажет некоторые ошибки:

Первая строка на самом деле хитрая:

Warning: cannot open -log file: .....: Access is denied

Сложность в том, что как только мы нажимаем кнопку Disconnect — журнал исчезает, так как он не может быть записан на диск! Это вызвано тем, что каталог журналов по умолчанию C:\Program FilesOpenVPNlog доступен только пользователю с повышенными привилегиями.

Последние несколько строк в файле журнала говорят нам, что OpenVPN не удалось добавить маршрут, который был передан сервером. Опять же, это связано с тем, что программа OpenVPN была запущена с недостаточными привилегиями.

Как исправить

После перезапуска OpenVPN GUI с повышенными правами (включите Запуск от имени администратора) маршрут будет добавлен правильно. Это видно из таблицы маршрутизации:

Переданный маршрут — 192.168.122.0/24 , теперь присутствует в таблице маршрутизации, используя IP-адрес VPN сервера 10.200.0.1 в качестве шлюза.

Устранение проблем с маршрутизацией

Большинство вопросов, задаваемых в списках рассылки OpenVPN и форумах пользователей, на самом деле являются вопросами маршрутизации. Настройка VPN-соединения — это одно, а интеграция в существующую сеть — совсем другое. Для новичка трудная часть состоит в том, чтобы видеть, где заканчивается OpenVPN и где начинается маршрутизация. Этот раздел предназначен в качестве пошагового руководства по устранению неполадок маршрутизации в довольно простой настройке OpenVPN.

Рассмотрим следующий план сети:

  • Сеть в главном офисе должна быть доступна для дополнительного офиса и для людей, работающих из дома
  • Серверы в дополнительном офисе должны быть доступны для IT-отдела главного офиса
  • Люди, работающие из дома, должны иметь доступ только к компьютерным ресурсам в главном офисе

Для этого в главном офисе устанавливается сервер OpenVPN, сотрудники которого подключаются как обычные клиенты VPN, а дополнительный офис подключается как специальный клиент, раскрывая свою собственную сеть.

Рисование детальной картины

Перед созданием файлов конфигурации для OpenVPN нарисуйте подробное изображение схемы сети, включая все подсети, IP-адреса, IP-адреса шлюза, имена интерфейсов и многое другое.

Используемые публичные IP-адреса не перечислены на этом рисунке, но это рекомендуется сделать. Кроме того, подключения от людей, работающих из дома, не включены, но они будут подключаться к общедоступному IP-адресу gateway1 на предыдущем рисунке.

На gateway1 добавлено правило переадресации портов, поэтому входящий и исходящий трафик UDP через порт 1194 перенаправляется на сервер OpenVPN в 172.31.1.2:1194.

Поскольку нам необходимо раскрыть сеть в дополнительном офисе, нам также потребуется использовать файл client-config-dir с соответствующим оператором iroute.

Файлы конфигурации сервера и клиента для этой настройки уже перечислены в Главе 4, Режим клиент/сервер с tun-устройствами, с некоторыми незначительными изменениями IP-адреса. Новый набор файлов конфигурации выглядит следующим образом:

proto udp
port 1194
dev tun

server 10.200.0.0 255.255.255.0

tls-auth  /etc/openvpn/movpn/ta.key 0
dh        /etc/openvpn/movpn/dh2048.pem
ca        /etc/openvpn/movpn/movpn-ca.crt
cert      /etc/openvpn/movpn/server.crt
key       /etc/openvpn/movpn/server.key

persist-key
persist-tun
keepalive 10 60

topology subnet

user nobody
group nobody

verb 3
daemon
log-append /var/log/openvpn.log

push "route 172.31.1.0 255.255.255.0"
client-config-dir /etc/openvpn/movpn/clients
route 192.168.3.0 255.255.255.0 10.200.0.1

Этот файл сохраняется как movpn-09-01-server.conf. Для клиента OpenVPN в дополнительном офисе создается специальный сертификат с именем /CN=SecondaryOffice. Соответствующий файл CCD, следовательно, имеет имя /etc/openvpn/movpn/clients/SecondaryOffice. Его содержание таково:

ifconfig-push 10.200.0.200 255.255.255.0
iroute 192.168.3.0 255.255.255.0

Для всех клиентов может быть использован конфигурационный файл basic-udp-client.conf или basic-udp-client.ovpn. Это, кстати, показывает гибкость конфигурационных файлов OpenVPN. В большинстве случаев нет необходимости изменять файлы конфигурации клиента, даже если макет сети на стороне сервера был изменен или в VPN была добавлена ​​вторичная сеть.

Затем мы запускаем сервер OpenVPN и клиент вторичного офиса и проверяем что файл CCD выбран. Клиент VPN на вторичном офисе может пинговать сервер OpenVPN на его VPN IP-адрес и поэтому может тест пользователь дома.


Заметка

На данный момент VPN работает, а маршрутизация — нет.


Начните с середины и двигайтесь наружу

Наиболее эффективный способ устранения неполадок в этой настройке состоит в том, чтобы рассматривать канал VPN как середину, а затем постепенно выполнять пошаговую работу до тех пор, пока все части сети не будут подключены. Во-первых, есть несколько тестов для выполнения на клиенте OpenVPN в дополнительном офисе. Почти для всех тестов достаточно простой команды ping.

Обратите внимание, что нет смысла переходить ко второму тесту, если первый не пройден, и, аналогично к третьему, если второй еще не работает:

  • Может ли клиент достичь IP-адреса VPN сервера?
    Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на сервере. IP-адрес VPN-сервера должен быть приватным (как правило RFC1918) и, следовательно, не будет маршрутизируемым через общий Интернет.

  • Может ли клиент получить доступ к IP-адресу сервера в локальной сети?
    Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила или попробуйте отключить правила брандмауэра для отладки.

  • Может ли клиент достичь IP-адреса шлюза на стороне сервера?

Если нет, то проверьте ответы на следующие вопросы:

  • На сервере включена переадресация IP?
  • Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа к серверу с определенного диапазона IP-адресов?
  • Существует ли на межсетевом шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить на разрешение трафика, поступающего с VPN IP 10.200.0.0/24.
  • Есть ли обратный маршрут на шлюзе, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом назначения в диапазоне 10.200.0.0/24 следует пересылать на сервер OpenVPN по IP 172.31.1.2 на маршрутизаторе gateway1. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора.
  • Может ли клиент связаться с другим сервером в локальной сети на стороне сервера?

Если нет, то проверьте ответы на следующие вопросы:

  • Имеет ли этот сервер в локальной сети на стороне сервера правильный шлюз в качестве шлюза по умолчанию?
  • Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)

Убедившись, что клиент может получить доступ ко всем машинам в локальной сети на стороне сервера — пришло время убедиться что обратное также верно. Убедитесь, что сервер OpenVPN может получить доступ ко всем машинам в локальной сети за вторичным клиентом. Тесты для выполнения очень похожи:

  • Может ли сервер достичь IP-адреса VPN клиента?

Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на клиенте. Тем не менее, на данный момент это вряд ли будет проблемой. Но лучше перестраховаться, чем потом жалеть, так что давайте проверим это.

  • Может ли сервер получить доступ к IP-адресу локальной сети клиента?

Если это не работает, то, скорее всего, существует правило брандмауэра/iptables, которое блокирует доступ. Проверьте входящие правила.

  • Может ли сервер достичь IP-адреса шлюза на стороне клиента?

Если нет, то проверьте ответы на следующие вопросы:

  • Включена ли переадресация IP на клиенте вторичного офиса?
    Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте из определенного диапазона IP-адресов?
  • Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов не из локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо отрегулировать так, чтобы трафик приходил с VPN IP 10.200.0.1.
  • Есть ли обратный маршрут на шлюзе во вторичном офисе, чтобы сообщить ему, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника 10.200.0.1 должны быть перенаправлены клиенту OpenVPN по IP 192.168.3.17 на маршрутизаторе gateway2. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора. Также обратите внимание, что мы разрешаем проходить только пакетам с самого сервера OpenVPN, так как все остальные клиенты не требуют доступа к его сети.

  • Может ли сервер OpenVPN подключиться к другому компьютеру в локальной сети на стороне клиента?

Если нет, то проверьте ответы на следующие вопросы:

  • Имеет ли этот сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
  • Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)

На этом этапе клиент OpenVPN в дополнительном офисе должен иметь доступ ко всем машинам в локальной сети на стороне сервера, а сервер OpenVPN в главном офисе должен иметь доступ ко всем машинам в локальной сети на стороне клиента. Есть только еще один шаг: убедитесь, что серверы в локальной сети на стороне сервера могут обращаться к серверам в локальной сети на стороне клиента и наоборот. Опять же, нужно выполнить четыре теста, начиная с компьютера в локальной сети на стороне сервера:

  • Может ли эта машина достичь IP-адреса VPN клиента OpenVPN?

Это должно сработать, так как клиент может добраться до этой машины в результате четвертого теста. Однако лучше перестраховаться, чем сожалеть, так что давайте проверим это.

  • Может ли эта машина получить доступ к IP-адресу локальной сети клиента?

Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила на клиенте OpenVPN. Может ли сервер локальной сети достичь IP-адреса шлюза на стороне клиента?

Если нет, то проверьте ответы на следующие вопросы:

  • Включена ли переадресация IP на клиенте вторичного офиса? Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте для определенного диапазона IP-адресов? Обратите внимание, что пакеты, поступающие с компьютера в локальной сети на стороне сервера, будут иметь адрес источника (172.31.1.X), отличный от адреса самого сервера OpenVPN (10.200.0.1).
  • Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети 172.31.1.0/24. Точно так же может потребоваться добавить правило брандмауэра на шлюзе на стороне сервера, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети 192.168.3.0/24 на стороне клиента.
  • Есть ли обратный маршрут на шлюзе во вторичном офисе, для сообщения ему куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника 172.31.1.0/24 должен быть перенаправлен клиенту OpenVPN по IP 192.168.3.17 на маршрутизаторе gateway2. Обратите внимание, что это обычно не так.

  • Может ли сервер на стороне сервера подключиться к другому компьютеру на стороне клиента?

Если нет, то проверьте ответы на следующие вопросы:

  • Имеет ли сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
  • Существует ли на клиентском компьютере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)

Методично прорабатывая все эти шаги, мы можем решить практически все проблемы маршрутизации. В некоторых случаях могут потребоваться более продвинутые методы отладки. Это может потребовать от нас временно отключить правила брандмауэра, поэтому перед попыткой сделать это следует соблюдать особую осторожность.

Найдите время, чтобы временно отключить брандмауэр

В списках рассылки OpenVPN было слишком много случаев, когда люди не могли заставить маршрутизацию работать, и это оказалось слишком ограничительным правилом брандмауэра или iptables. Нет необходимости отключать все правила брандмауэра, но если вы застряли на одном из двенадцати шагов, перечисленных ранее, то попробуйте отключить брандмауэр, связанный с устройством, которое вы не можете достичь или с которого вы отправляете трафик.


Заметка

Если вам нужно использовать настройку NATted, убедитесь, что вы не отключаете правила NATting.


Если ничего не помогает, используйте tcpdump

Низкоуровневый сетевой инструмент tcpdump — отличный инструмент для проверки подключения. Для устранения проблем с маршрутизацией мы можем использовать tcpdump, чтобы увидеть, поступает ли какой-либо трафик в конкретный сетевой интерфейс или покидает его, и мы можем проверить адреса источника и назначения этого трафика. На клиенте или сервере Windows может быть проще запустить Wireshark (http://www.wireshark.org), который предоставляет аналогичные функции, включая графический интерфейс.

В двенадцати шагах, перечисленных ранее, могут помочь следующие операторы tcpdump:

  1. Запустите tcpdump -nnel -i tun0 на сервере, чтобы увидеть, поступает ли вообще какой-либо трафик через VPN.
  2. Запустите tcpdump -nnel -i eth0 на сервере (где eth0 — интерфейс локальной сети используемого сервера), чтобы увидеть, поступает ли вообще какой-либо трафик на интерфейс локальной сети. Если нет, то, скорее всего, правило брандмауэра отбрасывает входящий трафик на туннельном интерфейсе.
  3. Запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс LAN с помощью следующего:
source address      = 10.200.0.200
destination address = 172.31.1.254

Также проверьте, видим ли мы обратный трафик от серверного шлюза с обратными адресами отправителя и получателя.

  1. Снова запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс локальной сети со следующими заголовками пакетов:
source address      = 10.200.0.200
destination address = 172.31.1.XXX

Здесь 172.31.1.XXX — это IP-адрес компьютера, к которому мы пытаемся подключиться в локальной сети на стороне сервера. Есть ли обратный трафик?

И так далее и так далее для оставшихся шагов!

Как оптимизировать производительность с помощью ping и iperf

Получить максимальную производительность из установки OpenVPN может быть сложно. В чистой сети Ethernet стандартные настройки OpenVPN довольно хороши. Однако в гигабитных сетях требуется некоторая настройка.

Когда используется ADSL или кабельное модемное соединение, производительность также обычно довольно хорошая. Однако при определенных обстоятельствах производительность нашего туннеля OpenVPN может значительно отставать от производительности обычной сети. Эти обстоятельства почти всегда зависят от интернет-провайдера, но, тем не менее, стоит изучить как повысить производительность.

Ключом к оптимизации производительности является наличие хороших инструментов для измерения производительности. Два основных, но бесценных инструмента для измерения производительности сети — это ping и iperf. Инструмент iperf легко доступен в Linux, FreeBSD и Mac OS. Есть порты, доступные для Windows и даже Android.

Использование ping

Используя ping мы можем определить оптимальный размер MTU для нашей сети. Большинство сетевых операторов сейчас предоставляют своим клиентам MTU для Ethernet размером 1500 байт. Это приводит к полезной нагрузке пакета в 1472 байта. Остальные 28 байтов являются издержками TCP/IP для таких вещей, как адрес источника и назначения.

Однако если между клиентом и сервером существует сеть с более низким MTU, то это может значительно повысить производительность, уменьшив размер пакетов OpenVPN чуть ниже этого размера. Чтобы определить максимальный размер передачи для нашей сети, мы используем следующее:

$ ping -M do -s 1472 www.example.org

В Windows мы используем следующее:

C:> ping -f -l 1472 www.example.org

Она будет отправлять ICMP-пакеты на удаленный сервер по нашему выбору с установленным флагом not fragment, инструктируя сетевые маршрутизаторы не разбивать этот пакет на более мелкие биты. Если между клиентом и сервером есть сеть с меньшим MTU, то команда ping завершится неудачно:

$ ping -M do -s 1472 www.example.org
PING www.example.org (IP) 1472(1500) bytes of data.

ping: local error: Message too long, mtu=1480

Это говорит нам о том, что производительность будет, скорее всего, лучше, если мы используем либо фрагмент размером 1480, либо размер MTU 1480 байт вместо значения по умолчанию 1500. Обратите внимание, что это не является гарантией — только измерив фактическую производительность VPN, мы узнаем, каково влияние на самом деле.

Использование iperf

Используя iperf мы можем измерить производительность сети как внутри, так и вне VPN-туннеля. Это даст нам ценную информацию о том, сколько пропускной способности мы тратим, используя VPN-туннель.

Прежде чем измерять производительность самого VPN-туннеля, всегда пытайтесь измерить производительность нормальной сети. Будет довольно сложно заставить VPN работать лучше чем базовая сеть.

Сначала запустите iperf на сервере с помощью следующей команды:

Затем запустите iperf на клиенте с помощью следующей команды:

$ iperf -c openvpn.example.org

В кабельной сети, которая использовалась для тестирования, результат выглядит следующим образом:

Это на самом деле скорость загрузки используемого кабельного соединения. Теперь мы можем проверить производительность VPN-туннеля в той же сети:

[ 3] 0.0-10.8 sec 5.25 MBytes 4.09 Mbits/sec

Повторение измерения дает очень похожие цифры, поэтому справедливо утверждать, что производительность VPN-туннеля на несколько процентов ниже производительности базовой сети. Это на самом деле имеет смысл, так как использование VPN действительно создает некоторые накладные расходы для инкапсуляции, шифрования и аутентификации (подписи) исходных данных. Это будет трудно для дальнейшей оптимизации этой сети.

Аналогично, для скорости загрузки используемого кабельного соединения мы обнаруживаем, что производительность VPN-туннеля на несколько процентов ниже:

Производительность базовой сети показана следующим образом:

[ 4]  0.0-10.6 sec  51.6 MBytes 40.7 Mbits/sec

Теперь сравните это с VPN-туннелем:

[ 4]  0.0-10.7 sec  49.5 MBytes 39.0 Mbits/sec

Опять же, мы видим снижение производительности на 4,5 процента.

Теперь мы можем использовать параметры fragment и mssfix, чтобы посмотреть сможем ли мы повысить производительность. Там будет немного проб и ошибок для поиска подходящего места для конкретной установки. Неизвестно, какое именно место будет заранее, но метод его определения всегда один и тот же. Теперь добавьте параметры в файлы конфигурации клиента и сервера:

Делая это и изменяя X, мы получаем следующие результаты:

X (bytes) Download (Mbps) Upload (Mbps)
1200 37.9 3.94
1300 38.1 4.01
1400 38.4 4.04
1472 38.8 4.06
1500 37.6 3.98
39.0 4.09

Мы можем заключить, что настройки OpenVPN по умолчанию — самое приятное место для этой сети. Мы могли бы повторить это упражнение, изменив параметр tun-mtu но мы получили бы тот же результат. Однако рекомендуется сначала настроить производительность с помощью параметра fragment, поскольку этот параметр меньше влияет на пересылку пакетов.

Гигабитная сеть

Теперь мы выполним ту же процедуру в неиспользуемой сети Gigabit Ethernet. Производительность iperf базовой сети составляет 950 Мбит/с вверх и вниз.

Когда мы запускаем сервер OpenVPN с помощью конфигурации basic-udp-server.conf и подключаем к нему клиента с помощью файла конфигурации basic-udp-client.conf, мы достигаем следующей производительности iperf:

[ ID] Interval        Transfer      Bandwidth
[ 5]   0.0-10.0 sec    193 MBytes    161 Mbits/sec
[ 4]   0.0-10.0 sec    242 MBytes    203 Mbits/sec

Сейчас наблюдается явное падение производительности. К сожалению, снижение параметра fragment нам здесь не поможет. С fragment 1200 мы достигаем 149 Мбит/с и 115 Мбит/с соответственно.

В высокоскоростных сетях также имеет смысл поэкспериментировать с шифром кодирования. Оба сервера, используемые в этом примере, способны выполнять быстрые инструкции AES благодаря расширению AES-NI, которое присутствует в процессорах (Xeon E5 2620 с тактовой частотой 2 ГГц и Xeon E5 2643 с тактовой частотой 3,5 ГГц, соответственно). Давайте добавим следующее:

Теперь мы получаем следующий результат:

[ 5]  0.0-10.0 sec  316 MBytes  265 Mbits/sec
[ 4]  0.0-10.0 sec  266 MBytes  223 Mbits/sec

На способном процессоре шифр оказывает большое влияние на производительность. Поскольку OpenVPN является монолитной программой — большое количество ядер не помогает вообще. Тактовая частота процессора является доминирующим фактором. Подключив ноутбук Core i7 с тактовой частотой 3,8 ГГц к серверу Xeon E5-2643 с частотой 3,5 ГГц, мы получаем гораздо более высокую пропускную способность, используя точно такую ​​же конфигурацию:

[ 5]  0.0-10.0 sec  707 MBytes  593 Mbits/sec
[ 4]  0.0-10.0 sec  529 MBytes  443 Mbits/sec

Таким образом, если вы хотите настроить туннель OpenVPN через высокоскоростную сеть, то лучший совет — использовать высокопроизводительные ЦП, которые поддерживают набор инструкций AES-NI. С такой настройкой можно достичь скорости сети более 500 Мбит/с в обоих направлениях.

Анализ трафика OpenVPN с помощью tcpdump

Низкоуровневый сетевой инструмент tcpdump или его аналог Wireshark с графическим интерфейсом является последним средством для устранения неполадок и производительности сети. В этом разделе мы рассмотрим процесс захвата и анализа зашифрованного сетевого трафика, создаваемого OpenVPN.

Сначала мы настраиваем нашу стандартную сеть OpenVPN, используя конфигурационные файлы basic-udp. На клиенте также работает веб-сервер. Мы будем использовать команду wget на стороне сервера, чтобы извлечь файл с веб-сервера, чтобы мы могли посмотреть на полученный сетевой трафик.

Мы запускаем tcpdump на интерфейсе Ethernet и собираем сетевой трафик, выполняя wget вне туннеля:

wget -O /dev/null https://CLIENT-IP/test1

Результирующий вывод tcpdump выглядит следующим образом (для ясности изменен):

Как мы видим, существует 13 пакетов для передачи текстового файла размером 5 КБ. Большинство из этих пакетов были использованы для установки и разрыва соединения, но есть четыре больших пакета, которые были использованы для фактической передачи данных. Первые три из четырех пакетов имеют размер 1514 байт, что является максимальным размером пакета Ethernet.

Далее мы запускаем ту же команду wget внутри туннеля. Теперь мы наблюдаем зашифрованный трафик на адаптере Ethernet:

Здесь мы видим 22 захваченных пакета. Первый и последний два пакета являются heartbeat пакетами OpenVPN и могут игнорироваться. Оставшиеся 18 пакетов являются зашифрованным эквивалентом пакетов, показанных в первом выводе tcpdump. Как мы видим здесь, длина пакета немного меньше, и особенно payload каждого пакета немного меньше: самый большой пакет payload UDP составляет 1445 байтов. Эти 1445 байт содержат зашифрованные и подписанные данные из команды wget. В нашей настройке мы не указали параметр fragment — это означает, что OpenVPN 2.3 по умолчанию будет иметь внутреннюю фрагментацию 1450 байт.

Общий размер каждого пакета никогда не превышает 1487 байтов, что довольно близко к оптимальному: обычно пакеты не должны превышать размер MTU, который составляет 1500 байтов.

Этот дамп экрана tcpdump также показывает что фрагментации не происходит, кроме как внутри OpenVPN. Это хорошо, поскольку мы хотим избежать фрагментации пакетов операционной системой или сетью для максимальной производительности. Если бы мы видели здесь фрагментацию пакетов, то это было бы отличным признаком того, что нам нужно было добавить дополнительную фрагментацию в нашу конфигурацию OpenVPN.

Давайте посмотрим, что произойдет, если мы добавим fragment 1400 в нашу настройку. Мы перезапускаем сервер и клиент и снова запускаем команду wget:

С добавленным в нашу настройку fragment 1400 мы можем видеть в выводе tcpdump что полезная нагрузка пакета теперь составляет 1397 байт, что очень близко к пределу 1400. Мы также видим, что теперь требуется больше пакетов для передачи текстового файла размером 5 КБ по туннелю, что означает снижение производительности. Из этого снимка экрана мы можем сделать вывод, что нам следует снова удалить параметр.

Из предыдущего скриншота и предыдущего мы также можем сделать вывод, что каждый пакет OpenVPN несет 42-байтовые издержки. Эти издержки частично способствуют накладным расходам, возникающим при использовании любого решения VPN. Он включает в себя всю служебную информацию, поскольку все сетевые пакеты должны содержать служебную информацию об адресе источника, адресе назначения, типе пакета, контрольные суммы, флаги и многое другое.

Наконец, давайте посмотрим на содержимое реального зашифрованного пакета OpenVPN. Для этого удобно использовать инструмент Wireshark (http://www.wireshark.org). Wireshark в основном предоставляет графический интерфейс поверх низкоуровневого инструмента tcpdump. Он может декодировать содержимое большинства типов сетевого трафика, как мы можем видеть на следующем снимке экрана (снимок экрана был анонимным по соображениям конфиденциальности):

Этот скриншот говорит нам следующее:

  • Фактический размер пакета составляет 1487 байт.
  • Он содержит заголовки Ethernet и IPv4, как и любой сетевой пакет в сети Ethernet.
  • Это пакет OpenVPN с исходным портом 35400 и портом назначения 1194 — это означает, что он перемещается от клиента к серверу. На самом деле это один из зашифрованных пакетов при передаче файла размером 5 КБ с клиента на сервер.
  • Полезной нагрузкой пакета является пакет данных OpenVPN (формат версии 1) с размером полезной нагрузки 1487 байт. Обратите внимание, что tcpdump сообщил о 1488 байтах ранее, но Wireshark может декодировать полезную нагрузку и увидеть, что первый байт является кодом операции OpenVPN.

Этот пакет будет получен OpenVPN, проверен на аутентификацию, расшифрован и распакован (если мы указали). Полученный незашифрованный пакет затем перенаправляется в таблицы маршрутизации операционной системы, которые решают, куда направить пакет. В нашем случае пакет останется на сервере и будет передан процессу wget.

Резюме

В этой главе вы познакомились с некоторыми основными приемами устранения неполадок и настройки OpenVPN. Вы также получили представление о чтении файлов журналов клиента и сервера. Вы узнали как обнаружить и исправить некоторые из наиболее часто совершаемых ошибок. Большинство вопросов в списке рассылки OpenVPN касаются проблем маршрутизации — поэтому мы обсудили обнаружение и устранение проблем маршрутизации. Наконец, существует большая разница между работающей установкой и хорошо работающей установкой, поэтому мы рассмотрели примеры того, как обнаруживать и решать проблемы с производительностью.

Конечно, OpenVPN не идеален и поэтому ваша нерабочая настройка также может быть вызвана ошибкой в ​​самом OpenVPN. Существует несколько каналов для сообщения об ошибках, включая список электронной почты (openvpn-users@lists.sourceforge.net), канал IRC (#openvpn на freenode.net IRC) и веб-сайт форума (https://forums.openvpn.net). Вы также можете отправлять запросы на функции или списки пожеланий на эти каналы, некоторые из которых могут появиться в будущей версии OpenVPN.

В следующей главе вы узнаете, что нового можно ожидать в следующих выпусках OpenVPN. Вы также узнаете, какие в настоящее время известны проблемы с базой кодов OpenVPN, и узнаете о планах по устранению этих проблем.

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?

proto udp

# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.

dev tun

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh dh2048.pem

# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
;topology subnet

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
push «redirect-gateway def1 bypass-dhcp»

# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
client-to-client

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
tls-auth /etc/openvpn/ta.key 0 # This file is secret

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC

# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 6

# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1

Fixing OpenVPN «Authenticate/Decrypt packet error: cipher final failed»

When connecting to a VPN I was constant getting the error

Mar  8 09:29:27 openvpn[1696]: Authenticate/Decrypt packet error: cipher final failed

I had imported the supplied ovpn file and had followed all the other configuration steps, so this was quite frustrating. Then I saw this in the logs:

Mar  8 09:31:07 openvpn[1790]: WARNING: ‘cipher’ is used inconsistently, local=’cipher BF-CBC’, remote=’cipher AES-256-CBC’

Changing my client to use «cipher AES-256-CBC» instead of the default (which apparently was cipher BF-CBC) fixed the issue.

Popular posts from this blog

MinHash for dummies

Duplicate document detection is becoming increasingly important for businesses that have huge collections of email, web pages and documents with multiple copies that may or may not be kept up to date. MinHash is a fairly simple algorithm that from all my Googling has been explained very poorly in blogs or in the kind of mathematical terms that I forgot long ago. So in this article I will attempt to explain how MinHash works at a practical code level. Before I start, please take a look at  http://infolab.stanford.edu/~ullman/mmds/ch3.pdf . That document goes into a lot of theory, and was ultimately where my understanding on MinHash came from. Unfortunately it approaches the algorithm from a theoretical standpoint, but if I gloss over some aspect of the MinHash algorithm here, you will almost certainly find a fuller explanation in the PDF. I’ll also be using pseudo Java in these examples instead of traditional math. This means when I use terms like Set, I am referring to the gr

Authenticating via Kerberos with Keycloak and Windows 2008 Active Directory

Image

The following instructions show you how to configure Keycloak with Windows AD in order to use Kerberos authentication. Assumptions The Kerberos realm is VIRTUAL.LOCAL The hostname used to access Keycloak is virtual.local. This just means we are running Keycloak on the domain controller. In production virtual.local will be replaced with something like keycloak.dev.virtual.local or something like that, giving you a SPN of  HTTP/keycloak.dev.virtual.local@VIRTUAL.LOCAL Configuration Create a windows domain account called Keycloak. Run the following command to assign a SPN to the user and generate a keytab file: ktpass -out keycloak.keytab -princ HTTP/virtual.local@VIRTUAL.LOCAL -mapUser Keycloak@VIRTUAL.LOCAL -pass password1! -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT Verify the SPN has been assigned to the user with the command: setspn -l Keycloak Configure the LDAP settings in Keycloak like this. Since we are running Keycloak on the domain controller, we ref

While setting up OpenVPN I came accross some common errors or workarounds that make life easier. To make it easier to remember these I have documented them in this blog. Maybe they are useful for others as well.

Remove pass phrase

In case you want to remove the pass phrase from the server key to make it easiert to start the OpenVPN server part, use the following command:

mv server.key server.key.orig
openssl rsa -in server.key.orig -out server.key

You’ll have to enter one more time the pass phrase of the key, and then a new server.key file is written without the pass phrase. You can see this when looking into the key files.

With pass phrase:

Note: file starts with: BEGIN ENCRYPTED PRIVATE KEY

Without pass phrase:

Note: file starts with: BEGIN RSA PRIVATE KEY

Run OpenVPN as a service on Linux

After installing openvpn via yum on AWS AMI Linux, a service script is also installed. How the file works and can be activated is written in the file itself:

more /etc/init.d/openvpn

The file should already be copied by yum to /etc/rc.d/init.d/openvpn

Activate the service

chkconfig

Check whether or not openvpn is already configured to run as a service. For each run level, the status is either on or off. In case of on, openvpn is already configured to run as a service. In this example, opevpn is not configured to run as a service in any runlevel.

sudo chkconfig --add openvpn

sudo chkconfig openvpn on

OpenVPN will now be started as a service in the run levels 2, 3, 4 and 5. Output of openvpn is then written to /var/log/messages

sudo tail -f /var/log/messages

Systemd

To start and control openvpn via systemd. Check status of openvpn.

sudo systemctl status openvpn

Edit service configuration

sudo vim /etc/default/openvpn

Insert the client configuration to start automatically. Here, I am going to start client1.conf:

AUTOSTART=”client1”

Start service

sudo systemctl start openvpn
sudo systemctl status openvpn

Solving common OpenVPN connection error message

Some information on how to solve common OpenVPN error message on the server and client. Most occur when trying to start OpenVPN for the first time.

TA.KEY

Client starts connecting but no connection is established.

Error message

TLS Error: cannot locate HMAC in incoming packet from [AF_INET]

Cause

Server is configured to use ta.key.

Solution

Copy the ta.key into the openvpn configuration directory and specify its location in the conf file.

Cipher final failed

OpenVPN server accepts a client connection, but communication fails.

Error message

Authenticate/Decrypt packet error: cipher final failed

Cause

Server and client are using different algorithms for encryption and decryption. On the server, the log gives more information:

WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'

Solution

Server uses AES-256-CBC, while the client is using BF-CBC. Adjust the client configuration in client.conf. Insert cipher AES-256-CBC in client.conf

Other parameters to adjust

During first startup, some warning message may be written on the server log. Most common they refer to link-mtu, cipher, keysize or comp-lzo.

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1542'
WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

Solution

Adjust the parameters in the client.conf file so that they match the server configuration. Also good to check this way if a not controlled/configured client is connecting to your server.

Link-mtu

Configure the client to use the same mtu size as the server. Insert parameter link-mtu into client.conf.

link-mtu 1557

Keysize

Keysize used by client and server should be the same. Insert parameter keysize into client.conf.

keysize 256

Comp-lzo

Uncomment the parameter in server.conf.

Introduction

OpenVPN is the open source virtual private network software, capable of connecting computers securely across the internet.

Download

Community Downloads

VPN Comparison

PPPTP vs L2TP vs OpenVPN

PPTP vs L2TP vs OpenVPN vs Chameleon

Overview

laptop —> openvpn —> firewall —> server —> openvpn —> files

Modem Settings

OpenVPN requires a port to be opened on DSL/broadband modem.

Default Port: 1195 UDP

OpenVPN 2.0 HOWTO

This has nice notes and examples.

http://www.imped.net/oss/misc/openvpn-2.0-howto-edit.html

HOWTO: INSTALL:

AUTOMATED

sudo -i
curl -O https://raw.githubusercontent.com/angristan/openvpn-install/master/openvpn-install.sh
bash openvpn-install.sh

MANUAL

Ubuntu & Debian Linux

Where <version> can be one of

  • stable: stable releases only — no alphas, betas or RCs
  • testing: latest releases, including alphas/betas/RCs
  • release/2.3: OpenvPN 2.3 releases
  • release/2.4: OpenVPN 2.4 releases, including alphas/betas/RCs

and <osrelease> depends your distribution:

  • wheezy (Debian 7.x)
  • jessie (Debian 8.x)
  • precise (Ubuntu 12.04)
  • trusty (Ubuntu 14.04)
  • xenial (Ubuntu 16.04)
  • beaver (Ubuntu 18.04)
  • focal (Ubuntu 20.04)
sudo -i
sudo wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg | sudo apt-key add -
sudo echo "deb http://build.openvpn.net/debian/openvpn/stable focal main" > /etc/apt/sources.list.d/openvpn-aptrepo.list
sudo apt-get update && sudo apt-get install openvpn easy-rsa

https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos

https://help.ubuntu.com/community/OpenVPN

Raspberry Pi

http://readwrite.com/2014/04/10/raspberry-pi-vpn-tutorial-server-secure-web-browsing

Gentoo Linux

Add the local portage file:

** UPDATE **

Version 2.1.3 is now in the Portage tree. Do not use the method below.

Skip the to section Installing the software:

The latest version available in the official Gentoo portage tree is 2.1.0, however the latest community version of OpenVPN is 2.1.1

Download the latest version custom ebuild and install it as follows:-

su - root
echo "PORTDIR_OVERLAY="/usr/local/portage"" >> /etc/make.conf
mkdir -p /usr/local/portage/net-misc/openvpn
cd /usr/local/portage/net-misc/openvpn/
wget http://www.paully.co.uk/openvpn-2.1.1.ebuild

Download OpenVPN Community Version 2.1.1 custom Gentoo Linux ebuild by Paul Littlefield
openvpn-2.1.1.ebuild 2010-05-12

Copy the important files directory:

cp -av /usr/portage/net-misc/openvpn/files /usr/local/portage/net-misc/openvpn/

Create the portage manifest file:

cd /usr/local/portage/net-misc/openvpn/
ebuild openvpn-2.1.1.ebuild digest

Update the EIX portage cache:

eix-update

Allow beta software:

echo "net-misc/openvpn ~amd64" >> /etc/portage/package.keywords

Install the software:

You will need to make sure that the minimal USE flag is not set, and that the examples and ssl USE flags are set.

echo "net-misc/openvpn -minimal examples ssl" >> /etc/portage/package.use

Then test the software.

emerge -pv openvpn

Then install the software.

emerge openvpn

SSL keys / certificates:

Change to the directory with the OpenVPN scripts to set up the keys.

cd /usr/share/openvpn/easy-rsa/

Or

cd /usr/share/easy-rsa/

Then, edit the basic parameters for the certificates. Edit the vars file and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don’t leave any of these parameters blank.

nano vars

export KEY_COUNTRY="UK"
export KEY_PROVINCE="Kent"
export KEY_CITY="Canterbury"
export KEY_ORG="My Company"
export KEY_EMAIL="me@mycompany.com"

Next, initialize the PKI.

source ./vars
./clean-all
./build-ca

The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive openssl command:

Generating a 1024 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) [UK]:
State or Province Name (full name) [Kent]:
Locality Name (eg, city) [Folkestone]:
Organization Name (eg, company) [Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [Company Ltd CA]:server1.company.com
Name []:
Email Address [myname@company.com]:

Note that in the above sequence, most queried parameters were defaulted to the values set in the vars or vars.bat files. The only parameter which must be explicitly entered is the Common Name. In the example above, I used «server1.company.com».

Generate certificate & key for server

Next, we will generate a certificate and private key for the server.

./build-key-server server

As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter «server». When asked for a challenge password, leave it blank and hit Enter. Two other queries require positive responses, «Sign the certificate? [y/n]» and «1 out of 1 certificate requests certified, commit? [y/n]».

Generating client certificates is very similar to the previous step. On Linux/BSD/Unix:

./build-key-pass client1

Remember that for each client, make sure to type the appropriate Common Name when prompted, i.e. «client1», «client2», or «client3». Always use a unique common name for each client.

Generate Diffie Hellman parameters

Diffie Hellman parameters must be generated for the OpenVPN server.

./build-dh

Server Configuration:

This is for a Gentoo Linux server with 2 network interface cards, acting as as gateway / firewall / file share…

ip addr show

 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host 
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether e0:cb:4e:3a:da:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
    inet6 fe80::e2cb:4eff:fe3a:daa4/64 scope link 
 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:50:bf:10:05:6e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
    inet6 fe80::250:bfff:fe10:56e/64 scope link 
 4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.1.1 peer 192.168.1.2/32 scope global tun0
12: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.2.1 peer 192.168.2.2/32 scope global tun1

Create a directory for your ‘named’ VPN, e.g ‘vpn’…

mkdir /etc/openvpn/vpn

Copy the keys and certificates from the previous steps into the new directory…

rsync -av /usr/share/openvpn/easy-rsa/keys/* /etc/openvpn/vpn/

Routing:

Method A:

We will try the simpler method of a ‘routed ip tunnel’.

OK, create the first VPN server configuration file…

nano /etc/openvpn/openvpn.conf
port 1194
proto udp
dev tun
ca /etc/openvpn/vpn/ca.crt
cert /etc/openvpn/vpn/server.crt
key /etc/openvpn/vpn/server.key
dh /etc/openvpn/vpn/dh1024.pem
server 192.168.1.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/vpn/ipp.txt
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 3
log /var/log/openvpn.log

Now create the second VPN server configuration file…

nano /etc/openvpn/openvpn2.conf

port 1195
proto udp
dev tun
ca /etc/openvpn/vpn/ca.crt
cert /etc/openvpn/vpn/server.crt
key /etc/openvpn/vpn/server.key
dh /etc/openvpn/vpn/dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/vpn/ipp.txt
push "route 172.20.0.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 3
log /var/log/openvpn2.log

Next, create the Gentoo Linux system start-up files…

cd /etc/init.d/
ln -s openvpn openvpn.openvpn2
rc-update add openvpn default
rc-update add openvpn.openvpn2 default

Finally, start the 2 OpenVPN servers…

/etc/init.d/openvpn start
/etc/init.d/openvpn.openvpn2 start

Check that you have both of the new VPN interfaces…

ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.1.1  P-t-P:192.168.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:247206 (241.4 KiB)
ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.2.1  P-t-P:192.168.2.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:3216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3214 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:433830 (423.6 KiB)  TX bytes:607390 (593.1 KiB)

Your log file should look like this…

tail /var/log/openvpn.log
Fri May 21 14:02:51 2010 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on May 14 2010
Fri May 21 14:02:51 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri May 21 14:02:51 2010 Diffie-Hellman initialized with 1024 bit key
Fri May 21 14:02:51 2010 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri May 21 14:02:51 2010 ROUTE default_gateway=10.0.0.2
Fri May 21 14:02:51 2010 TUN/TAP device tun1 opened
Fri May 21 14:02:51 2010 TUN/TAP TX queue length set to 100
Fri May 21 14:02:51 2010 /sbin/ifconfig tun1 192.168.2.1 pointopoint 192.168.2.2 mtu 1500
Fri May 21 14:02:51 2010 /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.2
Fri May 21 14:02:51 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri May 21 14:02:51 2010 GID set to nogroup
Fri May 21 14:02:51 2010 UID set to nobody
Fri May 21 14:02:51 2010 Socket Buffers: R=[112640->131072] S=[112640->131072]
Fri May 21 14:02:51 2010 UDPv4 link local (bound): [undef]:1195
Fri May 21 14:02:51 2010 UDPv4 link remote: [undef]
Fri May 21 14:02:51 2010 MULTI: multi_init called, r=256 v=256
Fri May 21 14:02:51 2010 IFCONFIG POOL: base=192.168.2.4 size=62
Fri May 21 14:02:51 2010 IFCONFIG POOL LIST
Fri May 21 14:02:51 2010 Initialization Sequence Completed

Method B: Bridged

to be done

Shoreline Firewall / Shorewall Configuration:

We would like to allow staff on the road (Roadwarriors  :) access to the files on their server in the office. Our server acts as a gateway and firewall using 2 network interface cards (eth0 and eth1)

Internet <—> [123.456.789.0 Modem 10.0.0.2] <—> [10.0.0.1 Firewall | Server 192.168.0.1] <—> [Network]

http://www.shorewall.net/OPENVPN.html#RoadWarrior

IMPORTANT — If the roadwarrior uses a hotel WiFI, you have to allow for both ends of the tunnel to be the same IP address range. This ROUTING config will take care of that  :-)

[192.168.0.x roadwarrior] <— VPN —> [server 192.168.0.x]

Edit the Shorewall config files, adding the lines shown in bold below:-

/etc/shorewall/zones
###############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4
loc     ipv4
vpn     ipv4
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/interfaces 
###############################################################################
#ZONE   INTERFACE       BROADCAST       OPTIONS
net     eth0            detect          routefilter,tcpflags
loc     eth1            detect          dhcp,tcpflags
vpn     tun+
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/tunnels
###############################################################################
#TYPE                   ZONE    GATEWAY         GATEWAY
#                                               ZONE
openvpnserver:1194      net     0.0.0.0/0
openvpnserver:1195      net     0.0.0.0/0
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/policy
###############################################################################
#SOURCE         DEST    POLICY          LOG     LIMIT:          CONNLIMIT:
#                                       LEVEL   BURST           MASK
loc             net     ACCEPT
loc             fw      ACCEPT
fw              net     ACCEPT
fw              loc     ACCEPT
vpn             loc     ACCEPT
loc             vpn     ACCEPT
vpn             fw      ACCEPT
fw              vpn     ACCEPT
net             all     DROP            info
# THE FOLLOWING POLICY MUST BE LAST
all             all     REJECT          info
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/netmap
##############################################################################
#TYPE   NET1                    INTERFACE       NET2
SNAT    192.168.0.0/24          tun+            172.20.0.0/24
DNAT    172.20.0.0/24           tun+            192.168.0.0/24  
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Check your firewall configuration, and correct any errors.

shorewall check

Then restart.

/etc/init.d/shorewall restart

ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input

Make sure CONFIG_IP_NF_TARGET_NETMAP is set.

Thanks to Gentoo Wiki.

Quick and Dirty Gentoo Linux Install

This will install OpenVPN just for 1 client with a simple secret file instead of keys.

http://briancarper.net/blog/243/

Client Configuration

This will install OpenVPN so that the client can use it anywhere — even if both networks at each end of the VPN tunnel share the same IP address range.

Microsoft Windows

OpenVPN Client Connect For Windows

https://www.sparklabs.com/viscosity/download/

NOTE: The following examples are for Windows 7 64-bit, the file paths for 32-bit systems are slightly different — C:Program Files (x86).

As Administrator

Install the latest OpenVPN Community Edition Microsoft Windows software from here, then reboot.

Copy the example config file (C:Program FilesOpenVPNconfig-samplesclient.ovpn) into the actual config folder (C:Program FilesOpenVPNconfig) as something like ‘office.ovpn’ or ‘server.ovpn’

Edit the file adding the following lines of the new .ovpn file:

# Site details
remote server1.myoffice.com 1195

# Windows tweaks
route-method exe
route-delay 2

# Prevent caching of password in Windows
auth-nocache

The 1195 is important, because you will be connecting to the second OpenVPN server which then passes the requests for data through the firewall by cool network mapping to the first openvpn server  :-)

Copy the necessary client key files (ca.crt, client.crt, client.key) which have been generated from the server (as shown above) to the C:Program FilesOpenVPNconfig folder.

Follow this guide to have OpenVPN run as a privileged user, this saves following the steps in the As User section below.

As User

Right-click on the OpenVPN GUI shortcut icon, and choose Run as Administrator. Put in the Windows Administrator password and click OK.

Right-click on the little OpenVPN icon on the task bar near the clock, and choose Connect.

With any luck you see the connect log whizz buy and it will show Connected.

Then you can do a quick ping test…

ping 172.20.0.x    (the last number in the IP address of your server)

Then you can do a share test…

net view \172.20.0.x

Then you can launch Windows Explorer and put the following in the address bar…

\172.20.0.xshared   (or whatever your Samba share is called)

Thanks to Surfbouncer.

Linux

Install the package…

emerge openvpn

Create the directory for the VPN files…

mkdir -p /etc/openvpn/domain.co.uk

Copy the client and server files to that directory…

server1.ovpn
client1.key
client1.crt
ca.crt

Load the tun module…

modprobe tun

Start the client…

cd /etc/openvpn/domain.co.uk
openvpn server1.ovpn

Android

OpenVPN Connect

https://play.google.com/store/apps/details?id=net.openvpn.openvpn

OpenVPN Connect does not like X509 Certificates with the standard DSA encryption, so you have to change this to DES encryption before it will work and prompt you for the private key password…

cd /etc/openvpn/vpn/
openssl rsa -in client1.key -out client1_unencrypted.key
openssl rsa -in client1_unencrypted.key -des3 -out client1_DES.key
rm client1.key 
mv client1_unencrypted.key 
rm client1_unencrypted.key 
mv client1_DES.key client1.key

Then transfer the following 4 files to your MicroSD card / directory…

ca.crt
client1.crt
client1.key
server.ovpn

Start OpenVPN Connect > Menu > Import > Import Profile from SD card > Choose server.ovpn

Type in your Private Key password but do not tick Save.

You will now connect to the VPN and Android will show a notification near the clock.

You can now use an app like X-Plore File Manager to connect to the LAN Samba server or email app.

FAQS

https://forums.openvpn.net/topic14432.html

HELP

http://wiki.hidemyass.com/Tutorials:OpenVPN_Connect_on_Android

TROUBLESHOOTING

If you receive an error saying «cannot acquire tun interface», then you need to install the TUN module into your kernel.

TUN.ko Installer

https://play.google.com/store/apps/details?id=com.aed.tun.installer

Apple

NEW

https://www.sparklabs.com/viscosity/download/

https://tunnelblick.net/cUsingTunnelblick.html#the-first-time-tunnelblick-is-run-on-a-computer

OLD

https://forums.openvpn.net/post30830.html#p30830

OpenVPN Connect iTunes App

OpenVPN Setup on an iPad

OpenVPN Setup on an iPad

HOWTO: FIX:

TAP Driver Problems

TAP install failing

Managing Windows TAP Drivers

Authenticate/Decrypt packet error: cipher final failed

You have to exactly match the cipher’s used at both ends of the VPN tunnel because of new security rules.

Default…

cipher BF-CBC

New…

cipher AES-128-CBC

Thanks — http://matthewcasperson.blogspot.co.uk/2015/03/fixing-openvpn-authenticatedecrypt.html

FIX 1

If you are not running an ‘Administrator’ profile, then you need to ensure that the User Account Control (UAC) is enabled.

Thanks to PersonalVPN.

FIX 2 (POSSIBLE)

If you are running OpenVPN under Home Editions of Vista in a ‘Standard User’ profile its permissions need to be set to allow it to run.

Log on in an administrator profile

Open Windows Explorer and navigate to the Program Files folder, locate and right-click on the OpenVPN folder and select ‘Properties’ from the shell menu.

Select the ‘Security’ tab and click the ‘Edit’ button.

On the next window click the ‘Add’ button

On the next window click the ‘Advanced’ button

On the next window click the ‘Find’ button

Under the search results click once on the user you want to add and then click the ‘OK’ buttons through to the window which reads ‘Permissions for OpenVPN’

In the top box click on the user just added and in the permissions box below select the check box next to ‘Full Control’ in the ‘Allow’ column

Other possibles

Windows 7 Setup

http://forums.openvpn.net/topic9972.html

2FA

https://duo.com/docs/openvpn

https://community.duo.com/t/2fa-openvpn-for-linux-error-auth-received-control-message-auth-failed/10196/

HOWTO: Change The Passphrase On An OpenVPN Key

OpenVPN keys are generated using openssl and can be edited using the openssl command.

To change the passphrase on the key use openssl to write out a new key and move it into place.

openssl rsa -des3 -in /etc/openvpn/vpn/client.key -out /etc/openvpn/vpn/client-new.key
mv /etc/openvpn/vpn/client-new.key /etc/openvpn/vpn/client.key

To remove the passphrase all together, leave -des3 out of the openssl command.

openssl rsa -in /etc/openvpn/vpn/client.key -out /etc/openvpn/vpn/client-new.key
mv /etc/openvpn/vpn/client-new.key /etc/openvpn/vpn/client.key

Thanks — http://www.linuxsysadmintutorials.com/change-the-passphrase-on-an-openvpn-key/

http://bit.ly/1yIXtcb

HOWTO: Check the OpenVPN UDP Port Is Open

Use netcat to check the connection worked…

netcat -z -v -u vpn.mydomain.com 1194
Connection to vpn.mydomain.com 1194 port [udp/openvpn] succeeded!

Check it is alive…

sudo nmap -sP -Pn server.domain.co.uk

Scan the port…

sudo nmap -sU -Pn server.domain.co.uk -p 1194

Check Server Certificate Date

openssl x509 -noout -text -in ca.crt

Check Client Certificate

openssl verify -CAfile ca.crt client.crt

client.crt: OK
error 10 at 1 depth lookup:certificate has expired

Start OpenVPN Automatically

https://www.ovpn.com/en/blog/windows-run-openvpn-automatically-on-computer-startup

Help and Troubleshooting

OpenVPN Forum — Scripts and Customisations (iptables)

Advanced Usage

Pi-Hole + VPN

OpenVPN 2 Cookbook

100 simple and incredibly effective recipes for harnessing the power of the OpenVPN 2 network

  • Set of recipes covering the whole range of tasks for working with OpenVPN
  • The quickest way to solve your OpenVPN problems!
  • Set up, configure, troubleshoot and tune OpenVPN
  • Uncover advanced features of OpenVPN and even some undocumented options

Introduction

The topic of this article is troubleshooting OpenVPN. This article will focus on troubleshooting OpenVPN misconfigurations.

The recipes in this article will therefore deal first with breaking the things. We will then provide the tools on how to find and solve the configuration errors. Some of the configuration directives used in this article have not been demonstrated before, so even if you are not interested in breaking things this article will still be insightful.

Cipher mismatches

In this recipe, we will change the cryptographic ciphers that OpenVPN uses. Initially, we will change the cipher only on the client side, which will cause the initialization of the VPN connection to fail. The primary purpose of this recipe is to show the error messages that appear, not to explore the different types of ciphers that OpenVPN supports.

Getting ready

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Set up the client and server certificates. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (download code, ch:2) and the client configuration file basic-udp-client.conf at hand.

How to do it…

  1. Start the server using the configuration file basic-udp-server.conf:

    [[email protected]]# openvpn –config basic-udp-server.conf

    
    
  2. Next, create the client configuration file by appending a line to the basic-udp-client.conf file:

    cipher CAST5-CBC

    
    

    Save it as example7-1-client.conf.

  3. Start the client, after which the following message will appear in the client log:

    [[email protected]]# openvpn –config example7-1-client.conf
    … WARNING: ‘cipher’ is used inconsistently, local=’cipher CAST5-
    CBC’, remote=’cipher BF-CBC’
    … [openvpnserver] Peer Connection Initiated with server-ip:1194
    … TUN/TAP device tun0 opened
    … /sbin/ip link set dev tun0 up mtu 1500
    … /sbin/ip addr add dev tun0 192.168.200.2/24 broadcast
    192.168.200.255
    … Initialization Sequence Completed
    … Authenticate/Decrypt packet error: cipher final failed

    
    
  4. And, similarly, on the server side:

    … client-ip:52461 WARNING: ‘cipher’ is used inconsistently,
    local=’cipher BF-CBC’, remote=’cipher CAST5-CBC’
    … client-ip:52461 [openvpnclient1] Peer Connection Initiated
    with openvpnclient1:52461
    … openvpnclient1/client-ip:52461 Authenticate/Decrypt packet
    error: cipher final failed
    … openvpnclient1/client-ip:52461 Authenticate/Decrypt packet
    error: cipher final failed

    
    

The connection will not be successfully established, but it will also not be disconnected immediately.

How it works…

During the connection phase, the client and the server negotiate several parameters needed to secure the connection. One of the most important parameters in this phase is the encryption cipher, which is used to encrypt and decrypt all the messages. If the client and server are using different ciphers, then they are simply not capable of talking to each other.

By adding the following configuration directive to the server configuration file, the client and the server can communicate again:

cipher CAST5-CBC


There’s more…

OpenVPN supports quite a few ciphers, although support for some of the ciphers is still experimental. To view the list of supported ciphers, type:

$ openvpn –show-ciphers


This will list all ciphers with both variables and fixed cipher length. The ciphers with variable cipher length are very well supported by OpenVPN, the others can sometimes lead to unpredictable results.

TUN versus TAP mismatches

A common mistake when setting up a VPN based on OpenVPN is the type of adapter that is used. If the server is configured to use a TUN-style network but a client is configured to use a TAP-style interface, then the VPN connection will fail. In this recipe, we will show what is typically seen when this common configuration error is made.

Getting ready

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Set up the client and server certificates (Download code-ch:2 here). For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.confat hand.

How to do it…

  1. Start the server using the configuration file basic-udp-server.conf:

    [[email protected]]# openvpn –config basic-udp-server.conf

    
    
  2. Next, create the client configuration:

    client
    proto udp
    remote openvpnserver.example.com
    port 1194
    dev tap
    nobind
    ca /etc/openvpn/cookbook/ca.crt
    cert /etc/openvpn/cookbook/client1.crt
    key /etc/openvpn/cookbook/client1.key
    tls-auth /etc/openvpn/cookbook/ta.key 1
    ns-cert-type server

    
    

    Save it as example7-2-client.conf.

  3. Start the client

    [[email protected]]# openvpn –config example7-2-client.conf

    
    

    The client log will show:

    … WARNING: ‘dev-type’ is used inconsistently, local=’dev-type
    tap’, remote=’dev-type tun’
    … WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu
    1573′, remote=’link-mtu 1541′
    … WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1532′,
    remote=’tun-mtu 1500′
    … [openvpnserver] Peer Connection Initiated with server-ip:1194
    … TUN/TAP device tap0 opened
    … /sbin/ip link set dev tap0 up mtu 1500
    … /sbin/ip addr add dev tap0 192.168.200.2/24 broadcast
    192.168.200.255
    … Initialization Sequence Completed

    
    

    At this point, you can try pinging the server, but it will respond with an error:

    [client]$ ping 192.168.200.1
    PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
    From 192.168.200.2 icmp_seq=2 Destination Host Unreachable
    From 192.168.200.2 icmp_seq=3 Destination Host Unreachable
    From 192.168.200.2 icmp_seq=4 Destination Host Unreachable

    
    

How it works…

A TUN-style interface offers a point-to-point connection over which only TCP/IP traffic can be tunneled. A TAP-style interface offers the equivalent of an Ethernet interface that includes extra headers. This allows a user to tunnel other types of traffic over the interface. When the client and the server are misconfigured, the expected packet size is different:

… WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1532′,
remote=’tun-mtu 1500′


This shows that each packet that is sent through a TAP-style interface is 32 bytes larger than the packets sent through a TUN-style interface.

By correcting the client configuration, this problem is resolved.

Compression mismatches

OpenVPN supports on-the-fly compression of the traffic that is sent over the VPN tunnel. This can improve the performance over a slow network line, but it does add a little overhead. When transferring uncompressible data (such as ZIP files), the performance actually decreases slightly.

If the compression is enabled on the server but not on the client, then the VPN connection will fail.

Getting ready

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Set up the client and server certificates. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.confat hand..

How to do it…

  1. Append a line to the server configuration file basic-udp-server.conf:

    comp-lzo

    
    

    Save it as example7-3-server.conf.

  2. Start the server:

    [[email protected]]# openvpn –config example7-3-server.conf

    
    
  3. Next, start the client:

    [[email protected]]# openvpn –config basic-udp-client.conf

    
    

    The connection will initiate but when data is sent over the VPN connection, the following messages will appear:

    Initialization Sequence Completed
    … write to TUN/TAP : Invalid argument (code=22)
    … write to TUN/TAP : Invalid argument (code=22)

    
    

How it works…

During the connection phase, no compression is used to transfer information between the client and the server. One of the parameters that is negotiated is the use of compression for the actual VPN payload. If there is a configuration mismatch between the client and the server, then both the sides will get confused by the traffic that the other side is sending.

With a network fully comprising OpenVPN 2.1 clients and an OpenVPN 2.1 server, this can be fixed for all the clients by just adding another line:

push “comp-lzo”


There’s more…

OpenVPN 2.0 did not have the ability to push compression directives to the clients. This means that an OpenVPN 2.0 server does not understand this directive, nor do OpenVPN 2.0 clients. So, if an OpenVPN 2.1 server pushes out this directive to an OpenVPN 2.0 client, the connection will fail.

Key mismatches

OpenVPN offers extra protection for its TLS control channel in the form of HMAC keys. These keys are exactly the same as the static “secret” keys used in point-to-point style networks. For multi-client style networks, this extra protection can be enabled using the tls-auth directive . If there is a mismatch between the client and the server related to this tls-auth key , then the VPN connection will fail to get initialized.

Getting ready

Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Set up the client and server certificates using the first recipe. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf (Download code-ch:2 here) and the client configuration file basic-udp-client.conf at hand.

How to do it…

  1. Start the server using the configuration file basic-udp-server.conf:

    [[email protected]]# openvpn –config basic-udp-server.conf

    
    
  2. Next, create the client configuration:

    client
    proto udp
    remote openvpnserver
    port 1194
    dev tun
    nobind

    ca /etc/openvpn/cookbook/ca.crt
    cert /etc/openvpn/cookbook/client1.crt
    key /etc/openvpn/cookbook/client1.key
    tls-auth /etc/openvpn/cookbook/ta.key

    ns-cert-type server

    
    

    Note the lack of the second parameter for tls-auth. Save it as example7-4-client.conf file.

  3. Start the client:

    [[email protected]]# openvpn –config example7-4-client.conf

    
    

    The client log will show no errors, but the connection will not be established either. In the server log we’ll find:

    … Initialization Sequence Completed
    … Authenticate/Decrypt packet error: packet HMAC authentication
    failed
    … TLS Error: incoming packet authentication failed from client-
    ip:54454

    
    

This shows that the client openvpnclient1 is connecting using the wrong tls-auth parameter and the connection is refused.

How it works…

At the very first phase of the connection initialization, the client and the server verify each other’s HMAC keys. If an HMAC key is not configured correctly, then the initialization is aborted and the connection will fail to establish. As the OpenVPN server is not able to determine whether the client is simply misconfigured or whether a malicious client is trying to overload the server, the connection is simply dropped. This causes the client to keep listening for the traffic from the server, until it eventually times out.

In this recipe, the misconfiguration consisted of the missing parameter 1 behind:

tls-auth /etc/openvpn/cookbook/ta.key


The second parameter to the tls-auth directive is the direction of the key. Normally, the following convention is used:

  • 0: from server to client
  • 1: from client to server

This parameter causes OpenVPN to derive its HMAC keys from a different part of the ta.key file. If the client and server disagree on which parts the HMAC keys are derived from, the connection cannot be established. Similarly, when the client and server are deriving the HMAC keys from different ta.key files, the connection can also not be established.

Yesterday I installed Debian 9 and OpenVPN on a server at home and everything was working flawlessly (I followed this guide). However, this morning, OpenVPN was working (client side) and suddenly nothing was loading anymore. I tried reconnecting to the VPN and it worked for 5 or 10 minutes and then nothing.

I did a few researches and I checked the status of the OpenVPN server with the command systemctl status openvpn@server and I saw the message:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

Again, I looked up this error on internet but nothing solved the problem. In the mean time, 2 other errors came up:

TLS Error: local/remote TLS keys are out of sync

and

Authenticate/Decrypt packet error: cipher final failed

It seems obvious that this has something to do with TLS right? I have the file ta.key generated with openvpn --genkey --secret ta.key in both /etc/openvpn/ on the server and in the config folder on the client (windows).


I tried disabling ufw but it doesn’t solve the problem so I doubt it is a firewall thing. Here is the result of ufw status anyway:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
1194/udp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
1194/udp (v6)              ALLOW       Anywhere (v6)

Here’s what I added to /etc/ufw/before.rules:

*nat
:POSTROUTING ACCEPT [0.0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

The server.conf (without comments):

port 1194
proto udp4
dev tun
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
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 82.196.9.45"
push "dhcp-option DNS 89.46.223.237"

keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

And finally the client.ovpn (without comments and certificates):

client
dev tun
proto udp4
remote [server-ip] 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

<ca>
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----
</ca>

<cert>
Certificate:
    (...)
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
(...)
-----END PRIVATE KEY-----
</key>

Any suggestions are welcomed, thank you!

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Openvpn authenticate decrypt packet error bad packet id may be a replay
  • Openvpn android transport error
  • Openvpn android tls error
  • Openvpn an error occurred installing the tap device driver windows 10
  • Openvpn agent request error

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии