Как самому быстро и просто исправить ошибки VPN подключения
Как исправить ошибку VPN с кодами 31/87/720/13843
Следуйте этим простым 5 шагам, чтобы исправить ошибку подключения ВПН за несколько минут:
Шаг первый: Откройте ‘Диспетчер Устройств’
Шаг второй: Найдите и откройте ‘Сетевые адапторы’
Шаг третий: Теперь удалите все адаптеры с названием ‘WAN Miniport drivers’ (IKEv2, L2TP, IP, IPv6, и т.д.)
Шаг четвертый: Кликните на иконку ‘Обновить конфигурации оборудования’
Шаг пятый: Подождите пока сканирование закончится – адаптеры, которые вы только что удалили, автоматически переустановятся.
Вот и все! Все, что теперь остается сделать это вернутся к Bright VPN и нажать подключится. Ошибки подключения VPN с кодами 31/87/720/13843 теперь должны быть полностью устранены.
Посмотрите это краткое пошаговое видеоруководство (на английском языке):
Как исправить ошибку VPN с кодами 633/756
Если вы столкнулись с кодами ошибок VPN:
- ошибка VPN подключения 633
- ошибка VPN подключения 756
Следуйте этим простым 4 шагам, чтобы исправить ошибку подключения ВПН за несколько минут:
Шаг первый: Откройте ‘Командную строку (cmd)’
Шаг второй: Введите команду ‘rasdial / disconnect’
Шаг третий: Нажмите ‘Enter’
Шаг четвертый: Откройте ‘Диспетчер Задач’ (сочетание клавиш ‘ctrl+alt+end’) и завершите оба эти процесса: ‘Bright VPN’ и ‘Rasdial’
Вот и все! Все, что теперь остается сделать это вернутся к Bright VPN и нажать подключится. Ошибки подключения VPN с кодами 633/756 теперь должны быть полностью устранены. Если по какой-то причине вы все еще видите код ошибки, перезагрузите компьютер, а затем вернитесь к Bright VPN.
Посмотрите это краткое пошаговое видеоруководство (на английском языке):
Как исправить ошибку VPN с кодами 13801/13849
Если вы столкнулись с кодами ошибок VPN:
- ошибка VPN подключения 13801
- ошибка VPN подключения 13849
Вы должны знать, что эти ошибки обычно возникают, когда рассматриваемый «клиент» не доверяет «сертификату», установленному на его «VPN-сервере». Чтобы решить эти проблемы, необходимо убедиться, что у «клиента» установлены все необходимые «корневые» и «промежуточные сертификаты центра сертификации (ЦС)» в соответствующих «хранилищах сертификатов». Устранение неполадок обычно должно начинаться с обновления вашей «ОС (Windows)» или с «установки» рассматриваемого «отсутствующего сертификата». Последнее можно сделать, выполнив следующие 9 простых шагов:
Шаг первый: Перейдите на страницу «Сертификаты Sectigo»
Шаг второй: Продолжайте прокручивать вниз, пока не дойдете до раздела под названием ‘Root Certificates section’
Шаг третий: Запустите процесс, щелкнув ссылку для загрузки, которая появляется рядом с «SHA-2 Root: USERTrust RSA Certificate Authority».
Шаг четвертый: перейдите к загрузке «сертификата»
Шаг пятый: Теперь откройте загруженный «сертификат».
Шаг шестой: нажмите кнопку с надписью «установить сертификат».
Шаг седьмой: когда появится окно приветствия, сначала выберите «Расположение магазина: локальный компьютер», а затем нажмите «Далее».
Шаг восьмой: Теперь выберите параметр «Автоматически выбирать хранилище сертификатов», а затем нажмите «Далее».
Шаг девятый: Теперь нажмите «Готово».
Вот и все! Все, что теперь остается сделать это вернутся к Bright VPN и нажать подключится. Ошибки подключения VPN с кодами 633/756 теперь должны быть полностью устранены. Если по какой-то причине вы все еще видите код ошибки, перезагрузите компьютер, а затем вернитесь к Bright VPN.
Посмотрите это краткое пошаговое видеоруководство (на английском языке):
Как исправить ошибку VPN с кодом 1931
Если вы когда-либо сталкивались с кодом ошибки VPN 1931, вы должны знать, что это обычно происходит, когда «службы IPS» отключены или вообще не работают.
Выполните следующие 4 простых шага, чтобы устранить проблему за считанные минуты:
Шаг первый: сначала нажмите кнопку «Пуск».
Шаг второй: в строке поиска введите «Службы» и нажмите «Enter».
Шаг 3. В окне «Службы» в столбце «Имя» найдите модули ключей IPsec для обмена ключами в интернете, а также «служба агента политики IPsec».
Шаг четвертый: убедитесь, что все вышеперечисленное «Включено», «Работает» и установлено на «Автоматический запуск».
Вот и все! Все, что теперь остается сделать это вернутся к Bright VPN и нажать подключится. Ошибка подключения VPN с кодом 1931 теперь должна быть полностью устранена. Если по какой-то причине вы все еще видите код ошибки, перезагрузите компьютер, а затем вернитесь к Bright VPN.
Посмотрите это краткое пошаговое видеоруководство (на английском языке):
Почему Bright VPN — правильный выбор для вас?
Во-первых, Bright VPN предлагает лучшую в отрасли техническую поддержку пользователей, особенно при возникновении ошибки. У вас всегда будет на кого положиться, когда вы столкнетесь с проблемами в режиме реального времени, это совершенно бесплатно.
Во-вторых, Bright VPN обеспечивает дополнительный уровень безопасности, гарантируя, что любые личные контакты, сообщения или финансовая информация находятся в безопасности и не могут быть просмотрены нежелательными третьими лицами (в основном с помощью метода сквозного шифрования, называемого «туннелированием»).
В-третьих, Bright VPN поддерживает широкий спектр стран, поэтому вы можете просматривать Интернет без каких-либо ограничений.
В-четвертых, Bright VPN обладает самой высокой степенью анонимизации, — чтобы начать пользоваться сервисом не требуется никаких личных данных и даже электронной почты, а сам сервис следует строжайшей политике «отсутствия журналов (логов)»
Ну а самое главное – это абсолютно бесплатный сервис, с неограниченым доступом, высокой скоростью и миллионами IP-адресов по всему миру.
Konstantin Markov
Недавно появилась задача настроить SSTP VPN на базе роутера MikroTik 951Ui 2HnD таким образом, чтобы к нему мог подключаться другой роутер MicroTik2 750 GL, а так же чтобы могли подключаться «одиночные» клиенты с рабочих станций.
Туннель между двумя роутерами был мной настроен ранее, в этом ни чего сложного нет, все подробно описано в базе знаний Mikrotik(на этой же странице описан процесс настройки сервера с возможностью подключения «одиночных» пользователей). По скольку на тот момент не стоял вопрос о подключении «одиночных» пользователей, то сертификаты я не создавал и подключение было настроено без них. Когда же появилась необходимость подключения таких пользователей, стало очевидно, что нужно генерировать и устанавливать сертификаты. Этот процесс так же подробно описан в базе знаний.
Для большей наглядности я нашел в Интернете видео , где настраивается соединение между двумя роутерами с использованием сертификатов. Подобным образом я сгенерировал сертификаты у себя, экспортировал их и установил на «клиентский» роутер. Туннель между роутерами после этого поднялся без проблем.
Сложности начались при настройки клиентского подключения в Windows. Может быть я плохо искал, но в Интернете не очень много описаний того, как настраивать клиентское SSTP подключение на Windows. Первым делом учетной записи компьютера нужно установить корневой и клиентский сертификаты. Затем создать новое клиентское подключение, в настройках задать его тип(SSTP), протокол шифрования(я оставил только mschap2), адрес сервера, куда будет подключаться клиент(внешний IP-адрес роутера, где настроен SSTP-сервер), ввести логин и пароль пользователя. После всего этого я попробовал подключиться, но получил ошибку 0x80070320. В базе знаний MikroTik на странице, где описан процесс настройки SSTP-сервера, сказано, что чтобы этой ошибки не появлялось, нужно на сервере отключить пункт verify-client-certificate. После этого при подключении стала появляться ошибка 0x800B010F «CN имя сертификата не совпадает с полученным значением». В процессе поиска примеров настройки в Windows удачного клиентского подключения я нашел вот это видео . На нем при создании сертификата в поле CN прописывается внешний IP-адрес роутера, к которому подключаются(в первом видео туда прописывается название сертификата, аналогично полю Name и я у себя сделал так же). Пришлось по новой перегенерировать и переустанавливать сертификаты. У корневого и серверного сертификата в поле CN я поставил внешний IP адрес роутера, у клиентского сертификата оставил его как раньше. Далее установил эти сертификаты на клиентский роутер и компьютер. Туннель на роутере, как и ранее, поднялся без проблем, подключение с компьютера тоже установилось без проблем.
P.S.:
Позже выяснилось, что для подключения клиента Windows достаточно лишь установки корневого сертификата. Наличие или отсутствие в системе клиентского сертификата на успешность подключения никак не влияет(очевидно в силу того, что в настройках сервера снята галочка в verify-client-certificate).
3 комментария:
спасибо очень помогло проблема решилась на половину в 10 ке все подключается в семерке ругается на цепочку сертификатов и какие то довереные отношения.
Надо сертификат CA устанавливать в хранилище доверенныйх центров сертификации ЛОКАЛЬНОГО КОМПЬЮТЕРА а не пользователя.
Тоже столкнулся с такой проблемой, как вариант решения
— при создании сертификата сервера
— в параметре Common Name, а точнее его подпункте Subject Alt Name
— надо указать все возможные имена и ЙП адреса сервера, начиная от локального ЙП и заканчивая параметром Identity
Тогда Виндовый клиент при подключении к сервиру — верифицирует что ЙП адрес к которому подключается совпадает с тем ЙП \ Именем что есть в сертификате — и пропускает.
Глава 9. Устранение неполадок и настройка
Обычно довольно легко настроить VPN с использованием OpenVPN. Это одна из самых привлекательных функций OpenVPN по сравнению с другими решениями VPN. Однако иногда необходимо устранить неполадки в нерабочей настройке или настроить существующую настройку для повышения производительности.
Устранение неполадок и настройка OpenVPN часто игнорируются. Файлы журнала OpenVPN на стороне клиента и сервера предоставляют много информации, но вы должны знать как их читать. При настройке файлов конфигурации клиента и сервера также допускается довольно много ошибок. В этой главе вы узнаете, как интерпретировать файлы журнала OpenVPN и как обнаруживать и исправлять некоторые из этих распространенных ошибок.
Наконец, существует большая разница между рабочей установкой и установкой, которая работает хорошо. Возможно, ваша установка OpenVPN работает правильно, но пользователи все равно могут жаловаться на низкую производительность. Получение максимальной производительности от установки OpenVPN может показаться черной магией. В этой главе вы узнаете немного этой черной магии.
В этой главе будут рассмотрены следующие темы:
- Как читать файлы журнала
- Исправление распространенных ошибок конфигурации
- Устранение проблем с маршрутизацией
- Как оптимизировать производительность с помощью ping и iperf
- Анализ трафика OpenVPN с использованием tcpdump
Как читать файлы журнала
Поначалу отладка нерабочих настроек может показаться сложной задачей. С чего начать? К счастью, OpenVPN предоставляет отличные средства ведения журналов и отладки. Однако с увеличением степени детализации журналов становится все труднее читать эти файлы журналов. Уровень детализации журнала OpenVPN по умолчанию равен 1 , но рекомендуется установить степень детализации 3 . Это часто дает администратору достаточно информации для обнаружения проблем с настройкой, в то же время сводя к минимуму потери производительности.
Установка детальности на 5 или выше рекомендуется только для целей отладки, так как это сильно повлияет на производительность.
Каждый пример в этой книге до сих пор включал устанку verb 3 . Во-первых, мы рассмотрим файлы журнала клиента и сервера для рабочей настройки с такой детальностью. Важно понимать и, возможно, даже хранить файлы журналов работающего соединения. При попытке найти ошибку в нерабочей настройке, очень полезно сравнивать файлы журнала нерабочего случая с файлами рабочей настройки.
Запустите сервер, используя файл конфигурации по умолчанию basic-udp-server.conf :
Пока не подключайтесь к клиенту. Файл журнала сервера теперь будет содержать следующее:
Метки времени в начале каждой строки были сокращены для ясности.
Давайте посмотрим на этот файл журнала построчно:
- Строки 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 — это волшебная строка, которая сообщает нам, что сервер успешно запущен и инициализация завершена. Сервер теперь готов принимать соединения от входящих клиентов.
Далее мы запускаем клиент и смотрим файл журнала на стороне сервера:
После этого мы также рассмотрим файл журнала на стороне клиента:
Давайте пройдемся по новым записям журнала:
- Строка 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 и 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 , будет отображаться в журналах сервера следующим образом:
Об этом клиенте больше ничего не сообщается, поскольку сервер OpenVPN немедленно отклоняет попытку подключения. Из временных меток в файле журнала мы видим, что клиент увеличивает время задержки между попытками соединения с каждым неудачным соединением. Если в течение 60 секунд соединение не может быть установлено, клиент прервет:
Второй сбой соединения станет очевидным только после того, как соединение будет успешно инициализировано. Для этого мы указываем использование другого кодирующего шифра на одной стороне, но забываем сделать это на другой. В файле журнала клиента теперь будет отображаться следующее:
Таким образом, сначала соединение, кажется, было успешно установлено (строки с 1 по 3), но через 10 секунд шифрование и дешифрование канала данных не удается.
Заметка
Если бы в этом случае использовался графический интерфейс Windows, значок графического интерфейса стал бы зеленым, но сама VPN не работала бы!
Во время инициализации будет сообщено о большинстве проблем конфигурации на стороне сервера или клиента. О проблемах маршрутизации, которые встречаются гораздо чаще, OpenVPN обычно не сообщает. Следовательно, требуются различные методы устранения неполадок.
Исправление распространенных ошибок конфигурации
При настройке конфигурации OpenVPN есть несколько распространенных ошибок, которые легко допустить. Эти ошибки конфигурации можно условно разделить на четыре категории:
- Сертификат (PKI) ошибки и несоответствия
- Несоответствие опций, таких как tun по сравнению с tap , шифрование и сжатие
- Недостаточно прав для запуска OpenVPN
- Ошибки маршрутизации
В этом разделе мы рассмотрим первые три из этих категорий. Ошибки маршрутизации будут обсуждаться позже в этой главе.
Неправильный сертификат CA в конфигурации клиента
Файл конфигурации клиента почти всегда будет содержать три строки, подобные этой:
Эти файлы сертификатов и секретных ключей были созданы в главе 3, PKI и сертификаты и широко используются в последующих главах. Файл CA, однако, не должен указывать центр сертификации, который использовался для подписи файла сертификата клиента. Это должен быть публичный сертификат центра сертификации, который использовался для подписи сертификата сервера. Если сертификат сервера был подписан другим центром сертификации, клиент откажется подключиться к серверу. Это можно увидеть в файле журнала на стороне клиента:
В этом случае ошибки не регистрируются на стороне сервера, так как сертификат клиента считается действительным на сервере.
Единственное, что зарегистрируется на сервере, это:
Это показывает последовательные попытки подключения, которые сделаны клиентом OpenVPN.
Как исправить
Убедитесь, что в файле конфигурации клиента указан правильный файл CA.
Сертификат клиента не распознан сервером
Если сертификат клиента не распознан сервером — сервер откажет в доступе к нему. Это может произойти, если используется неправильный (или мошеннический) клиентский сертификат или если клиентский сертификат был отозван, а опция crl-verify указана в файле конфигурации сервера.
Следующие записи будут отображаться в файле журнала сервера, если неизвестный клиент попытается подключиться к серверу OpenVPN:
Сервер не может проверить сертификат клиента, так как он не распознает сертификат CA, который использовался для его подписи. Поэтому отказывается разрешить этому клиенту подключаться.
На стороне клиента никакие сообщения не печатаются в файле журнала в течение 60 секунд, после чего первоначальное рукопожатие прекращается и делается новая попытка подключения:
Как исправить
Убедитесь, что сертификат клиента распознается сервером. Это можно сделать либо указав соответствующий сертификат CA в файле конфигурации сервера, либо добавив сертификат CA в составленный файл сертификата CA в файле конфигурации сервера:
Далее используйте следующее в конфигурации сервера:
Таким образом, клиентские сертификаты, подписанные CA1.crt или CA2.crt будут приняты сервером.
Конечно, если это мошенник, пытающийся подключиться, то более подходящим решением может быть черный список IP-адресов, с которых клиент подключается.
Несоответствие сертификата клиента и приватного ключа
Если сертификат и закрытый ключ на клиенте не совпадают, то OpenVPN даже не будет пытаться подключиться к серверу. Вместо этого в файле журнала будет напечатана следующая ошибка:
Эта проблема может возникнуть, особенно, когда сертификат и закрытый ключ обновляются; Распространенной ошибкой является использование старого приватного ключа с новым сертификатом.
Как исправить
Убедитесь, что сертификат клиента и приватный ключ совпадают. Удивительно, но для этого не существует простого в использовании инструмента. Чтобы выяснить, принадлежат ли сертификат и закрытый ключ друг другу — мы можем использовать следующие команды и искать разделы modulus :
Если мы посмотрим на модуль с открытого ключа (сертификата) и приватного ключа, то увидим что они одинаковы. Таким образом, этот сертификат и приватный ключ принадлежат друг другу.
Подсказка
При сравнении модулей часто достаточно сравнить первые несколько байтов, а затем последние несколько байтов.
Несоответствие ключей auth и tls-auth
Параметры auth и tls-auth используются для аутентификации пакетов канала управления и канала данных с использованием алгоритма подписи HMAC. Значением по умолчанию для алгоритма аутентификации HMAC является SHA1 , в котором используются 160-битные ключи. Для опции tls-auth нет значения по умолчанию, так как оно не требуется. Однако этот вариант рекомендуется, поскольку он обеспечивает дополнительный уровень защиты от DDoS-атак.
Если алгоритм аутентификации, указанный в конфигурации клиента и сервера, не совпадает, то сервер не позволит клиенту начать квитирование безопасности TLS. Аналогичным образом, если файлы tls-auth на клиенте и сервере не совпадают или если с обеих сторон указан неверный параметр direction — сервер также не позволит клиенту начать квитирование безопасности TLS.
Обычно в файле конфигурации сервера указывается следующая опция:
Соответственно, на клиенте у нас есть следующая опция:
Здесь второй параметр определяет direction из tls-auth для используемых ключей. Этот параметр не обязателен, но он позволяет OpenVPN использовать разные ключи хеширования (или HMAC) для входящего и исходящего трафика. Ключ, используемый на клиенте для подписи исходящего трафика, должен совпадать с ключом, используемым на сервере для проверки входящего трафика, и наоборот.
Если используется неверный файл ключей tls-auth или если направление опущено или указано неверно, в журнале сервера появятся следующие записи:
В то же время, клиент просто попытается подключиться в течение 60 секунд, прежде чем произойдет тайм-аут.
Как исправить
Убедитесь, что используется один и тот же файл tls-auth в файлах конфигурации клиента и сервера. Также убедитесь, что параметр direction указан правильно на обоих концах (если используется вообще).
Если вы все еще не уверены, какие ключи HMAC используются для входящих и исходящих соединений, то можете увеличить детализацию файла журнала, чтобы увидеть фактические ключи, используемые как клиентом, так и сервером. Давайте добавим следующее в файлы конфигурации клиента и сервера:
Теперь обе стороны будут печатать большое количество информации о регистрации при запуске.
Строки для поиска в файле журнала на на стороне сервера:
Строка HMAC size = 20 соответствует тому, что используется 160-битовое хеширование с помощью SHA1, так как 160 соответстуют как 20 байт.
Если на стороне клиента используются правильный файл tls-auth и параметр direction , мы найдем следующее:
Ключи аутентификации входящего и исходящего каналов управления зеркально отображаются на клиенте и на сервере, обеспечивая надлежащую аутентификацию TLS.
Несоответствие размера MTU
OpenVPN использует два размера максимальной единицы передачи (MTU):
- tun-mtu : указывает настройку MTU адаптера tun и указывает максимальный размер каждого пакета внутри VPN-туннеля.
- link-mtu : указывает максимальный размер каждого пакета вне туннеля. Он включает в себя все биты заполнения, шифрования и аутентификации, но это не фактический размер пакета при передаче по сети. Фактический размер пакета не может быть определен заранее, так как размер каждого пакета может отличаться из-за алгоритмов сжатия и шифрования.
Значение по умолчанию для параметра tun-mtu составляет 1500 байт, что также является размером MTU по умолчанию для адаптера Ethernet. При нормальных обстоятельствах мы можем использовать следующую формулу для вычисления размера link-mtu из размера tun-mtu :
Здесь 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 по сравнению со стороной клиента, в файлах журнала появится следующее предупреждение:
Это показывает, что для конфигурации default , издержки link-mtu на самом деле составляют 41 байт. Здесь мы добавили в файл конфигурации клиента:
На этом этапе VPN-соединение будет функционировать. Однако производительность будет ограничена, так как пакеты должны быть фрагментированы и повторно собраны. При такой настройке можно вызвать ошибку, отправив большие пакеты ICMP с установленным флагом not fragment . В Linux/FreeBSD это можно сделать с помощью следующей команды:
В Windows мы используем следующее:
Это приведет к 100-процентной потере пакета для команды ping , а также будет отображаться в файле журнала:
Это сообщение об ошибке может сначала показаться странным, но оно вызвано тем, что отправляющая сторона создала и подписала пакет, размер которого превышает 1400 байт. Клиент получает только первые 1400 байтов этого пакета и проверяет подпись, которая терпит неудачу. Затем он отклоняет пакет и распечатывает ошибку.
Как исправить
Убедитесь, что, если вы хотите использовать опцию tun-mtu — она указана в файлах конфигурации клиента и сервера.
Несоответствие шифра
Шифр кодирования, который используется для канала данных OpenVPN, можно указать, используя следующую опцию со значением по умолчанию BF-CBC :
Если в файле конфигурации клиента указан другой шифр, чем в файле конфигурации сервера, то в файлах журнала с обеих сторон будет напечатано предупреждающее сообщение, но VPN-соединение будет установлено. Однако, как только любой трафик проходит по нему, он не сможет расшифровать. Мы можем видеть это в следующем фрагменте из файла журнала на стороне клиента:
Три напечатанных предупреждения изначально показывают как другой тип, так и другой размер используемого шифра. Шифр Blowfish по умолчанию использует 128-битную стойкость, тогда как AES-256 — 256-битную стойкость, что приводит к немного большему зашифрованному пакету ( link-mtu 1541 байт для Blowfish по сравнению с link-mtu 1557 байт для AES-256).
Как исправить
Убедитесь, что в файлах конфигурации клиента и сервера указан один и тот же шифр. Поскольку файлы журналов клиента и сервера выводят ожидаемый шифр, исправить эту ошибку довольно просто.
Заметка
В настоящее время невозможно передать шифр с сервера на клиент. Это в списке пожеланий разработчиков OpenVPN, но оно оказывает существенное влияние на код. Он не будет добавлено в OpenVPN до версии 2.4 или даже 2.5.
Несоответствие компрессии
OpenVPN имеет возможность сжимать весь VPN-трафик на лету. Для определенных типов трафика, таких как обычный веб-трафик, это может повысить производительность VPN, но добавляет дополнительные издержки к протоколу VPN. Для несжимаемого трафика эта опция фактически немного снижает производительность.
Параметр, используемый для указания сжатия в настоящее время, выглядит следующим образом:
Обратите внимание, что нам не нужно указывать второй параметр. Значение по умолчанию является адаптивным, если используется сжатие.
Как мы узнаем в Главе 10, Будущие направления , этот вариант будет заменен более общим вариантом compression , что позволит различные механизмы сжатия.
Можно передать опцию compression с сервера на клиент, но только если опция сжатия была указана в самом файле конфигурации клиента. Если файл конфигурации клиента не содержит такой опции, VPN-соединение не будет установлено. В файле журнала клиента будет показано следующее:
Файл журнала сервера будет содержать те же сообщения WARNING , а также будет отображать предупреждения распаковки:
Заметка
Странно, но верно: если мы будем ждать достаточно долго, клиент будет перезагружен из-за ошибок сжатия и попытается восстановить соединение. На этот раз, однако, соединение будет успешным, так как опция comp-lzo все еще находится в памяти.
Как исправить
Убедитесь, что, если вы хотите использовать сжатие, опция comp-lzo указана в файлах конфигурации клиента и сервера. С опцией comp-lzo в файле конфигурации на стороне клиента мы теперь можем контролировать тип сжатия, используемый на стороне сервера, используя опцию push . Используйте следующее:
Это отключит сжатие, но, к сожалению, это не то же самое, что вообще не указывать какой-либо метод сжатия. Надеемся, что это будет решено в будущем выпуске.
Несоответствие фрагмента
Одним из наиболее часто используемых параметров настройки является опция fragment . Подробнее об этой опции вы узнаете в разделе Как оптимизировать производительность с помощью ping и iperf далее в этой главе.
Как и параметр comp-lzo , параметр fragment указывать не нужно ни с одной стороны. Однако мы не можем указать его только с одной стороны; он должен быть настроен на обоих. Если он указан только с одной стороны, то также должен быть указан и с другой. Технически говоря, даже нет необходимости использовать одно и то же значение для параметра fragment с обеих сторон, но это рекомендуется.
Если опция fragment не указана на стороне клиента, но используется на стороне сервера, то VPN-соединение не будет работать должным образом, как видно из журнала клиента:
Опять же, это будет выглядеть так, как будто VPN подключился ( Initialization sequence completed ), но файл журнала заполнится сообщениями об ошибках с code=22 .
Обратите внимание, что в предупреждении фактически указан mtu-dynamic , который является устаревшим названием этой функции.
Как исправить
Убедитесь, что, если вы хотите использовать параметр fragment — он указывается в файлах конфигурации клиента и сервера.
Обратите внимание, что, в отличие от опции comp-lzo , эту функцию нельзя передать с сервера на клиент.
Несоответствие tun и tap
Наиболее распространенный вариант использования сети в стиле tap — это мостовая установка, как мы узнали из Главы 6 , Режим клиент /сервер с помощью tap-устройств. Однако не все устройства поддерживают сеть в стиле tap. В частности, все устройства Android и iOS не имеют этой возможности. Следовательно, если мы подключим такое устройство к серверу OpenVPN в стиле tap, в файле журнала сервера будут перечислены предупреждения от этих клиентов:
Помимо этих предупреждений сервер не обнаружит ничего о подключающихся клиентах. На клиенте аналогичные предупреждения будут перечислены вместе с этим:
Так как мы не можем передать топологию подсети в настройке стиля 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 выглядит следующим образом:
Это дает команду серверу OpenVPN назначить IP-адрес VPN 10.200.0.99 для этого клиента и для маршрутизации подсети 192.168.4.0./24 через него. Файл журнала сервера теперь содержит следующее:
Если выделенная строка отсутствует, то файл 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-соединение вообще не будет установлено:
Проверьте userid или используйте sudo для переключения на привилегированного пользователя перед запуском OpenVPN.
Наиболее распространенный сценарий, когда доступны недостаточные привилегии, происходит после автоматического перезапуска VPN-подключения. Рассмотрим следующий файл конфигурации клиента:
Это базовый файл конфигурации с двумя строками внизу. Когда мы запускаем VPN-соединение с помощью этого файла конфигурации, соединение устанавливается правильно, но выводится предупреждение:
Действительно, после перезапуска VPN-соединения (например, из-за плохого сетевого соединения) перезапуск не удастся:
Здесь мы видим, что OpenVPN не удалось перезапустить, так как пользователю nobody не разрешили прочитать приватный ключ, который использовался для этого соединения. Если бы мы указали пользователя с правами доступа, мы бы увидели другую ошибку:
Обратите внимание, что во время перезапуска OpenVPN не может завершить работу существующего устройства tun или удалить любые системные маршруты. Это также будет иметь место, если используется persist-tun , но в этом случае он будет безвредным.
Как исправить
Добавьте следующие параметры в файл конфигурации клиента, если вы также используете параметры user и/или group :
Убедитесь, что вы запускаете OpenVPN с достаточными привилегиями.
Также убедитесь, что OpenVPN имеет правильный контекст безопасности SELinux, или попробуйте запустить OpenVPN с SELinux, установленным в разрешающий или отключенный режим:
Отсутствие повышенных привилегий в Windows
В некоторых старых версиях программы установки OpenVPN для Windows не были заданы правильные привилегии для приложения OpenVPN GUI.
В этом конкретном примере один сервер был передан с сервера OpenVPN всем клиентам:
В Windows Vista и выше OpenVPN требуются повышенные привилегии чтобы иметь возможность добавлять или удалять системные маршруты. Если эти привилегии отсутствуют, VPN обычно инициализируется правильно, а значок GUI становится зеленым:
Мы даже можем пропинговать сервер OpenVPN по IP-адресу его VPN-сервера. Тем не менее, файл журнала в OpenVPN GUI покажет некоторые ошибки:
Первая строка на самом деле хитрая:
Сложность в том, что как только мы нажимаем кнопку Disconnect — журнал исчезает, так как он не может быть записан на диск! Это вызвано тем, что каталог журналов по умолчанию C:\\Program Files\OpenVPN\log доступен только пользователю с повышенными привилегиями.
Последние несколько строк в файле журнала говорят нам, что 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-адреса. Новый набор файлов конфигурации выглядит следующим образом:
Этот файл сохраняется как movpn-09-01-server.conf . Для клиента OpenVPN в дополнительном офисе создается специальный сертификат с именем /CN=SecondaryOffice . Соответствующий файл CCD, следовательно, имеет имя /etc/openvpn/movpn/clients/SecondaryOffice . Его содержание таково:
Для всех клиентов может быть использован конфигурационный файл 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, так как все остальные клиенты не требуют доступа к его сети.
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли этот сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
- Существует ли на сервере правило брандмауэра, блокирующее доступ с 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:
- Запустите tcpdump -nnel -i tun0 на сервере, чтобы увидеть, поступает ли вообще какой-либо трафик через VPN.
- Запустите tcpdump -nnel -i eth0 на сервере (где eth0 — интерфейс локальной сети используемого сервера), чтобы увидеть, поступает ли вообще какой-либо трафик на интерфейс локальной сети. Если нет, то, скорее всего, правило брандмауэра отбрасывает входящий трафик на туннельном интерфейсе.
- Запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс LAN с помощью следующего:
Также проверьте, видим ли мы обратный трафик от серверного шлюза с обратными адресами отправителя и получателя.
- Снова запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс локальной сети со следующими заголовками пакетов:
Здесь 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 чуть ниже этого размера. Чтобы определить максимальный размер передачи для нашей сети, мы используем следующее:
В Windows мы используем следующее:
Она будет отправлять ICMP-пакеты на удаленный сервер по нашему выбору с установленным флагом not fragment , инструктируя сетевые маршрутизаторы не разбивать этот пакет на более мелкие биты. Если между клиентом и сервером есть сеть с меньшим MTU, то команда ping завершится неудачно:
Это говорит нам о том, что производительность будет, скорее всего, лучше, если мы используем либо фрагмент размером 1480, либо размер MTU 1480 байт вместо значения по умолчанию 1500 . Обратите внимание, что это не является гарантией — только измерив фактическую производительность VPN, мы узнаем, каково влияние на самом деле.
Использование iperf
Используя iperf мы можем измерить производительность сети как внутри, так и вне VPN-туннеля. Это даст нам ценную информацию о том, сколько пропускной способности мы тратим, используя VPN-туннель.
Прежде чем измерять производительность самого VPN-туннеля, всегда пытайтесь измерить производительность нормальной сети. Будет довольно сложно заставить VPN работать лучше чем базовая сеть.
Сначала запустите iperf на сервере с помощью следующей команды:
Затем запустите iperf на клиенте с помощью следующей команды:
В кабельной сети, которая использовалась для тестирования, результат выглядит следующим образом:
Это на самом деле скорость загрузки используемого кабельного соединения. Теперь мы можем проверить производительность VPN-туннеля в той же сети:
Повторение измерения дает очень похожие цифры, поэтому справедливо утверждать, что производительность VPN-туннеля на несколько процентов ниже производительности базовой сети. Это на самом деле имеет смысл, так как использование VPN действительно создает некоторые накладные расходы для инкапсуляции, шифрования и аутентификации (подписи) исходных данных. Это будет трудно для дальнейшей оптимизации этой сети.
Аналогично, для скорости загрузки используемого кабельного соединения мы обнаруживаем, что производительность VPN-туннеля на несколько процентов ниже:
Производительность базовой сети показана следующим образом:
Теперь сравните это с VPN-туннелем:
Опять же, мы видим снижение производительности на 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 :
Сейчас наблюдается явное падение производительности. К сожалению, снижение параметра fragment нам здесь не поможет. С fragment 1200 мы достигаем 149 Мбит/с и 115 Мбит/с соответственно.
В высокоскоростных сетях также имеет смысл поэкспериментировать с шифром кодирования. Оба сервера, используемые в этом примере, способны выполнять быстрые инструкции AES благодаря расширению AES-NI, которое присутствует в процессорах (Xeon E5 2620 с тактовой частотой 2 ГГц и Xeon E5 2643 с тактовой частотой 3,5 ГГц, соответственно). Давайте добавим следующее:
Теперь мы получаем следующий результат:
На способном процессоре шифр оказывает большое влияние на производительность. Поскольку OpenVPN является монолитной программой — большое количество ядер не помогает вообще. Тактовая частота процессора является доминирующим фактором. Подключив ноутбук Core i7 с тактовой частотой 3,8 ГГц к серверу Xeon E5-2643 с частотой 3,5 ГГц, мы получаем гораздо более высокую пропускную способность, используя точно такую же конфигурацию:
Таким образом, если вы хотите настроить туннель OpenVPN через высокоскоростную сеть, то лучший совет — использовать высокопроизводительные ЦП, которые поддерживают набор инструкций AES-NI. С такой настройкой можно достичь скорости сети более 500 Мбит/с в обоих направлениях.
Анализ трафика OpenVPN с помощью tcpdump
Низкоуровневый сетевой инструмент tcpdump или его аналог Wireshark с графическим интерфейсом является последним средством для устранения неполадок и производительности сети. В этом разделе мы рассмотрим процесс захвата и анализа зашифрованного сетевого трафика, создаваемого OpenVPN.
Сначала мы настраиваем нашу стандартную сеть OpenVPN, используя конфигурационные файлы basic-udp . На клиенте также работает веб-сервер. Мы будем использовать команду wget на стороне сервера, чтобы извлечь файл с веб-сервера, чтобы мы могли посмотреть на полученный сетевой трафик.
Мы запускаем tcpdump на интерфейсе Ethernet и собираем сетевой трафик, выполняя wget вне туннеля:
Результирующий вывод 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, и узнаете о планах по устранению этих проблем.
Osvoenie-OpenVPN is maintained by translaster. This page was generated by GitHub Pages.
Ошибки при подключении VPN
Главная задача любого сервиса VPN – создание защищенного соединения, которое помогает посещать заблокированные ресурсы. Подобное соединение называется VPN-тоннель, который связывает конкретного пользователя и удаленный сервер. Это достаточно сложная технология, требующая специальных знаний и оборудования.
Если программа сдает сбой – это ошибка подключения VPN, о которой немедленно сообщается пользователю. В данном сообщении, как правило, содержится код, указывающий на тип сбоя, что облегчает дальнейшую работу по его исправлению.
Максимально расширьте свои возможности в Интернете с помощью наших надежных серверов виртуальной частной сети! Всего от $4 в месяц вы сможете получить доступ к популярным международным сайтам, таким как Netflix, Amazon,Chatgpt, недоступные в РФ. Наши интуитивно понятные приложения и передовая технология шифрования обеспечат вам безопасный просмотр веб-страниц без ущерба для конфиденциальности. Кроме того, воспользуйтесь нашими демократичными ценами и бесплатным пробным периодом — присоединяйтесь прямо сейчас! Наши консультанты помогут вам выбрать наиболее подходящую систему защиты и настроить безопасные протоколы передачи данных – IKEv2, L2TP/ipsec, OpenVPN, Shadowsocks, WireGuard. Не упустите свой шанс — подключайтесь к нам, чтобы получить все эти преимущества по доступной цене уже сегодня!
Защитите свою информацию и свободно просматривайте веб-страницы с помощью нашего VPN-сервиса! Наше программное обеспечение совместимо с Android, Windows, Linux, MacOS, iOS, что гарантирует защиту вашей цифровой деятельности и личных данных от любых потенциальных рисков. Если вам нужна помощь в настройке системы, наши специалисты готовы оказать ее. Получайте потрясающие предложения на нашем TG-канале (https://t.me/rvpn_info) или подключайтесь к нашему телеграм-чату (https://t.me/rvpn_chat) для чтения новостей и оперативного решения любых проблем! Зарегистрируйтесь сейчас, чтобы защитить свои данные и получить мгновенный доступ к любым сайтам!
Поскольку большинство ошибок VPN типичны, при наличии определенной информации пользователь может самостоятельно исправить проблему. Важно отметить, что многие провайдеры самостоятельно вводят процедурные коды, исправляющие возникшие проблемы и неполадки. Но существует определенный перечень, требующий непосредственного вмешательства пользователя для конкретного решения проблемы.
Коды ошибок и пути решения проблемы
При сбое работе программного обеспечения VPN система выдает сообщение об этом, выдавая конкретный код ошибки. Каждый из выдаваемых кодов позволяет провести определенные процедуры, позволяющие с высокой долей вероятности решить проблемы.
Ошибка VPN 800
Описывает одну из наиболее распространенных проблем. Такой код выдается, когда программе не удалось установить удаленное соединение с сервером. Это указание на то, что запрос по какой-либо причине не достигает сервера. Такая ситуация может сложиться по нескольким причинам:
- Неправильно указанное имя или виртуальный адрес сервера.
- Установка сетевых брандмауэров, некоторые из них просто блокируют VPN-траффик.
- Потеря связи с локальной сетью.
- При использовании туннеля L2TP/IPSec неподходящий формат IPSec-переговоров в конфигурации параметров безопасности.
Такое случается, когда тоннель VPN имеет автоматические настройки, при этом не удается воссоздать соединение для всех образующихся туннелей.
Решение проблемы:
При подключении проверить все параметры, включая адрес сервера, логин и пароль.
Лучше не использовать брандмауэр или настроить его таким образом, чтобы разрешался транзит PPTP и/или VPN.
Ошибки VPN 609 и 633
При указании несуществующего типа устройства выдается ошибка 609, а в случае, когда соединение уже занято или неправильно используется, показывается ошибка 633. Это схожие проблемы, возникающие при неправильной настройке мини-портов или при использовании порта ТРС другими программами. Для подтверждения проблем с мини-портом, необходимо выявить его наличие, для этого в командной строке вводится команда netcfg.exe -q. Для разных тоннелей используются такие мини-порты:
- MS_PPTP для туннеля PPTP.
- MS_L2TP для туннеля L2TP.
- MS_AGILEVPN для туннеля переподключения VPN (IKEv2).
- MS_SSTP для туннеля SSTP.
- Использовать встроенную диагностику Windows, если есть указание на отсутствие мини-порта. Утилит операционной системы может устранить возникшую проблему в автоматическом режиме.
- Установить и использовать диспетчер подключений мини-портов для доступа VPN.
- Перезагрузить компьютер или гаджет, после чего снова подключиться к VPN.
Ошибка VPN 0x80072746
Такой код выводится системой, когда уже работающее соединение удаленный хост закрывает в принудительном порядке. Причины проблемы – сертификат компьютера не привязывается к серверу VPN или такой сертификат просто не установлен на данном сервере.
Решение проблемы:
Выйти на связь с администраций компании, предоставляющей услуги VPN. Он даст информацию о факте установки сертификата компьютера на сервере ВПН.
При правильной установке сертификата выполнить привязку HTTPS нужно в командной строке сервера VPN ввести команду netsh http show ssl.
Ошибка VPN 809
Код 809 выдается системой в случае, если компьютеру не удалось установить соединение с ВПН сервером, который не отвечает на запросы.
Решение проблемы:
Подключить порт на маршрутизаторе или брандмауэре. Если не получается, можно развернуть туннель SSTP на сервере и на компьютере, через который и восстановить связь.
Ошибка VPN 13801
Это один из самых распространенных кодов ошибки, которая указывает на недопустимость учетных данных IKE. Она возникает в таких случаях:
Истечение срока действия сертификата на сервере RAS.
Сертификат проверки, применяемый на IKEv2 на сервере RAS, не имеет функции расширенного использования ключа «Аутентификация сервера» EKU.
Отсутствие на клиенте корневого сертификата, проверяющего сертификат RAS сервера.
На клиенте указано имя выбранного сервера VPN, не совпадающее с субъектом сертификата сервера.
Решение проблемы:
Решить вопрос можно только связавшись с администрацией провайдера ВПН.
Ошибка VPN 691
Выдача кода ошибки VPN 691 указывает на отказ в удаленном соединении. Причина – неопознанная комбинация представленного провайдеру логина и пароля или действующий протокол не поддерживается удаленным сервером.
Решение проблемы:
- Убедится, что введенные логин и пароль верны. Часто случается, что такая мелочь, как нажатый Caps Lock приводит в выдаче ошибки.
- Убедиться, что протокол, установленный у пользователя, поддерживается на сервере.
Ошибка VPN 0x800704C9
Данный код выдается в том случае, когда сервер не располагает доступным портом SSTP.
Решение проблемы:
Для устранения ошибки необходимо убедиться, что на RAS сервере достаточно настроенный для работы портов. Для этого нужно:
- Запустить Маршрутизация и удаленный доступ.
- Раскрыть сервер, выбрать Порты при помощи правой кнопки мыши и в контекстном меню выбрать Свойства.
- Найти мини-порт WAN (SSTP), щелкнуть по нему, затем нажать Настроить.
- В пункте Максимальное количество портов поставить желаемое число и нажать ОК. Число портов по умолчанию – 128.
- В окне Свойства порта тоже нажать ОК.
Ошибка VPN 789
Этот код выдается при неудачном подключении L2TP в связи с ошибкой при доступе к удаленному компьютеру.
Решение проблемы:
Нужно убедиться, что и на стороне пользователя и у провайдера используется правильные сертификат соединений L2TP/IPSec. То же нужно сделать и при использовании Pre Shared Key (PSK).
Иногда, кроме специфических шагов, решить проблему с ошибками VPN помогают общие рекомендации:
- Перезагрузить устройство и снова подключиться к провайдеру ВПН.
- Проверить работу антивирусных программ и, при необходимости, на время отключить их.
- Смените сервер ВПН. Тот, на который идет запрос может быть недоступен или перегружен.
- Сбитые настройки времени на устройстве могут привести к проблемам с подключением.
Как видим, нерешаемых проблем не существует, если ничего не помогает, можно обратиться в службу технической поддержки ВПН провайдера. Крайний метод – просто сменить ненадежного провайдера.